The 3 most common techniques EMM vendors use to secure email

I've been writing about many different enterprise mobility management solutions recently, and one of the questions that comes up is how they handle security for email and attachments. Today I'm going to outline the three most common techniques.

I’ve been writing about many different enterprise mobility management solutions recently, and one of the questions that comes up is how they handle security for email and attachments. Today I’m going to outline the three most common techniques.

For a baseline, we’re going to assume that IT will not only want to protect email with basic security policies like passwords and encryption, but also keep third-party apps from accessing and leaking data as well. I’m using the term enterprise mobility management as a way to collectively describe vendors that do mobile device management, mobile application management, and address bring your own device. It will be clear in each of the following scenarios where MDM comes into play and where MAM is used. Let’s dive in!

1. Protect the whole device

The simplest way to protect email on a mobile devices is to actual manage and secure the entire device. Users sync their Exchange accounts to their device’s native built-in email client and then MDM is used to enforce password protection, encryption, remote wiping, and other security features. The email client is protected because the whole device is protected.

But that’s only half of the problem. The other half is that the built-in email clients in iOS and Android are designed to share calendars, contacts, and attachments with any random third-party apps that happen to be on the device. This is convenient for users, but it also means that corporate data can easily be leaked. The only way to stop this is to control what applications are installed on the device in the first place using MDM blacklisting capabilities. (This isn’t always a smooth process, but that’s another whole discussion...) In most situations you’ll probably only block especially dangerous apps or apps that are confirmed malware, but depending on your environment, the amount of blacklisting can range anywhere from totally locked down to wide open.

The good thing about this tactic is that you don’t need any special tools beyond just basic MDM. (Though you’ll probably need some sort of resource like Appthority to help you decide which apps are actually threatening). The downside is that users will be upset if you deem one of their favorite apps to be dangerous and block it, especially if it’s a personal device.

2. Middle of the road: encrypted attachments

If all you’re really worried about are the email attachments, then you can intercept them before they get to the device and encrypt them. Once on the device, only managed corporate apps can decrypt the attachments, not personal apps. You can still use device-level MDM to put some basic security on the device (and thus also the email client), but you don’t have to be nearly as concerned about what random apps the user has installed. The actual email messages, contacts, and calendar are still exposed to the user’s apps, but a lot of the time this is okay, since the attachments are still protected.

The major leap here is that you have to be doing some sort of mobile app management in order to have the corporate apps that can decrypt the attachments, but you can start with just a file syncing client with a built-in document viewer and add other corporate apps to the ecosystem as you get to them.

What’s good about this middle of the road approach is that users get to use the native built-in email client, but IT still gets to control what apps have access to attachments. The disadvantage is that you’ll have to be deploying some corporate-managed apps in order for attachments to be useful.

Right now only a small handful of EMM vendors support this scenario, including MobileIron, AppSense MobileNow, and AirWatch.

3. Third party email apps

The final option ignores the built-in email client in favor of a third-party client app. This means that IT can have complete control over all aspects of email. Security policies are applied directly to the app itself, and only other corporate-managed apps will be able to access attachments and other data, per IT policy.

The advantage with a third party app is that IT doesn’t have to be concerned at all with what’s going on at the device level, and yet they still full control over email. The problem with third-party email apps is that they may not have the same look and feel as native built-in clients, and some users also dislike not being able to view their personal and work email in the same app.

Most solutions rely on Exchange ActiveSync device access rules to restrict access to just the 3rd party client app and not the built-in one, though some like Good Technology use a proprietary protocol. While there are dozens of manageable email client apps out there, not all EMM vendors provide one of their own.

Which do you pick?

Which of these techniques is best? None of them? All of them? The reality is that each one of these techniques involves some sort of a trade-off, whether it’s using a third party app or dealing with app-blacklisting. We’re asking for more protection than mobile devices provide on their own, and it doesn’t come without a penalty in some way or another. Different EMM vendors will skew different ways on this, too. Your environment might push you towards one option or another, but by providing users with multiple options and allowing them to pick on their own you can keep a lot more of them happy.


Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I think you have to ask do you care about data leakage or not. If you do, then only options 1) and 3) are feasible today. Option 2 just encrypting attachments will fall flat on it's face 99.9% of the time.

