Secure your mobile email with Microsoft EMS

and Microsoft Outlook for iOS and Android

(This post is co-authored by Adrian Moore, Senior Program Manager, and Mayunk Jain, Product Manager,
Microsoft 365 Security)

Whether you have an official BYOD (bring your own device) policy or not, chances are you caught up on
some work email this weekend on your mobile phone. If so, you’re not alone; more than 80% of employees
admit using non-approved SaaS apps for work purposes, including mobile email. What is worth noting, is
that 63% of confirmed data breaches involve weak, default, or stolen passwords. According to Verizon's
2018 Breach Investigations report, 92 percent of malware is still delivered by email.

As an IT leader investing in Microsoft 365 modern workplace to meet cyber-security challenges head-on,
secure email access is likely to be a key part of your strategy. In this article, we’d like to introduce you to the
integrated approach of Microsoft Enterprise Mobility + Security (EMS) and Microsoft Outlook for iOS and
Android devices, that we consider the gold standard of secure mobile email access.

Three pillars of secure mobile email

Outlook for iOS and Android (also called Outlook or ‘Outlook mobile’ in this document), Microsoft Intune
app protection policies, and Azure Active Directory (Azure AD) conditional access (CA) are the three pillars
of secure mobile email access within this integrated Microsoft 365 approach. They enable mobile email
access without the need for gateways or proxies and get full value from your deployment of Microsoft
Exchange Online cloud service. Microsoft Intune and Azure AD conditional access are included in every core
EMS or Microsoft 365 subscription.

Microsoft Outlook for iOS and Android

Outlook is a free, top-rated productivity client on both Apple app store and Google Play Store. Outlook
apps provide a consistent messaging experience across a variety of platforms, while ensuring security and
data are not compromised. Standardize how your users access email from mobile devices, and protect your
organization from email-based cyberattacks such as ransomware and phishing, and prevent corporate data
falling into the wrong hands from unsecured mobile email clients. Enabling Microsoft Outlook for iOS and
Android as the approved, managed email app allows you to gain full advantage of Microsoft Intune app
protection policies (APP). Your users get the top-rated experience of a modern, secure email client in
Outlook, with features such as focused inbox, integrated calendar, external recipient notifications, one-
touch meetings, and more.

Microsoft Intune app protection policies

You can use Intune app protection policies to secure Outlook data on mobile devices, whether the devices
themselves are managed or unmanaged. This implementation of mobile application management (MAM)
by Microsoft gives you enhanced data security at an app level, independent of any mobile-device
management (MDM) solution. This independence lets you protect your company’s data in the Outlook
client running on managed devices, unmanaged devices (i.e. without enrolment in any MDM solution), and
devices managed by a third-party MDM solution.

App-level policies help make sure your employees can collaborate freely and be productive, while creating
trust that the modern email system will automatically protect against any accidental or intentional data
leakage. With Microsoft EMS, you keep corporate data within the purview of your IT department at all
times; even after it leaves the organization boundary.

Azure Active Directory conditional access

You can configure conditional access policies to block email access from unmanaged mobile email clients
that may be non-compliant with corporate security policies. Where Intune app protection policies use data
loss prevention (DLP) technology to secure data inside the app, conditional access (CA) protects the
network and the service itself by ensuring only compliant and approved apps access the service in the first
place.

How it works
Let us dig deeper and explore the configuration settings to deliver the rich experience of Microsoft secure
mobile email.

Conditions are evaluated on several parameters to determine compliance. The results of the conditional
access check define which authentication attempts in Azure Active Directory (AD) will be subject to which
access controls. It’s important to understand that the more granular your conditions, the fewer levels of
authentication will apply to your chosen access controls.

Device platform condition

A common approach to securing email with CA, is to first tackle all iOS and Android devices, then move on
to other platforms such as Windows and macOS. You can then widen the net to cover any client that
leverages either Modern Authentication or Basic authentication on any platform. In order to “scope” the CA
rules in such a manner, we take advantage of the “Device platform” condition, shown below.
IMPORTANT

It’s important to note that only clients that correctly identify their device platform will be subject to such a
policy. The Authentication Considerations section provides more detail.

Client Apps condition

In the Azure portal, if we navigate to Microsoft Intune > Conditional access - Policies > New > Conditions >
Client apps (preview), we see the following options:
Here’s a breakdown of what those options mean:

