The last few months have brought a lot of excitement around app wrapping, SDKs, and other methods of mobile application management. The reality is, though, that the many of the mobile applications that most corporate users use are clients for SaaS offerings that don’t need to be managed. Trying to control these apps or services using mobile application management is difficult, if not impossible.
For the purpose of this article, I’m talking about publicly-available software-as-a-service offerings that have client apps that are easily accessible for multiple platforms (Apple App Store, Google Play, web apps, etc.). I also refer to the two different types of mobile application management: basic app stores and more advanced management through app wrapping or SDKs.
1. Users can find SaaS clients on their own
The most basic type of mobile application management, a simple app store, is irrelevant for SaaS. It could be provided as a convenience to users, but it’s pretty safe to say that any user that’s comfortable with a mobile device would have no problem searching for, installing, and logging into a client app. It’s also most likely that an enterprise app store would contain links to public app stores, rather than the actual apps themselves.
2. Watch out for unsecured client apps
What if an a SaaS client app is insecure in some way—perhaps it doesn’t automatically log out users? Even if a company could acquire the client app and use one of the more advanced types of MAM to wrap it or secure it in some way, a user could simply acquire the publically available version of the app. Ideally, part of a company’s due diligence with a SaaS offering would be making sure that all the methods of accessing it are acceptably secure. What if the apps do happen to be unsecure? Read on to number three:
3. There will always be other ways to access SaaS
Blocking an SaaS client app on one platform or device won’t secure the SaaS offering. A company can secure devices, secure apps, or block websites all they want, but there will always be other ways to access both SaaS offerings and their associated client apps.
4. Who’s responsible for securing SaaS?
It would be easy to blame the mobile device security or app security when something goes wrong. The IT department’s responsibility for securing SaaS can only go so far, especially in cases where employees are using unauthorized services (FUIT situations). But what if one department in a company decides to use a SaaS product, without the knowledge of IT and without making sure that the client apps are secure, who will be responsible? True, IT could be responsible for securing the users’ mobile devices, but those only one of many possible vectors for access.
5. What is a SaaS app, anyway?
While we’re having this discussion, I want to ask what what a “SaaS app” is. Various app management and portal solutions claim to be able to manage “SaaS apps”. What do they mean by that? A native iOS or Android app? A traditional desktop app that plugs into a SaaS offering? A web app? Are they managing users’ identities in some way? We can talk about specific types of client apps—like here, where we’re talking about mobile apps that act as clients for SaaS offerings—but saying a product manages “SaaS apps” is vague and possibly misleading.
6. You’ll have to figure out identity management
At the end of the day, you can’t control a SaaS offering through its client apps. Instead it has to be controlled through identity management. You’ll have to figure out federation protocols or managing user accounts manually. When it comes to the client apps that are used to access SaaS, you’ll have to make sure that they’re inherently secure, because no amount of MAM or MDM will secure SaaS.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.