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.
One issue I am having with Outlook for iOS and Android with an Exchange on-premise environment is the ability to report on what type of device is running the app. EAS reports the device model, type, friendly name, OS, and user agent as “Outlook” or some variation to that effect. I’m guessing this has something to do with the single device ID per user.
Do you know of a way to report on the actual device OS or model when the Outlook app is being utilized to connect to EAS?
Hi, I found this page after discovering the proxy behavior of Outlook for Android even on IMAP accounts. This is freaking me out, as I do not want my e-mails or credentials passing through any third party. When I installed the software I did not consent to having my credentials stored on any remote device, nor having my e-mails scanned. I feel this behavior on IMAP is a disturbing invasion of privacy, and I will be uninstalling the application.
Thanks very much for explaining how Outlook works. We have Exchange Server 2010 on-premises. Most of our users access their Exchange email from desktops on the LAN using MS Outlook on Windows 10.
Our firewall blocks these users from accessing Exchange except from their desktops on the LAN.
Now, these users have Android Tablets to be used within our premises (on the LAN). Since Outlook for Android is far superior to OWA, our users prefer Outlook. However, our firewall is blocking them from retrieving Exchange emails, even though it seems crazy to go to the Cloud to get their Exchange email which resides on the LAN. Is there another option for Android users to retrieve on-premises Exchange email?
If we go with the Outlook for Android option, would appreciate any help on what IP or websites these Microsoft Servers are on – our firewall will need to open them up so these Android users can connect to them in order to access their Exchange email.
If you use the native mail app on Android (or iOS for that matter), and your ActiveSync virtual directory is mail.domain.com, and mail.domain.com resolves in your internal DNS directly to the Exchange server, then mobile devices and tablets on your wifi LAN would just connect directly to Exchange.
If you want to use the Outlook iOS/Android app, or otherwise allow external access, you’ll need to open up TCP 443 access from the internet. I don’t know specifically which IP addresses Microsoft’s cloud service for Outlook will be connecting from, or even if that is documented anywhere other than the Office 365 IP address ranges documentation that they’ve already published.
I am having trouble setting this up on my iPhone?
Has anyone else seen this? iOS 10.0.2 on iPhone 6s with Exchange 2010. Outlook for iOS 2.8.0
1) Create a new calendar event in Outlook for iOS on the iPhone and invite someone.
2) Go to Outlook on your desktop PC and open your meeting. Click Forward and add a new attendee.
3) Notice that it will specify From: username on behalf of user@domain – it does not recognize your Outlook iOS user as your Outlook user.
4) Try to send. Either you get a popup saying “You do not have permission to send the message on behalf of the specified user.” or an undeliverable notification after clicking send.
Any ideas? I see that Outlook for iOS 2.9.0 came out yesterday 1/23/2017 and I am about to try that.
It appears that 2.9.0 has the same issue.
You can contact support directly via the app itself if you think you’ve found a bug.
Is it possible to turn off the “SSL Encryption” for Outlook for Android? I am trying to add an IMAP e-mail address to my handheld Samsung Galaxy S5 using Outlook for Android 2016 and I continue to get an error message suggesting my “mail server certificate is invalid”.
I don’t think so. What you should do is fix your IMAP SSL so that you can use it securely. IMAP transmits creds in the clear so the SSL encryption is very important.
I recently stumbled upon this “problem”. The reason for me noticing that the traffic was not following the expected path was the installation of a new firewall. This new firewall allows me to block traffic from certain regions. In my case I only allowed OWA/ActiveSync traffic to my on premises Exchange Server from the Netherlands.
Several days after applying this rule the first users with an Android phone and Outlook App started complaining. The Outlook App didn’t download any new email from the time I applied the rule. Old emails are still visible. I didn’t expected the new firewall rule created this problem so I started removing the App and data from the phone. After reinstalling the App the old email immediately reappeared! Yes, immediately and it was up-to-date until the date and approximately time of applying the firewall rule. So the mailbox was lasted synced on the 8th of June and the email was still stored on Microsofts servers on the 14th of June! That’s more than 72 hours and not just credentials!
Maybe there’s an error in my findings. But it seems to me that something is wrong with the way this App works!
As far as I know, as long as the app on the device is still connecting to Microsoft’s servers, they will retain data/creds/OAuth tokens/anything else necessary. It’s only when you remove the app, or the account from the app, or the app stops connecting to their servers at all, that you’ll trigger a removal of cached data.
So everything you describe there is consistent with how this app works. Whether that is “wrong” or not is a subjective matter 🙂
Thanks for the reply. Your right. The App is working fine.
What I meant or should have said was it’s wrong (in my opinion) that it’s not clear to the end-user that there credentials and in particular messages are stored on a different server then the company server. And this server is located in de US etc. This remains a hot item.
But that’s actually something for a different, non-technical, discussion topic.
So we don’t trust Microsoft (and their cohorts) with our cached user credentials, and now we’re going to deny users the ability to use this client for ‘security reasons’. This fits in perfectly with my suggestion that we take away all the users’ pens and Post-It notes, in case they write their credentials down and stick the note inside a desk drawer. Also, rather than send sensitive data across God-knows-what allegedly ‘encrypted’ private network connections, my users connect their notebooks together via RS232 serial port to exchange data. You can just never be safe enough.
Who is “we”? I trust Microsoft and haven’t blocked anybody from using this app.
Paul – I used feedback on the app to express surprise over the credential storage in the cloud thing and response from MSFT was that I’m misinformed. I understand MSFT updated the app to eliminate storing credentials on MSFT servers but the article says it works with O365 and makes no mention of exchange. Can you clear up whether anything really changed for a normal exchange active sync users? I want to use the app to connect to my corporate exchange server just like the stock iOS app but I can’t figure out if it really works that way or not. I like the Outlook app so much better than Apple’s version so I’m hoping for good news.
Correct, O365 no longer stores creds. Exchange still does, as far as I’m aware. And several of the other supported services use OAuth instead of cred storage.
We’re implementing Office365 MDM and have run into an issue where devices can access mail via the Outlook app if they configure as an Exchange account (rather than O365) even if that device isn’t enrolled in MDM. We’re fine with accessing via Outlook app for the time being, but need to prevent this circumvention – any thoughts?
Thanks a lot Paul
Hi Paul, many thanks for this tech article, but one important issue about Outlook for iOS and Android is not technical, it´s about the license terms, it´s impossible to access (for commercial use) an on premise Exchange Server with an Outlook for iOS/android App…
So wich Apps do you think could be the best for Enterprises with Exchange on premise?
Since I’m not fluent in license-ese I’ve sent a query off to Microsoft to see what the real intent of that licensing clause is.
Yes, you’re correct, Outlook on iOS/Android requires an Office 365 license that includes the rights to use the Office mobile apps.
So, in the absence of that license, I would personally just use the native email app on iOS.
Thanks for the informative article. Now I worry about this possibly being a breach in my company’s IT policies, since I’ve already downloaded and started using the app on two different personal devices. What kind of information can my IT department retrieve from me signing in with multiple devices? I know using the native iOS and Android apps they can see exactly what devices are connected to Exchange ActiveSync and have administrative control. Can they see both my personal phone and tablet within Exchange logs? And can they have administrative control over these devices?
You should talk to your IT department about that. I can’t advise you what they can or can’t see, and whether your corporate policies allow or disallow the use of the app.
I would love to know how it plays with third party MDM solutions since those are required to use the DEP program in a corporate setting. If you are using corporate iPhones and the DEP program along with an MDM solution I do not believe the Outlook app would play well with them.
Thanks a lot for this useful article!, … but…
Isn’t it the way push notification works for iOS and Android: they all use a proxy Server (Google Cloud Messaging or Apple Push Notification Service) which will contact the on premise Exchange Sever on behalf of the User (and therefore they use the user credentials)?
So it looks there is no difference to the Outlook App and their relaying “Microsoft Servers” in the picure above…
Thanks a lot for any light in the darkness 🙂
Great article as I’m having a difficult time with the stock mail app continuously giving me messages that it can’t connect to the server.
Now while I’m not connected to or getting email from a corporate server, what are your thoughts on the use of this app for the average joe just getting their email and using this as their standard app? Does this cloud based service pose a risk for us or are the concerns really just for enterprise level use? Little has been mentioned about the rest of us that may use this app. Just wanted to read your take on it. Thanks.
I think it’s fine. I use the app for both business and personal email. Some of the services use OAuth anyway which is different.
I was actually hoping for some elaboration on the argument of “Data stored in the USA”. Especially today’s ruling by the European Supreme Court (Case C-362/14, Schrems v Data Protection Commissioner) regarding this, could potentially cause a proverbial landslide for this kind of technology.
The servers the app connects to are hosted in the USA. As far as I know they haven’t deployed any to other regions.
I’m not a lawyer so I can’t comment on European Supreme Court rulings might mean.
Paul, thanks for the article. So the servers are in the USA, but whose servers are they? If I recall correctly, initially AWS was being used. Is that still the case? Or is everything under Microsoft’s wing now?
AFAIK the underlying infra is still AWS, but Microsoft controls and manages the servers (VMs etc).
I’m as happy with that as I would be running my own enterprise services and data on AWS, which is to say I’m perfectly fine with it.
Is the Outlook client for Windows 10 Phone also connecting to the cloudservice for storing credentials?
No, just iOS and Android.
Can this app be controlled with MDM, as a lot of organisations are moving to this, for understandable reasons.
We also have a customer using certificate based authentication. I’m guessing that with the authentication mechanism that Outlook for iOS uses, this will never be supported?
It can be managed with the Office 365 MDM features. Not sure about third party MDM though.
Nice read. I admit that I haven’t used Outlook for IOS or Android, but I’m wondering how it compares to Good?
Thanks for another great article Paul!
Regarding this part:
“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”
In the end I guess activesync uses a token to authenticate with the server and is renewed/checked after 24-72 hours?
Then I have a scenario:
A user gets fired from the company and account is locked and password reset on the same day. User has during his worktime synced e-mail on multiple devices.
Since token is in use for authentication, it will mean that user still can receive and send emails.
We have tested (office365) and confirmed that this is a weakness and it also goes for Outlook client.
Does not affect OWA
At the moment there is no solution, other than to manually disable MAPI and ActiveSync on users mailbox.
Downside of disabling MAPI is for other users that have added this mailbox as additional mailbox in outlook, and also those who have added users calendar.
Outlook will then freeze and hangs.
Is there anyway we can set lower “renew time” , then 24-72 hours?
Need hlep as we just moved our company emails server from exchange 2007 to exchange 2013 . Now we are facing problem as we are not able to configure exchange account through Outlook App in any andriod or Ios phones .
We have other exchange server with 2007 can connect outlook app as exchange account .
You should run the ActiveSync test from ExRCA.com
I wish Apple would let folks chose their default email app, then I would love Outlook for iOS. Not sure if anything changed in iOS9.
How do you folks use the app? Do you still keep an account setup on your phone that just doesn’t sync email so you can use the built in app functions to share links, photos, etc?
I have Outlook added to my Share list in iOS so I can share photos, links, etc with Outlook much as you can with Twitter, Facebook, etc.
“Nine for Exchange” is much better than “Outlook for Android”. But not free. But have support of photos from GAL, per-folder settings, beautiful material design and so on. Definitely, Outlook for Android is not “best mobile client for Exchange”
The only reason I don’t use it currently is that I have a lot of subfolders with rules that direct mail into those subfolders. I would like to have a home screen where it shows me only those emails. I do not keep everything in the inbox. Basically I’m looking for an interface similar to that of a blackberry or touchdown (which I currently use).
Great article. Thank you!
I did want to share another hang up for me: After setting up an IMAP account, I have about a half dozen addresses that I use (to send mail as) with multiple FROM addresses. I have found no way to add each of these to my 1 account. Apple allows this with the Mail app using commas between each. I tried this in Outlook and it doesn’t appear to work.
We are trying it to connect to our ActiveSync published service. We don’t see any connections from unknown IP addresses. We see connections only from the internet facing connection of the iPad. From my perspective, the App is not connecting to a cloud service that then connects to our activesync service. Can you clarify?
Everything I know about the architecture of the application is in the article above, and the resources I link to. I don’t know why you’re seeing a different result, unless you’re using the wrong app.
I’m using this now and may remove it due to 2 reasons mentioned.
1. Is the encrypted data stored in by Microsoft or by Acompli on AWS?
2. If Microsoft, with our new DC’s now running in AU why does the data still have to go offshore? That’s a legitimate concern for many Enterprises.
Its a nice enough app but why can’t it just do what it does connecting directly to your exchange server????
1. AWS is the cloud environment where the server(s) are hosted right now. That’s where they were deployed when the app was developed by Acompli, before the Microsoft acquisition. Microsoft has already stated that moving the servers to Microsoft’s cloud is a priority for them.
2. Because that’s how the app works right now. Whether that changes in future is unknown. If your org has concerns about this then you should block the app.
3. All the intelligence (eg indexing, sorting critical from non-critical mail, resheduling non-urgent email to reappear later) occurs in the cloud. This allows them to develop rapidly and keep the smartphone app code lightweight and more stable.
Thanks for the article. I think there is some work to do here before I replace the native mail app, but it’s a good start.
One bit of functionality that I noticed missing…you can’t book resources through the calendar. maybe my org is the only one that relies on this, but not being able to book a room for a meeting means I’m still heading back to my desk to finish up instead of taking care of things while on the go.
Another great article Paul, bit of a deviations from your Engineer/Operations stuff 🙂
You say that you trust Microsoft to securely store my data including my credentials. Problem is that the servers are not Microsoft’s. Your data is stored on Amazon Web Services servers setup by Acompli. While I may trust Microsoft’s security, I don’t trust a company I know nothing about.
I am sure Microsoft will, over time, move the back end servers to its own server environment but until then I won’t be trusting my mail to the new Outlook client.
AWS has “bring your own key” encryption options for customers who don’t want to use their standard KMS. So it’s entirely possible that Acompli/Microsoft has set up the cloud servers using that BYOK option and AWS has no access to the data. Of course it is also entirely possible that normal KMS was used and AWS does theoretically have access to the data.
Personally I trust AWS to securely host my data as much as I trust Microsoft. But you, or anyone else, can err on the side of caution and by all means flag it as a risk for now.
Meanwhile, Microsoft has stated that they are moving the cloud aspects of Outlook for iOS and Android to Microsoft’s cloud ASAP. Hopefully we’ll see some confirmation in the near future that this has completed.
Not so much concerned about AWS security, more about Acompli’s. Security is hard to get right and even the big players (see Yahoo, Adobe etc) have been hacked. The sooner that Microsoft moves the back-end to their cloud the better. I don’t know why they didn’t wait until the servers were directly under their control before releasing the client under their name.
BTW I’ve just updated the article above with some more info from Microsoft on the password and data storage.
Coming back to this really old post, is it still correct tha credentials are stored “somewhere”, or did Microsoft rework the App so that it now directly talks to On-Premise Exchange installations?
Here you go:
I just read over the article i think you hit on a lot of very valid points. I found your view on how the Microsoft not respecting a company policy spot on. That said i think Microsoft made a smart acquisition as a lot of companies would appreciate a Microsoft email client that can support B.Y.O.D.