• Browser: This option relates to access via a browser such as Edge, Safari, Firefox, etc.
• Mobile apps and desktop clients: This option relates to mobile apps such as Outlook mobile or the
iOS native mail client, and desktop clients such Microsoft Outlook and the macOS native mail client.
o Modern authentication clients: This relates to clients which support Modern Authentication
(specifically, OAuth 2.0). This includes Outlook mobile and the most recent versions of the iOS
native mail client.
o Exchange ActiveSync clients: This relates to any Exchange ActiveSync (EAS) clients that use
Basic authentication. This includes the native iOS mail client prior to iOS 11, as well as most
Android mail clients.
▪ Apply policy only to supported platforms: This relates to the OS platforms supported
by Intune (namely iOS, macOS, Android and Windows 10), and is based on the OS
Platform reported to EAS. Checking this causes the policy to only apply to devices that
can be enrolled into Intune, allowing devices that cannot enrol access to EAS without any
conditions. As a result, it’s not commonly used.
o Other clients: This relates to any other client that uses Basic authentication. This includes POP,
IMAP, SMTP, etc. This has the effect of completely blocking Basic authentication. Examples
include Office 2010, Office 2013 without the EnableADAL registry key, Office for Mac prior to
2016, and some EWS applications such as room booking systems (specifically, EWS apps that use
Basic authentication). Essentially, it's any Basic authentication request against Exchange Online.
For this reason, care should be used with this setting.
 NOTE
EAS is a client protocol that lets you synchronize a mobile device with your Exchange mailbox. Client apps
using the ActiveSync protocol use one of the following authentication/authorization protocols: HTTP
Basic authentication, OAuth or a client certificate. Credentials are passed in different formats depending
upon the form of authentication itself.

EAS shouldn’t be confused with authentication (Basic, or otherwise).

Reference: https://msdn.microsoft.com/en-us/library/ee218319(v=exchg.80).aspx

Real world example

We’ll now look at how all this translates into actual policies, what some of the IT Pro considerations are, and
what this looks like from the perspective of the user.

With the following policies in place, Outlook mobile is the only Modern Authentication client allowed
to access Exchange Online on an iOS or Android device:

Policy 1. Prevent EAS clients that leverage Basic authentication from connecting to Exchange Online by
requiring Outlook mobile:

Policy 2. Allow only Outlook for iOS and Android devices, and block OAuth-capable EAS clients from
connecting to Exchange Online:
 NOTE
I. Ensure you understand that unpredictable results that may occur when using the device platforms
condition.

II. In order to use the “Require approved client app” control, a valid Intune license is required.

III. For the second policy, the minimum required cloud app is “Office 365 Exchange Online”; however, to
leverage the deep integration of Outlook mobile with O365, you will also need to enable Office 365
SharePoint Online, Microsoft Teams, and Skype for Business Online.

End user email client experience

Here’s how the secure email experience looks from the perspective of a Microsoft Outlook mobile user:

• If they use Outlook mobile, the connection satisfies the compliance check and runs smoothly. Any
attempt to use a non-compliant Modern Authentication client to access Exchange Online will be
blocked, even if the device platform itself is compliant. The user will be presented with the following
conditional access error:
• If user tries another client that uses Basic authentication to access Exchange Online using the Exchange
ActiveSync (EAS) protocol, they will be blocked and the sent a quarantine email with a link to use
Outlook mobile. This includes most bundled Android email clients:

• When accessing Exchange Online, Modern Authentication clients on Windows and macOS devices
continue in their current state, as well as any client that does not correctly define its OS. Browser access is
similarly unaffected, as are “Other clients”.
Authentication considerations
To give your users easy access to your cloud apps, Azure AD supports a broad variety of authentication
protocols, including legacy authentication. However, legacy protocols don’t support multi-factor
authentication (MFA). In many environments, MFA is a common requirement to address identity theft, so
blocking clients that leverage Basic authentication from connecting to Exchange Online is an important part
of improving your tenants’ protection.

The previously-configured policies ensure employees using traditional mobile messaging clients comply
with policy. However, there are other clients available that don’t leverage traditional mobile protocols –
IMAP, POP, and Exchange Web Services (EWS), for example. We also know that we cannot always rely on a
client to present the device platform information correctly (or, even, at all), and therefore some clients may
bypass such a CA rule.

We have seen customers attempt to use the device platforms condition to scope the policy that blocks
Basic authentication, so that it only affects specific device platforms - only to experience unpredictable
results.

Consider the following scenario:

