Microsoft Entra Conditional Access: A Practical Guide covers Conditional Access mechanics in general — policy structure, Report-only mode, break-glass accounts. This article goes one level more specific: the policy patterns that matter most for Microsoft 365 workloads in particular (Exchange Online, SharePoint, Teams), rather than Conditional Access as a generic identity control.
Microsoft 365-specific policy patterns
| Policy | Why It's M365-Specific |
|---|---|
| Block legacy authentication for Exchange Online | Legacy mail protocols (IMAP, POP, older Outlook clients) are a disproportionately common bypass path specifically for email access |
| Require compliant device for SharePoint/OneDrive | Data exfiltration risk is highest for the workloads that actually store organizational files |
| Session control: app-enforced restrictions for unmanaged devices | Allows limited, browser-only access (no download/print/sync) from personal devices, rather than a binary allow/block |
| Block or restrict Teams external access | Guest/external collaboration is a Teams-specific attack surface distinct from other workloads |
| Require MFA for Exchange admin center / SharePoint admin center specifically | Admin portals for these workloads carry outsized risk relative to standard user access |
App-enforced restrictions: the middle ground for unmanaged devices
A binary "block all unmanaged devices" policy is often too restrictive for organizations with legitimate BYOD or contractor access needs, while "allow full access from any device" leaves data exfiltration risk unaddressed. App-enforced restrictions offer a middle path: unmanaged devices get browser-only access to Exchange Online, SharePoint, and OneDrive, with downloading, printing, and syncing disabled — full functionality preserved for managed devices, limited functionality (not zero) for everything else.
This is often the single highest-value M365-specific policy
For organizations without full device management maturity yet, app-enforced restrictions deliver most of the data protection benefit of a full compliant-device requirement, with far less rollout friction — a reasonable interim step while broader device compliance is built out.
Guest and external access policies
Teams and SharePoint's external collaboration features are genuinely useful and also a distinct Conditional Access consideration — a policy scoped to "all users" may not correctly account for guest accounts, which authenticate differently and may not be covered by the same MFA/device requirements unless a guest-specific policy explicitly addresses them.
- Require MFA for guest accounts explicitly — don't assume a policy scoped to "all users" correctly covers guests by default; verify guest account behavior directly.
- Scope external sharing defaults conservatively — specific people, not "anyone with the link," as the SharePoint/OneDrive baseline default.
- Review active guest accounts periodically, removing access for completed external collaborations — the same access review discipline that applies to internal accounts.
Sequencing Microsoft 365-specific policies
Following the same Report-only-first discipline from the general Conditional Access guide, M365-specific policies should build on top of the baseline (all-users MFA, legacy auth block) already in place — not be layered in before that foundation is confirmed working. A reasonable build order: baseline policies first, then app-enforced restrictions for unmanaged devices, then compliant-device requirements as device enrollment matures, then workload-specific refinements (Teams external access, admin portal MFA).
Common mistakes
- Assuming a general "all users" MFA policy correctly covers guest accounts without verifying guest-specific behavior.
- Jumping straight to a full compliant-device requirement before device enrollment coverage is broad enough, causing unexpected lockouts — app-enforced restrictions are the better interim step.
- Leaving Teams external access unrestricted by default, missing a workload-specific attack surface distinct from email or file sharing.
- Not requiring MFA specifically for the Exchange and SharePoint admin centers, relying on the general admin-role policy to cover them without direct verification.
FAQ
Do we need separate policies for each Microsoft 365 workload, or one policy covering everything? A mix — baseline policies (MFA, legacy auth blocking) should apply broadly across all cloud apps, while workload-specific patterns (app-enforced restrictions, Teams external access) are naturally scoped to the specific application they protect.
How does this relate to Microsoft Purview data loss prevention? Conditional Access controls where and how access happens (device, location, session restrictions); Purview DLP controls what happens to the data once accessed (blocking specific content from being shared externally, for instance). They're complementary layers — see Microsoft 365 Security Architecture.
Does app-enforced restrictions require a specific license? This capability is tied to Entra ID P1 (the same tier required for Conditional Access generally) — confirm current licensing requirements directly with Microsoft.
Once these policies are deployed, how do we know they're still healthy months later? Deployment and ongoing review are different problems — see Conditional Access Policy Analyzer for a structured review methodology covering stale exclusions, break-glass verification, and policy conflicts that accumulate after initial rollout.