Data leakage is regulatory requirement, so you can't interrupt that as I just stop some data leaking. Unless the rules change you really have no choice.

So while I really like Option 2 in that is uses the native email client, to work in the real life it would need to secure the native email also which I don't see a solution for today.


@Jack: I agree that the best EMM solution would be one that could offer an organization (and its users) the option to  use one or all of these approaches in combination, based on organizational and user preference. I, for example, prefer the native mail client even though I have to contend with an 8-character complex password at the device level. Other users, however, like the container-only passcode and don't mind the UX issues.

@appdetective: Did you rule out option 2 as a viable method because the assumption was that there would be no passcode policy and the mail client would not be encrypted? What if option 2 included these device management policies, plus the extra layer of attachment leakage prevention? Would you consider that to be a viable approach?

While most organizations I have worked with are comfortable using the native mail client, I have encountered some (particularly those in the financial, healthcare, and govt verticals) that don't consider option 1 alone to be a complete approach because of concerns that attachments can be exported outside the encrypted mail client and into 3rd-party apps such as DropBox. For these organizations, they need an additional layer of protection, either through integrated MDM support of a 3rd-party mail client such as TouchDown, or an attachment stripping and encryption solution such as is described in option 2, or a full enterprise container approach such as Good or Enterproid.


@Naveed I need to worry about email, calendars, contacts, browser on mobile. All content needs to be effectively be isolated and encrypted. That's the basic requirement.


All posts and discussions that I've read of this topic (EMM) lead me to the conclusion that all existing solutions aren't good - they're just better than nothing. (opinion is my own)


Well, there are other interesting solutions coming to the marketof solving just this with full native app experience while providing the isolation.

"Network is the new frontier for EMM/MDM/MAM/MobileIT"..


Nice summary Jack!

One of the interesting things about EMM is that with Windows, vendors could effectively 'rootkit' the OS to apply unique differentiation towards management/security.  The mobile ecosystem seems to frown on enterprises requiring iPhones to be jailbroken to get deep enough access.

In a world of Android vs. iOS , the provided management API's are really the great normalizer.  Samsung SAFE is doing what we're most accustomed to by leveraging their role as device mfg, while Apple decides the fate of everyone else on their devices.

@Appdetective - I concur completely with your requirements.  Do you think Apple has given vendors enough rope to achieve it in a way users will accept ?


@DavidStafford, good points, and wanted to share some of my thoughts. I generally see several schools of thought on using native APIs etc. The Wall Street types will say sort of secure, but say the attack surface is still the container that will secure or host the email client. As a result their security folks will argue that methods provided by the OS can be limiting. As a result, I see some prefer to write their own email client or use Good. They see this vs. say Good as more secure, because it's their own container code and email client that gives them full control. The assumption here is, the probability of understanding how to compromise the container is smaller as it's not in the public domain, they can react faster to emerging threats and compromises and of course a touch of we know best for our custom environment. Having this complete custom environment, enables them to cherry pick what native OS functionality they want to take advantage off.

These same folks have a ltd interest in MDM, realizing that for what they need, stringing together some open source and using the OS API's they can build their own for some niche use cases that they need to service. Generally all these folks want out of the device management business.

However, I personally believe that when it comes to the consumerization of IT, native email is what users really want. Good has been around a while, and I have yet to meet a single person say that they prefer the custom email client vs. the native iOS client. When people try to go custom, IMO they completely miss the fact that the OS vendors spend an awful lot of money on design of their native experience. Through sheer scale economics they have already won the mind share battle for user sentiment. So traditional IT and information security will think cost, security, control first and then celebrate that they did something to enable the user. Winning solutions will focus on the native experience first that users want, and then find ways to layer in acceptable levels of compliance and governance.

