Microsoft Outlook is available for iOS and Android mobile devices. Outlook for iOS and Android was originally called Acompli, created by the company of the same name before they were acquired by Microsoft in December 2014. Microsoft re-branded Acompli and launched it as Outlook for iOS and Android in January 2015, and now generally refers to it as Microsoft Outlook as part of their consistent branding for Outlook across all platforms.
Managing Email, Not Just Accessing Email
A major gripe with many mobile email applications, particularly the native mail apps that ship with mobile operating systems like iOS and Android, is that they deliver only basic access to email and calendars. Very little functionality exists in those native apps to help end users manage their email, and historically many of the third party email apps for mobile devices have had poor user interfaces and have not improved productivity at all.
In a world where email is supposedly dead, yet more and more people are drowning in the ever increasing volume of email they receive, it is not surprising to see specialized mobile email applications arrive on the scene. These apps put features in the hands of users to allow them to manage their email better, sort through the noise, and (for some people) achieve “Inbox Zero”. This is a good thing for users, and I applaud Microsoft for getting into this space rather than live with the user experiences that other applications are providing.
I’ve been using Microsoft Outlook on my iPhone and iPad since it was released in January 2015, and it has won me over. Initially the experience was a little rough around the edges, but Microsoft has maintained a steady pace of updates and now Outlook is very fast and stable on my devices, and makes high volumes of email quite manageable.
So I’m happy with it from a functionality point of view, but does that make it suitable for enterprises who also need to assess mobile applications from a security point of view?
Security for Microsoft Outlook on iOS and Android
When Outlook launched there was a lot of noise made about the way that the application works, with particular concern around the storing of user credentials.
In short, Outlook for iOS and Android connects to a server or service hosted in the cloud. It does not connect directly to your corporate Exchange server, Office 365 tenant, or other email services (the app supports Outlook.com, Yahoo!, and Gmail).
When you configure an account in Outlook for iOS and Android, the cloud service connects to your mailbox on your behalf, accesses your email for the purposes of indexing and sorting (for example, to determine what should go in your “Focused” inbox view), and then the app on your mobile device downloads the messages from that cloud service. Cynics would say this is akin to a “man in the middle” attack. Which it is; except it is not malicious.
Here’s a more detailed explanation from various updates Microsoft has released for Outlook:
- Outlook uses OAuth for Outlook.com, OneDrive, Dropbox, Box and Gmail.
- Outlook also uses OAuth for Office 365 thanks to the ADAL support added to Outlook in June 2015.
- Exchange Server on-premises does not support OAuth, nor does Yahoo! or iCloud, so Outlook uses basic authentication for those services. Encrypted credentials are passed to the Microsoft cloud service and stored there for ongoing access. You can read more about how this is securely transmitted and stored here.
There are legitimate concerns to be had here for many enterprises.
- Credential storage. For Exchange on-premises, and any other service that doesn’t support OAuth, encrypted credentials are stored by Microsoft. I trust Microsoft to securely store my data including my credentials, and so do thousands of organizations around the world (take Microsoft Account/Live ID, Office 365, DirSync with Password Sync as examples).
- Corporate policy violation. Providing your user credentials to a third party is a breach of many IT usage policies, and the app doesn’t make clear to end users that this is occurring. In fact the typical end user would have no idea that this is happening.
- Data is stored in the USA. For organizations with data sovereignty or regulatory issues with off-shore data storage this will be a problem.
Microsoft has committed to addressing customer concerns as best they can as Outlook development continues. But given the reliance on this architecture for the features of the application itself, it’s pretty safe to assume that the architecture of Outlook for iOS and Android is not going to change, and that the cloud service acting as a proxy between the user and their mailbox will remain in place.
For enterprises that have a problem with any of the concerns above you can block or quarantine Outlook from your Exchange or Office 365 mailboxes by following the steps here to create an ActiveSync device access rule:
As for any concerns about long term credential storage, for example if an account becomes inactive, Microsoft has advised that the credentials for inactive accounts are purged after 24-72 hours.
Mobile Device Management for Outlook for iOS and Android
I spent some time examining Outlook for iOS and Android from a mobile device management perspective. I found a few interesting things that I wanted to expand on here.
Initially Outlook for iOS and Android would successfully connect to mailboxes that have ActiveSync mailbox policies in place that require things like PIN codes and device encryption, even if the mobile device itself did not meet those requirements. This is a classic example of a weakness in the ActiveSync protocol in that it basically trusts the device or app to be honest about its compliance with policies.
This is not automatically a problem. The default policies for Exchange 2013 and Office 365 are quite permissive and do not require PINs or device encryption. So any organization still running those default policy settings potentially has no problem with Outlook for iOS and Android’s behavior. On the other hand, I don’t know of any customers who would allow such a weak mobile device policy, and any that are still running that weak default policy tend to be unaware that they are doing so.
Today the Outlook application correctly enforces PIN/passcode requirements, but any users who installed the first version of the app and have not updated since then could still be avoiding policy compliance.
Due to the “man in the middle” approach being used with Outlook for iOS and Android there will only ever be one mobile device association visible for the user, no matter how many different devices they have installed the app on.
This is fine, if a little awkward to report accurately on, until someone loses a device. Imagine an executive who has the app on their phone and tablet. The tablet is lost in the back of a taxi, but they still have their phone. The IT team has to make a decision – issue a remote wipe for the single “device”, which will wipe the account data from every device the app is installed on. Or, do nothing.
There’s no right answer there. But it does lead us into the next problem.
Remote Wipe Behavior
I was pleased to see that in my testing the remote wipe does actually work, and it does only remove the specific account from the Outlook for iOS and Android app. Other accounts configured in the app are untouched, as is the rest of the data on the device itself. This type of “selective wipe” is perfect for BYOD environments. But there’s still a problem with how it works with this app.
Unfortunately, the app (or the cloud service in the middle) never reports back with the result of the wipe in every test I have performed. No matter whether the remote wipe was request was successful or not, it will remain in a “pending” state forever. Or until the wipe request is removed.
In the earlier example of the executive with two devices this presents a problem. All their devices are blocked from connecting due to the remote wipe request. If they want to keep using their phone then the remote wipe request needs to be removed, without anyone knowing whether the lost tablet was successfully wiped.
There may be a workaround available whereby the app is completely removed and reinstalled, which gives it a new device ID and circumvents the problem. But that is still an awkward solution, and doesn’t solve the issue of the remote wipe result never being reported accurately.
This falls more into the user experience side of things rather than being an architectural concern, but I’ll call it out here anyway.
When some versions of Outlook for iOS and Android are blocked, for example by using ActiveSync device access rules as mentioned earlier, it interprets this as an authentication failure and re-prompts for credentials. The other option given to the user at that time is to delete the account from the app. However, it is not clear whether this deletes the account only from the app, or also from the cloud service that is storing credentials and polling for email on the user’s behalf.
Other mail apps such as the native Mail app on iOS simply interpret a block as a “failure to connect to server”, which is also not a great user experience but is possibly better than falling into a cycle of re-entering credentials or removing the account entirely.
In my view Microsoft has done the right thing in acquiring this application from Acompli and launching it as Outlook for iOS and Android. The world is crying out for better email management apps and Microsoft needs to be in this space. After a bumpy start the application has improved in terms of features, user experience, and security as Microsoft continues to release frequent updates.
I consider this application ready for enterprise. It has a few caveats that some organizations will consider deal breakers, but for most businesses Outlook on iOS and Android is good enough today to be considered a secure and user friendly mobile email application.