Shortly after the release of the Outlook app for iOS and Android in early 2015, organizations quickly began blocking the mobile app because of security issues that were discussed on several blogs. After more than six months, has Microsoft addressed those security issues? Were they even issues to begin with? Should you consider allowing your end users to access Outlook for iOS and Android?

In December 2014, Microsoft acquired Acompli, a software company that made mobile email apps for iOS and Android. Shortly after the acquisition, Acompli was rebranded to Outlook for iOS and Android as the successor to the OWA apps for iOS and Android. Microsoft has said that the OWA apps will be replaced by the new Acompli/Outlook app when features such as the ability to view Information Rights Management protected mail and Apps for Outlook are available in the new app. After those features are added to Outlook for iOS and Android, I’m sure we’ll see a formal announcement about end of support for OWA.

The writing is on the wall: the OWA app is going away and the new Outlook app is the app that will be supported moving forward.

Outlook for iOS and Android denied access – The message end users receive if an organization blocks the Outlook app
Outlook for iOS and Android denied access – The message end users receive if an organization blocks the Outlook app

Shortly after the release of the new Outlook app, a blog post started circulating about how the Outlook app would break your company’s security that advocated blocking the app. Specifically, the cited security concerns are the file sharing capabilities (connectivity to OneDrive [consumer], Dropbox, Box, and Google Drive), shared Exchange ActiveSync ID and device type, and credential storage. Let’s dig into each one of those.

File sharing

As of the publication of this article, the Outlook app for iOS and Android allows a user to connect to OneDrive (consumer), Dropbox, Box, or Google Drive.

Adding a file storage location in the Outlook for iOS app
Adding a file storage location in the Outlook for iOS app

The risk with allowing an end user to connect to any of these services is that users can easily save email attachments from their corporate email account into one of these services, outside the control of corporate IT. You might think that this is a huge nightmare for protecting company data—especially if you’re dealing in credit card numbers, social security numbers, or other personally identifiable information (PII).

Here’s the problem: how much control do you have over that now? The proliferation of cloud services has made blocking them at the border nearly impossible—especially when those are the services that people want to use or if they have to work with other organizations (such as customers) that do use these services. Even if you block every one of these services at the corporate network border, employees will bring in USB drives, access them when off the corporate network on a laptop, or find other creative ways around the security measures.

What’s the solution? Microsoft’s solution to protecting data is Rights Management Service (RMS). It is available in both an on-premises version (Active Directory Rights Management Services [AD RMS]) and a cloud version (Azure Rights Management [Azure RMS]). RMS protects the file itself based on its content and rules that the organization writes. If a file is protected by RMS and saved to a public folder on a cloud storage location, only the authorized employees in the organization can open the file. With AD RMS or Azure RMS in place, IT doesn’t need to care where files get saved because they’re protected regardless of storage location.

Shared Exchange ActiveSync ID and device type

The Outlook for iOS and Android app depends on a back-end cloud service to check for mail and send push notifications to the device. Because of this architecture, Outlook for iOS and Android will always show up as one device with one ActiveSync ID regardless of the number of devices an end user has connected.

The obvious risk here is that, if an end user loses his/her device, you can’t identify it because all of the devices appear as a single device. And, unfortunately, there’s not a good answer for that. If a remote wipe becomes necessary, the Outlook app is going to be wiped on every device the end user has connected.

But, that’s also the benefit of this architecture in my book: only the Outlook for iOS and Android app gets wiped out. In a BYOD environment, this is a good thing. The remote wipe doesn’t reset the device back to a factory condition; it selectively wipes the Outlook app and all data in the Outlook cloud service. The worst-case scenario is that the user has to set up the Outlook app again.

Credential storage

In the original release of the Outlook app for iOS and Android, authentications against Office 365 Exchange used basic authentication. This could mean your credentials were stored in a Microsoft–run cloud service that resided inside Amazon Web Services.

As of a June 2015 update, Office 365 Exchange now uses OAuth in the Outlook app, removing the possibility that Office 365 credentials will be stored. The new authentication procedure uses Active Directory Authentication Library (ADAL)–based authentication. Accounts with a cloud-based username/password are directed to an Office 365 sign-in page; accounts with an Active Directory Federation Services (ADFS)–based username/password are directed to the ADFS sign-in page. Office 365 Exchange joins, OneDrive, Dropbox, Box, and Gmail as services that use OAuth within the Outlook app.

Outlook for iOS ADAL–based sign-in page

Outlook for iOS ADALbased sign-in page

Outlook for iOS being redirected to an ADFS sign-in page

Outlook for iOS being redirected to an ADFS sign-in page

As of the publication of this article, Yahoo, iCloud, and on-premises Exchange Server do not support OAuth. For these services, the Outlook app does store your credential in encrypted form in the Outlook cloud service. A random AES-128 key (called a device key) is generated during the first run of the app. When a user logs in to a non-OAuth service, the username, password, and device key are transmitted to the Outlook cloud service via a TLS encrypted connection. The cloud service verifies the password and then encrypts the password with the device key. The device key is then wiped from memory, never having been stored on disk. When a user checks for mail, the device key is sent to the cloud service and used to decrypt the encrypted password. After the Outlook cloud service has checked for mail, the device key is wiped from memory again.

Outlook app for iOS and Android flow chart for non-OAuth accounts
Outlook app for iOS and Android flowchart for non-OAuth accounts

If you’re using Office 365 Exchange, the move to OAuth in the Outlook app removes the concern about stored credentials. However, if you’re running on-premises Exchange, the storage of user credentials (even in encrypted form) is a risk that your security department will have to consider.