To get there, I think it's a fruitless effort to wait for the OS vendors. They will add incremental improvements, upsell existing systems management tools, since it's just not their core focus.  Enterprise controls will have to come from outside the OS in many cases in combination with native OS functionality for broad market solutions. Certainly this has started with MAM vendors filtering attachments, but I also agree with @Srini-gurrapu that network based controls have yet to be effectively exploited.


I'm excited to see such a thoughtful discussion around this area.

The one theme that emerges is that certainly all of these approaches require some sort of compromise to the end-user experience whether it's MDM or MAM. Not to mention that MDM for iOS and standard Android still comes nowhere near the level of control that we had with BlackBerry. @David, I agree, maybe SAFE or WP8 could get there. But Apple? looks unlikely. Look at the disparity between iOS config profile features versus the list of BES 5 features. And also remember all the features that emerged in BlackBerry more recently to keep 3rd party/consumer apps from accessing corporate data? Will iOS ever get there? I don't think so, at least not any time soon. So then the need for 3rd party email with more control as AppDetective points out emerges.

But what do we do with those different compromises? I think one approach to"solve" consumerization with the present tools is to approach it in the manner of "Yes, there's going to be some compromise, but you get to pick your flavor" i.e. native client with MDM or 3rd party client with MAM (or middle option, however and if that works for your environment). The nod towards CoIT is that users have choice, and are informed of reasons in an open dialogue, not a "this is the way it's done" command.

I think Citrix is going in a good direction with the @Work Mail app--At Synergy when it was unveiled the general feeling was liking the GoToMeeting integration. And that's the key for 3rd party email-- first, make sure user experience is solid and reliable, so it doesn't feel like a piece of junk; Second, add enough value-add features to give a carrot to attract users, not just "This is the only alternative to having IT blacklist personal apps." I know for many people in my office, an email app with integration to file shares would we a huge incentive to leave behind native client. (Right now we have no mobile file  solution)

And all of this is only if you need to actually go that far- i.e. for compliance-bound organizations. If middle of the road approach works, then absolutely make it available to users.


@David I don't think Apple has or will do enough to enable solutions for all use cases. Hence I concur with comments from others about other ways being required in conjunction with what Apple provides. Apple is too busy thinking about watches and TV to give a damn :-) As far as they are concerned, their closed eco system, encrypted phone, pin to access everything is meeting the need and selling plenty of phones. Apple is not an enterprise company and will never be, so we just need to accept that and move along. Microsoft could fill this void, but I am sure they will F it up and try to sell their old world management wares to solve problems of the past.

@Jack 100% respectfully disagree with you. Going with third party clients is simply the wrong approach IMO. If I am going to do that, I am better off building my own since the reason is security (as stated in above comments). Adding things like Sharefile etc, are just not enough to tip the balance and very vendor centric solutions. The problem here is this is not being thought about correctly. I.E we are saying, the tech is not there to give us what we want, so let's go down a rabbit hole to implement a solution that we really don't want. I'd say hold your horses. Step back and ask deeper questions.

First I'd really investigate if the tech is not there today, what's emerging, when and understand the feasibility. Reality check, BYOD is young and still an unproven market. Resigning ourselves to subpar solutions will ensure it's failure due to unsatisfied end users.

We also need to think about mobile apps in general. If iOS continues to remain so important, perhaps I am much better off taking all my MDM/MAM budget and instead port my key business productivity apps to HTML 5 etc and put more controls into the application layer.

An Exec recently told me, let's stop listening to what the vendors are telling us to do about BYOD. Let's first think about how best to provide the right set of mobile apps to our customers and internal users.  I.E Modern elegant app architectures designed for enterprise mobility as opposed to gang banging infrastructure solutions to add security. That may or may not be the right answer, or it most likely will be a combination. But what I do know 100% for sure is, that settling for heavily compromised solutions like third party email clients can't be the future of BYOD if we expect it to succeed. I think we have to try harder with native email, there have to be better options and no doubt that's what users will expect to use. If not, might as well stick with the new Blackberry Device with a ton of control beyond any MDM solution.