“Workflow” apps are a way to do mobile app security for SaaS

Where MDM isn’t possible, building workflows into other enterprise apps gives us a hook for security and management policies.

In mobile app management, there have always been certain mobile app security use cases that are just difficult to deal with. In particular, when you’re using native apps distributed on Google Play or the Apple App Store, and you can’t use MDM to manage at the device level, then you’re out of luck. And these days, a lot of companies have sensitive data in these types of apps—think EFSS, CRM, and the like—so mobile app security is a big problem.

SaaS apps can be a mobile app security challenge

SaaS platforms and their client apps might don’t always have all the security and management features you want built in. Unfortunately, you, as the enterprise, can’t just take the app from Google Play or the Apple App Store and add in your own policies (i.e., app wrapping). (App wrapping is still common and suitable for in-house apps, though.)

And still in 2018, there are many reasons why you may not be able to enroll a device in MDM. Maybe it’s for BYOD privacy concerns; or maybe it’s because the device belongs to an external partner or contractor and it’s already enrolled in another organization’s MDM environment. iOS and Android still only support one MDM at a time, and this is where I make the now-obligatory mention that BYOD privacy on Android is pretty good, but iOS BYOD privacy is lagging behind.

Enter "workflow" apps

So what do we do to secure these apps? This is where “workflow” apps come in. Essentially, you’re building your own client for your SaaS platform, instead of using the clients in the public app stores.

Workflow apps integrate with SaaS platform APIs, so that users can perform simple tasks, like responding to notifications with quick actions, capturing data, or searching for information.

These tasks are then integrated into some sort of mobile client—it can be a dedicated workflow app client, an email client, or some variation of the app catalog and workspace apps that have been getting common among EUC vendors.

The important thing is that since you’re using an alternative mobile client for your SaaS platform, you have more opportunities to choose or build an app with all the security and management policies you need. You then use identity management controls to make sure that users can only access the SaaS platform from your app, and not the clients apps in the public stores.

Caveats and options

Of course, the biggest problem is that you have to worry about how all these workflows are getting integrated, and you’ll probably have far fewer features than the “real” client. So for sure, this is only something you’ll do for important, frequent tasks. (If, for example, the user wants access to the full client, you could make a policy that they have to enroll in MDM.)

There are a lot of options for building SaaS workflows into other apps. On the EMM vendor side, VMware Workspace One Mobile Flows is on my of mind since I was just at VMworld. (Conversations at the show reminded me that I haven’t written about this angle before.) Some Mobile Flows features are available in VMware Boxer, and as was announced, Workspace One Intelligent Hub.

Citrix has some of these features in their Workspace apps—for example, their ServiceNow integration. I wouldn’t be surprised to see BlackBerry go after some of these features, as well, given their PaaS aspirations.

On the pure play side, there are a bunch of products, like Sapho, which aim to build workflows as alternatives to full clients. Sometimes these are also called “micro apps.”

Other approaches to this mobile app security problem include cloud access security broker (CASB) functionality; or, you could just go lightweight conditional access (i.e., make sure the device is up to date, encrypted with a passcode, and non-rooted/jailbroken).

As Android Enterprise and (hopefully someday) iOS MDM get better and cover more use cases, then there will be less of a need for workflow apps to serve as the anchor point for mobile app security policies. (They’ll still serve other purposes, though, like consolidating all your common tasks into a single view.)

On the other hand, there will always be places where you won’t be able to manage the device, just as there will always be places where you’ll want to fully own the device.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close