Conditional Access Policies Every Business Should Have

A good Conditional Access design is measured by outcomes: the right sign-ins are blocked, challenged, or restricted, while normal work stays predictable.

Your baseline should answer five questions for every important sign-in: who is signing in, from what device, from where, to which app, and at what risk level. If those decisions are inconsistent, you do not have a baseline; you have partial coverage.

Avoid building policies only in reaction to incidents: one for executives after phishing, one for SharePoint after an audit, one for a vendor after a scare. Conditional Access policies are cumulative. A user must satisfy all applicable grant controls, so unclear targeting and undocumented exclusions quickly become hard to troubleshoot.

Licensing matters. Conditional Access requires Microsoft Entra ID Plan 1, which is included with Microsoft 365 Business Premium and Microsoft 365 E3/E5. Risk-based user and sign-in policies require Microsoft Entra ID Plan 2, included with Microsoft 365 E5 and available as an add-on for other plans. Device compliance controls require Microsoft Intune. Microsoft Defender for Cloud Apps session controls require Defender for Cloud Apps licensing.

If you implement only a few controls first, start with privileged access, legacy authentication, and tenant-wide MFA.

Administrator accounts can reset passwords, grant mailbox access, consent to applications, change security settings, and access data indirectly. A compromised Global Administrator is not a mailbox incident; it is a tenant incident.

Create a dedicated admin policy that targets Microsoft Entra privileged directory roles, not only named users. Include roles such as Global Administrator, Privileged Role Administrator, Conditional Access Administrator, Exchange Administrator, SharePoint Administrator, Security Administrator, Intune Administrator, Application Administrator, and Cloud Application Administrator. Require the phishing-resistant authentication strength where possible: FIDO2 security keys, Windows Hello for Business, or multi-factor certificate-based authentication. If you need a transition period, use Microsoft Authenticator with number matching and additional context, and remove SMS and voice methods for privileged roles.

Block legacy authentication for all users. Legacy clients that use Basic authentication cannot satisfy modern MFA. POP, IMAP, SMTP AUTH, Exchange ActiveSync, older Office clients, and custom integrations should be inventoried and remediated. Exchange Online Basic authentication has been disabled for most tenants and protocols, but SMTP AUTH and non-Exchange dependencies can still create risk if you assume they are gone without checking.

Do not leave the tenant exposed for one scanner, copier, ticketing system, or accounting integration. Migrate it to modern authentication, use a supported relay pattern, or create a tightly scoped, time-limited exception with monitoring.

Requiring MFA for every user does not mean prompting every user constantly. Poor MFA design trains users to approve prompts. Good design challenges users when risk or context changes: new device, unfamiliar location, sensitive app, risky sign-in, or unmanaged session.

For a baseline, target all users and all cloud apps, then exclude only emergency access accounts and documented service accounts that cannot use MFA. Require MFA through Conditional Access rather than legacy per-user MFA. Conditional Access gives you clear targeting, exclusions, report-only testing, and sign-in log evidence showing which policy allowed or blocked access.

If you have Microsoft Entra ID Protection, add risk-based policies: require MFA for medium or high sign-in risk, and require a secure password change or block access for high user risk.

Use stronger authentication for higher-risk roles. A frontline user on a managed shared device may not need the same authentication strength as a finance approver or administrator. Every user needs MFA; the difference is authentication strength, frequency, and conditions.

MFA protects sign-in. It does not, by itself, stop data from being downloaded to unmanaged laptops, personal phones, or public browser sessions.

For sensitive apps, require a compliant device, a Microsoft Entra hybrid joined device, or both, depending on your device strategy. Apply this first to administrators, executives, finance, HR, and users with regulated data access. Include Exchange Online, SharePoint Online, OneDrive for Business, Microsoft Teams, Microsoft admin portals, Microsoft Azure Management, and key business applications.

Where a hard block would disrupt legitimate work, use session controls. For supported apps, app-enforced restrictions can allow browser access while limiting downloads. With Defender for Cloud Apps, Conditional Access App Control can monitor sessions and block downloads, uploads, cut/copy/paste, or other risky actions depending on the app and policy.

Be strict with admin portals. Admin access from unmanaged personal devices should be blocked in most environments. A stolen session token or malware-infected home device used for administration can turn a workstation compromise into a tenant compromise.

Country blocking can reduce noise, especially if your organization operates only in specific regions. It should not be your primary control.

Attackers can use VPNs, residential proxies, and compromised hosts inside allowed countries. Legitimate users may travel, use mobile networks, or connect through services that appear in unexpected regions.

Use named locations as one condition. Block countries where your users have no business need to authenticate. Require MFA or stronger controls outside trusted locations. Include unknown locations in your design if you use country-based rules.

Be careful with trusted office IP ranges. If office or VPN traffic bypasses MFA entirely, a compromised on-premises device or VPN account may become a password-only route into Microsoft 365. Trusted locations should reduce unnecessary prompts, not create an authentication downgrade.

Every baseline needs emergency access accounts. Use at least two cloud-only accounts with highly privileged roles, exclude them from Conditional Access, store credentials securely, and alert on every sign-in. Do not use them for daily administration. Test them periodically so recovery access works when needed.

Guest users need separate targeting. Require MFA for external users, or use cross-tenant access settings to trust MFA from partner tenants you explicitly trust. For sensitive SharePoint sites, Teams, or applications, restrict downloads, require compliant devices where feasible, or apply session controls. Review guest accounts regularly and remove stale access.

Service accounts are a common source of permanent exceptions. Exclude them only when necessary. Give each account the smallest permissions possible, block interactive sign-in where the workload does not need it, restrict by reliable locations when practical, rotate secrets, and move workloads to managed identities, workload identities, app registrations, certificates, or modern authentication.

Every exclusion needs an owner, reason, expiration date, and compensating control. Without those four items, it is not an exception; it is an unmanaged attack path.

Use report-only mode before enforcement. Review sign-in logs across a full business cycle, including remote work, payroll, executive travel, vendor access, and after-hours operations.

Pilot with a realistic group: IT, security, finance, executives, frontline users, and users with different device types. Do not pilot only with technical staff; they usually have cleaner devices and better authentication habits.

Track blocked sign-ins, MFA failures, device compliance failures, and helpdesk tickets tied to policy changes. A blocked malicious sign-in is success. Blocking payroll or executive access during a known business process is a rollout problem.

Name and document policies so intent is obvious. Use names such as "CA001 - Block legacy authentication - All users - Exclude emergency access" instead of "MFA Policy 2". Put the purpose, scope, exclusions, and owner in the policy description.