One additional risk in the current architecture is the use of Amazon Web Services to run the Outlook cloud service. Microsoft has said that a “coming IT control” is the move of the cloud service from Amazon Web Services to Microsoft Azure, but the company has not offered a timeline for when the move will be made. The current iteration of the Outlook web service does meet Category A of the Compliance Framework for Office 365, which does not include EU Model Clauses (EUMC), HIPAA Business Associate Agreement, or FedRAMP, just to name a few. I hope the move to Azure will clear up many of these current limitations.

Subscribe to 4sysops newsletter!

What about your organization? Have you disabled Outlook for iOS and Android? Do you plan on enabling it at some point in the future? Let us know what you think in the comments.

  1. Christian Wimmer 8 years ago

    We blocked the app on our Exchange server. Storing passwords and such in a cloud that isn’t even hosted by Microsoft is just a bit too insane for my taste.

    • Author
      Kyle Beckman (Rank 2) 8 years ago

      The password is never stored on disk in the Outlook cloud service. The password is encrypted and stored in encrypted form. It is decrypted in memory when the device requests that mail be fetched from the server and then erased from memory.

  2. Christian Wimmer 8 years ago

    The Heartbleed SSL bug has shown why this can be a bad idea.

    • Author
      Kyle Beckman (Rank 2) 8 years ago

      At the end of the day, every encryption that exists will be cracked eventually and bugs in those products will exist. Using that same standard, we in IT should block cloud-based password managers because users are potentially storing their corporate passwords in cloud services that could be hacked if a vulnerability is found or their encryption isn’t strong enough.

      • Chris K 7 years ago

        If you follow this line of argument you need to prevent users from saving passwords on any form of storage for the same reason, especially on devices that are portable and prone to loss.

        There’s no easy, simple solution – just a whole bunch of risks you have to decide on how to minimise.

  3. David 8 years ago

    According to, the remote wipe functionality with this app is a bit problematic. A report is never returned to the server indicating the wipe was successful and the device is listed as “pending” indefinitely.

    How do you allow access back to the server if you can’t be certain the account on a device has been wiped? Since all mobile devices using Outlook (iOS or Android) are considered a single device, the affected user’s other mobile device(s) would also be locked out.

    • Author
      Kyle Beckman (Rank 2) 8 years ago

      In a perfect environment, you would also have MDM on all of a user’s mobile devices and this wouldn’t be an issue. But yes, I agree that is problematic. The biggest upside for the end user is that the remote wipe is selective and only wipes the Exchange account from Outlook and not the entire phone. I would encourage you to pester your Microsoft rep about this issue and let him/her know it is a problem for you. The only way they fix these kinds of issues is customer feedback.

  4. JR 8 years ago


    I woulk like how connect my smartphone to office 365 if the user using smart card and require password?
    I’M istall ADFS 3.0 with MFA Azure and create app password, I’ts working with MS Outlook 2010 but when i add account app outlook in android require username and password, the choise to connect the azure MFA is not available in the wizard to add account office 365

    • Author
      Kyle Beckman (Rank 2) 8 years ago

      I don’t have any experience working with smart cards personally. Most people I know that do use them have those types of problems and are switching to some other form of 2FA that is more reliable. I would reach out to Office 365 support; they should hopefully be able to help you out.

  5. Dirnoz 7 years ago

    I use Outlook for iOS and Android, but my yahoo account, everyday send me email if log in unwanted in USA. I live in Indonesia. How to fix it?

    • Author
      Kyle Beckman (Rank 2) 7 years ago

      I’d recommend taking that up with Yahoo’s technical support for their email service.

  6. Ricardo 7 years ago

    Hello, a doubt, if the user loses the device and change the password, the e-mails will be visible for those who find the device? if the account the emails is disabled will be lost, right?

    • Author
      Kyle Beckman (Rank 2) 7 years ago

      I’m not sure how that would be any different than using the built-in mail apps on each mobile platform. The best practice is to require a PIN (or some other challenge like a finger print) to enter the device. If the device is lost, the only way to fully secure it would be to initiate a remote wipe.

  7. Tony Brock 7 years ago

    An issue I see is that our MDM product utilizes Powershell commands to allow or block devices based on the device ID. If our MDM issues a command which allows the Outlook app on a device controled by MDM, that user can then connect via Activesync with as many additional devices utilizing that same ID. These additional device connections are not brokered by our MDM solution, and therefore are not required to receive any of the policies we require prior to connecting to our email environment.

  8. Borisj 7 years ago


    Trying to create an Exchange account with the android version of this app works fine externally, but if the tablet is inside the local network (server name will resolve to the Exchange server’s local address) then it fails with a “check email and password” error.

    Any idea where I should start looking to fix this?


  9. Anon 7 years ago

    I work for a hospital, and we are not allowed to use any e-mail client other than Apple’s Mail if we use our personal iPhones to check e-mail.  The concern is PHI.  I don’t think that the server block iOS outlook, but I would be violating company policy if I used it.

    My phone has to be encrypted, and I would wipe it if completely if it were ever stolen.  I don’t like having my personal e-mail and my work e-mail in the same app.  (I worry that I would send a work e-mail from my personal account.)  So, I’d really like them to get rid of the credential storage.  I don’t know what we’re going to do when we have to go to Office 365.

  10. Giorgio 6 years ago

    Has Office 2016 and/or Outlook 2016 changed the way credentials are stored?  Is the newest version of the Outlook for Android and iOS different, two years after this article was written?

Leave a reply

Your email address will not be published.


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account