Which Conditional Access policies should every business have?

Key facts

• Conditional Access needs Microsoft Entra ID P1; risk-based policies need P2.
• Always exclude two monitored emergency access accounts from every policy.
• Report-only mode and the What If tool show impact before you enforce.
• Blocking legacy authentication removes a common path around MFA.
• A small set of broad policies is easier to maintain than dozens of narrow ones.

The core policy set

Conditional Access is the policy engine in Microsoft Entra ID that decides, at each sign-in, whether to allow access, require more proof, or block. The set below covers the most common identity attacks for small and mid-size organizations. Microsoft also publishes policy templates in the Entra admin center that match most of these.

Risk-based policies with Entra ID P2

If you have Entra ID P2, which is included in Microsoft 365 E5 and available as an add-on, Microsoft Entra ID Protection scores sign-ins and users for risk. Two policies are worth turning on.

A sign-in risk policy requires MFA, or blocks, when a sign-in looks suspicious, such as one from an anonymous IP address or with token anomalies. A user risk policy requires a secure password change, or blocks, when a user account shows signs of compromise such as leaked credentials. Microsoft now recommends configuring these as Conditional Access policies rather than the older standalone Identity Protection policies.

Exclusions that are safe, and ones that are not

Every policy should exclude two cloud-only emergency access accounts with strong, separately stored credentials, ideally protected with FIDO2 security keys. Alert on any sign-in by those accounts.

Other exclusions should be rare, documented and time-limited. Common bad exclusions include whole departments that complained about MFA, a service account that turned out to have mailbox-wide rights, or a trusted location that covers every office and VPN range. Workload identities and service accounts are better handled through managed identities, certificates or workload identity policies than by being excluded from user policies.

How to roll out without locking people out

Build each policy in report-only mode first. Leave it for one to two weeks and review the Conditional Access insights and reporting workbook and sign-in logs to see who would have been blocked or challenged.

Use the What If tool to test edge cases such as a contractor on a personal device or a scanner that sends mail. Communicate before enforcing user-facing policies, and run an MFA registration campaign so users have a method set up before the requirement turns on.

• Create and test break-glass accounts before any policy goes live.
• Check sign-in logs for legacy authentication and fix those clients first.
• Pilot with IT, then a friendly department, then everyone.
• Name policies consistently so the set is easy to audit later.
• Export policies as JSON or document them so changes can be tracked.

Microsoft-managed policies and keeping the set tidy

Microsoft now creates some Microsoft-managed Conditional Access policies in eligible tenants, such as MFA for admins. Review them, keep them if they fit, and make sure they do not conflict with your own.

Review the whole policy set at least quarterly. Look for exclusions that have outlived their reason, policies left in report-only mode for months, and apps that were added without coverage. A smaller number of broad, well-named policies is easier to reason about than a long list of overlapping ones.

How Accred Consulting approaches it

Accred Consulting designs Conditional Access around your users, devices and apps, not a generic template. Discovery reviews sign-in logs, legacy clients and licensing, and the proposal sets scope, fixed price and timeline. US-based specialists build policies in report-only mode, set up break-glass accounts, run MFA registration and enforce in waves with structured check-ins. For a roughly 350-user manufacturer, MFA and Conditional Access went live in 6 weeks. Handover includes a documented policy set and knowledge transfer so your team can maintain it, with optional support retainers.

Track record: 475+ client projects, 2,000+ migration workstreams and 210,000+ users migrated by a US-based team. Company facts · Case studies

Related questions