Key takeaway: "Access your email from anywhere" is the headline benefit of Exchange Online, and the biggest risk. The mailbox is on the internet, so the sign-in is the only door. Making it safe is a design job: pick which clients you allow, require multifactor authentication, block legacy protocols, decide what unmanaged and personal devices may do, control mobile access with app protection, add location and risk conditions, and watch the sign-in logs. This guide covers each decision, the exact settings, the PowerShell, the order to roll them out in, and the problems you will hit.
In This Article
- How Anywhere Access Works
- Decide What You Are Protecting
- What Users Do
- Step 1: Require Multifactor Authentication
- Step 2: Use Stronger Methods and Sign-In Frequency
- Step 3: Block Legacy Authentication
- Step 4: Limit What Unmanaged and Personal Devices Can Do
- Step 5: Mobile Devices and App Protection
- Step 6: Add Location, Risk, and Role Conditions
- Step 7: Turn Off Protocols Nobody Needs
- Step 8: Control Which Outlook Clients Connect
- Step 9: Monitor and Respond
- Recommended Rollout Order
- How to Check It Worked
- Troubleshooting
- A Short Decision Guide
With an on-premises Exchange server, "remote access" was a project: a VPN, a reverse proxy, a published certificate, and firewall rules. With Exchange Online, every user can reach their mailbox from any browser or phone the moment their account exists. That is good for business and for attackers. The goal is not to restrict access; it is to make sure the *right person on an acceptable device* gets in, and everyone else does not.
How Anywhere Access Works
The mailbox lives in Microsoft's datacenters. Every client talks to it over the internet using modern protocols:
| Client | Protocol | Notes |
|---|---|---|
| Outlook on the web | HTTPS | Any browser, no install |
| Outlook for Windows and Mac | MAPI over HTTPS (Autodiscover finds settings) | Cached copy of the mailbox on the device |
| Outlook for iOS and Android | Microsoft's cloud sync service | Supports app protection policies |
| Built-in mail apps on phones | Exchange ActiveSync | Less control; device-level security |
| IMAP, POP, SMTP clients | Legacy protocols | Often used by scanners, old apps, and third-party clients |
Authentication happens against Microsoft Entra ID. Conditional Access policies are evaluated at every sign-in, so they are the control point for everything in this guide. Exchange-specific settings add a second layer.
Decide What You Are Protecting
Before turning on settings, answer:
- Which users and roles need mail outside the office (everyone, field staff, executives, contractors)?
- Which devices are allowed: company-managed laptops, personal phones, shared kiosks?
- What happens if a personal device is lost? Can you wipe the work data only?
- Which locations are normal? Do you operate in specific countries only?
- What data is in mail (financial, health, legal)? That sets how strict you must be.
- Which systems send or read mail (scanners, line-of-business apps, mail archive, CRM)? They need a path that does not rely on a password.
Write the answers down. They become your Conditional Access policy set.
What Users Do
- Browser: go to
https://outlook.office.com, sign in, approve the second factor. Works on any modern browser. - Phone or tablet: install Microsoft Outlook from the app store, add the work account, and approve the security prompts. Use the Outlook app rather than the built-in mail app wherever you can, because Outlook supports app protection.
- Desktop: install Outlook for Windows or Mac from the Microsoft 365 portal and sign in. Autodiscover finds the settings.
- Offline use: Outlook caches mail locally. Set the cache window to match what you need. A shorter window means less data on a lost laptop.
Tell users what to expect: a sign-in prompt, an authenticator approval, and occasional re-prompts when they change network or device. Give them a short page on how to register their sign-in method, and what to do if they lose their phone.
Step 1: Require Multifactor Authentication
Passwords alone are the weakness. Credential stuffing, phishing, and password reuse account for most mailbox takeovers.
Registration first. Before enforcing, have users register methods in the Entra security info page. Use the Authentication methods policy to enable the Microsoft Authenticator app (with number matching), FIDO2 keys, and passkeys for stronger sign-in. Keep SMS and voice as a fallback only, because they are the weakest.
Create the policy. In the Microsoft Entra admin center: Protection, Conditional Access, Policies, New policy.
- Name it clearly, for example
CA01 - Require MFA - All users. - Users: include all users. Exclude your emergency (break-glass) accounts, and optionally service accounts that cannot do MFA and are covered by other controls.
- Target resources: all cloud apps, or at minimum Office 365 Exchange Online and the Microsoft 365 apps.
- Grant: require multifactor authentication.
- Enable policy: set to Report-only first.
- Watch the sign-in logs (the Conditional Access tab for each event) for a week. Fix surprises, then turn it On.
Break-glass accounts. Create two cloud-only accounts with long random passwords, excluded from all Conditional Access policies, stored securely, and monitored with an alert on any use. They exist for the day a policy locks everyone out. Test them every quarter.
Security defaults are a no-design alternative for small tenants that require MFA for everyone. They cannot be combined with Conditional Access; turn them off when you move to policies.
Step 2: Use Stronger Methods and Sign-In Frequency
- Authentication strength. Conditional Access can require a specific strength, such as phishing-resistant methods (FIDO2, Windows Hello for Business, certificate-based) for administrators and executives.
- Sign-in frequency. Decide how often users must re-authenticate on unmanaged devices (for example every 8 or 24 hours) and let managed, compliant devices stay signed in longer.
- Persistent browser sessions. Disable "stay signed in" on unmanaged devices, so closing the browser ends the session.
- Token protection and continuous access evaluation reduce the value of stolen tokens. Check the current availability for your licenses.
Step 3: Block Legacy Authentication
Legacy (basic) authentication sends a username and password with each request and cannot do MFA. Microsoft has turned basic authentication off for most Exchange Online protocols, but devices and apps can still try, and some tenants kept exceptions.
- Find who still uses it. In the Entra admin center open Monitoring, Sign-in logs, add the column Client app, and filter for *IMAP4*, *POP3*, *Authenticated SMTP*, *Exchange ActiveSync*, *Other clients*. Look at the user and the application behind each.
- Move them to modern authentication. Update Outlook, replace old mail apps, and change scanners and applications to a supported method (OAuth for SMTP, a connector for relay, or a dedicated mailbox with SMTP AUTH client submission where still supported).
- Block the rest. Create a Conditional Access policy: all users, all resources, condition Client apps: Exchange ActiveSync clients and Other clients, grant Block access.
Printers and scanners are the usual victims. Plan their replacement path, such as SMTP relay using a connector tied to your public IP, before you block.
Step 4: Limit What Unmanaged and Personal Devices Can Do
A browser on a personal PC, a hotel computer, or a friend's laptop can read mail. The risk is that attachments and cached content stay behind.
Outlook on the web policy:
# See current policies
Get-OwaMailboxPolicy | Format-Table Name, ConditionalAccessPolicy
# Allow viewing but block downloads on unmanaged devices
Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -ConditionalAccessPolicy ReadOnlyPlusAttachmentsBlockedThe setting does nothing alone. Pair it with a Conditional Access policy:
- Users: all users (or a group for the pilot).
- Target resources: Office 365 Exchange Online (and SharePoint Online if you want the same behavior there).
- Conditions: device filter or *Filter for devices* to apply only when the device is not marked compliant or hybrid joined, and client app *Browser*.
- Session: Use app enforced restrictions.
With ReadOnly, users can view and print-preview but cannot attach or download. With ReadOnlyPlusAttachmentsBlocked, users cannot open attachments in the browser either, only view them with web-based viewers according to the policy. Test both with a pilot account to see the exact behavior in your tenant.
Require compliant devices for full desktop access: create a policy that grants access only to devices that are compliant in Intune or Entra-joined. Combine it with the previous browser policy so personal devices get a limited web experience, and managed devices get everything.
Step 5: Mobile Devices and App Protection
Phones hold mail, so decide how much control you need.
| Approach | Controls | Impact on the user |
|---|---|---|
| Outlook app + app protection policy (MAM) | PIN, encryption of work data, block copy to personal apps, selective wipe of work data only | Low; the phone stays personal |
| Fully managed device (MDM/Intune) | Entire device compliance, wipe, apps | High; used for company-owned devices |
| Built-in mail app (ActiveSync) | Limited device policies; weak data separation | Convenient but harder to protect |
A common design is: require the approved Outlook app for phones (via Conditional Access Require approved client app or Require app protection policy), block ActiveSync for personal devices, and manage company phones with Intune.
Admins can inspect and act on devices:
Get-MobileDevice -Mailbox jsmith@contoso.com | Format-List DeviceModel, DeviceOS, FirstSyncTime, DeviceAccessState
# Retire access for one device
Remove-MobileDevice -Identity "device-id" -Confirm:$false
# Remote wipe (sends a wipe command; use with care)
Clear-MobileDevice -Identity "device-id" -NotificationEmailAddresses admin@contoso.comIn the Intune admin center, selective wipe removes only the work data from an app-protected personal phone.
Step 6: Add Location, Risk, and Role Conditions
Once MFA and device rules exist, add targeted controls:
- Named locations and country blocks. Define your offices and countries where you operate. Block sign-ins from countries where you have no staff or customers, or require stronger controls from them. Treat this as noise reduction, not complete protection, because attackers use VPNs.
- Sign-in risk and user risk (Entra ID Protection). With the right license, require MFA on medium sign-in risk and a password change on high user risk.
- Admin protection. Require phishing-resistant MFA and compliant devices for administrator roles, and separate admin accounts from daily accounts.
- Guests and external users. Apply MFA and terms of use to guests accessing shared mailboxes or Teams.
- Impossible travel and unfamiliar sign-ins. Review these in the risk reports.
Step 7: Turn Off Protocols Nobody Needs
Every protocol is another door. Disable the ones a user does not need:
# One user
Set-CASMailbox -Identity jsmith@contoso.com -PopEnabled $false -ImapEnabled $false -SmtpClientAuthenticationDisabled $true
# See who has POP/IMAP enabled
Get-CASMailbox -ResultSize Unlimited | Where-Object { $_.PopEnabled -or $_.ImapEnabled } |
Select DisplayName, PopEnabled, ImapEnabled
# Defaults for new mailboxes
Get-CASMailboxPlan | Format-Table Name, PopEnabled, ImapEnabled
Get-CASMailboxPlan | Set-CASMailboxPlan -PopEnabled $false -ImapEnabled $falseAlso review organization-level SMTP AUTH: Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled. Only enable it per mailbox for the devices that need it.
Step 8: Control Which Outlook Clients Connect
- Outlook versions. Block or warn about unsupported Outlook versions that do not support modern authentication. Check your Outlook versions in the Microsoft 365 apps admin center.
- Outlook on the web features. Control features per policy:
Set-OwaMailboxPolicyhas options for attachments, offline access, and the ability to add personal accounts. - Autodiscover and connection problems are covered in pushing Outlook Autodiscover settings.
- Third-party apps. In the Entra admin center review Enterprise applications, User consent, and restrict users from consenting to apps that request mailbox access.
Step 9: Monitor and Respond
- Sign-in logs show every authentication with the Conditional Access result. Alert on spikes of failures and on successful sign-ins from new countries.
- Risky users and risky sign-ins in Entra ID Protection.
- Defender for Office 365 and Defender XDR alerts for suspicious sign-ins, mass downloads, and unusual forwarding.
- Audit logs for mailbox access by non-owners.
- A response plan: disable the account, revoke refresh tokens (
Revoke-MgUserSignInSession), reset the password, review rules and delegates (see inbox rule audit), and check what was accessed.
Recommended Rollout Order
- Inventory legacy sign-ins and protocols.
- Create break-glass accounts and test them.
- Register MFA methods for all users.
- Turn on MFA in report-only, then enforce.
- Move apps and devices off legacy authentication, then block it.
- Restrict unmanaged device web access.
- Roll out Outlook mobile with app protection; block ActiveSync for personal devices.
- Add location and risk policies.
- Review monthly.
Pilot each step with a small group (IT first, then one department). Communicate before each change, and keep a rollback plan.
How to Check It Worked
- In a private browser window on an unmanaged computer, sign in and confirm you are challenged for MFA.
- Open an attachment and confirm it follows the restriction.
- Use the What If tool in Conditional Access to simulate a user, app, device, and location.
- Try a sign-in with a legacy protocol (for example a test IMAP client) and confirm it is blocked.
- Confirm in the sign-in logs that each policy shows *Success*, *Not applied*, or *Failure* as expected.
- Lose a test phone and practice the wipe.
Troubleshooting
| Symptom | Likely cause |
|---|---|
| Users locked out after MFA enforcement | No registered method, or the policy affects the registration page. Use a temporary access pass |
| Everyone locked out | A policy mistake. Use a break-glass account and switch the policy to report-only |
| Scanner or app stops sending mail | It used basic authentication. Move it to a supported method |
| Attachment restriction has no effect | The Conditional Access policy with app enforced restrictions is missing or out of scope |
| Phone cannot add the account | Policy requires an approved app or compliant device |
| Outlook keeps prompting for a password | Stale credentials, a conflict with a second profile, or modern authentication disabled |
| Mailbox missing on a new device | Autodiscover issue, wrong account type, or user not licensed |
| Sign-in blocked from a country by mistake | Named location policy too broad; add an exception for travelers |
A Short Decision Guide
- Small tenant, no Conditional Access: security defaults, then plan the move to policies.
- Personal phones: Outlook app with app protection, no ActiveSync.
- Unmanaged PCs: web access with downloads blocked.
- Executives and admins: phishing-resistant MFA and compliant devices.
- Old scanners and apps: modern replacement or a controlled relay before blocking legacy sign-in.
Related guides: Exchange Online protection, inbox rules, and delegate access.
Portal paths, license requirements, and available conditions change over time, and I have not tested these settings in your tenant. Use report-only mode, pilot groups, and Microsoft's current documentation before enforcing anything. If you want a second pair of eyes on your sign-in and device controls, get in touch.