You scope the Basic authentication block rule to iOS, macOS, and Android devices. You use the following
configuration:

This configuration makes sense on paper; however, as we discussed earlier, in general, Basic authentication
requests do not provide device platform information, and the presence of device platform information in
EAS and Modern Authentication requests varies from client to client. Conditional Access is based on
conditions - with device platform being one of them. If the client does not provide device platform
information, the request will not be matched to a conditional access policy because the condition has
not been met. In this case – where the CA policy is a block – this would result in an allow:
In order to eventually prevent these types of clients from connecting on mobile devices, you need an
unconditional rule.

Policy 3. A far broader policy for both Basic and Modern Authentication – a policy that only leverages the
Client Apps condition:

NOTE
I. This does not apply to the EAS protocol because we have a condition in Rule #1 which captures EAS
traffic. Without Rule #1, the user would simply get an “Incorrect username or password” loop instead of
the quarantine email with a link to Outlook mobile.
So, while this last rule is not mandatory, without it in place you will likely capture all or most of your clients.
However, you cannot rule out the possibility of some rogue clients slipping through a conditional policy. If
your goal is to truly standardize all mobile email access with Outlook mobile, you should first work to
ensure your entire environment (Outlook desktop, internal EWS apps, legacy clients etc.) is ready before
implementing any additional policies. This will require a thorough analysis of all (known and unknown)
clients and services which are currently accessing Exchange Online.

IMPORTANT
I. Serious care must be taken when enabling Policy 3 in your environment, as it will prevent all apps that
connect to Exchange Online using basic authentication from connecting. This includes most Android
devices, and may include some third-party EWS resource booking systems, legacy Office clients, etc.

II. Ensure you read and fully understand How to: Block legacy authentication to Azure AD with conditional
access, in particular the “Policy deployment” section.

If you have third-party application requirements which make an unconditional block of Basic authentication
unrealistic, another option is to leverage the new Authentication Policies in Exchange Online. An example
may be where you have a requirement to block POP/IMAP clients but allow EWS.

Finally, don’t forget that Basic authentication for EWS to access Exchange Online will be no longer
supported, and fully decommissioned on October 13th, 2020. This means that new or existing apps will not
be able to use Basic authentication when connecting to Exchange Online using EWS.

Viewing the sign-in results in Azure Active Directory

The Azure AD sign-in results show us a wealth of information which will assist in testing and
troubleshooting. Here we look at the effect of the previously-configured policies:

1. The test user “CloudiOS” attempts to connect to Exchange Online using Modern Authentication with the
native mail client on an iOS 12 device.

Open the Azure AD blade in the Azure portal, navigate to “Sign-ins” under the Monitoring section, and
search for the affected user:
Ensure you have the correct authentication attempt by matching the Request ID from the error on the
users’ device with the correct entry in the portal:

Device:

Portal:
The conditional access tab shows us that our policy is working as expected:

2. The test user “CloudiOS” attempts to connect to Exchange Online using EAS with Basic authentication via
the Gmail app on an Android device:

As this attempt utilizes the EAS protocol, we do not get a conditional access error. So, we just need to find
the entry in the Azure AD portal:

Notice how there are two entries, a few seconds apart, for what is - at least from the user perspective - the
same connection attempt. However, there is a difference between the two entries:
Also note how the conditional access tab does not show a matching policy:

The reason why we see this is because, with EAS traffic, it’s Exchange Online and not Azure AD that handles
the policy. For this reason, all EAS traffic is allowed through to so Exchange Online can generate the
quarantine message.

3. The test user “CloudiOS” attempts to connect to Exchange Online using EWS with Basic authentication via
a third-party app:
Checking the conditional access tab shows us our policy is working as expected:

For your reading pleasure, here is the output from the Exchange Remote Connectivity Analyzer that was
used to test EWS:

Next steps
Together, Outlook for iOS and Android and Microsoft Enterprise Mobility + Security give you the tools you
need to provide your users with a great mail experience on whatever platform they choose, without
compromising on the security your enterprise requires. Check out Securing Outlook for iOS and Android in
Exchange Online for technical documentation, including more advanced scenarios.

More info and feedback

Learn how to get started with Microsoft Outlook on iOS and Android in the enterprise with the
customer adoption resources. Don’t have Microsoft EMS? Start a free trial or buy a subscription
today!

As always, we want to hear from you! If you have any suggestions, questions, or comments, please
visit us on our Tech Community page.

Follow @MSIntune @AzureAD and @Outlook on Twitter