A baseline set of Conditional Access policies

Conditional Access can lock everyone out of a tenant, including the people who wrote the policy. Microsoft's guidance is to create at least two emergency access accounts before deploying anything. They should be cloud-only accounts on the tenant's .onmicrosoft.com domain, not synced from on-premises Active Directory, permanently assigned Global Administrator, and protected with a phishing-resistant method (Microsoft recommends a FIDO2 passkey) that differs from the method your everyday admins use.

Put both accounts in a dedicated group and exclude that group from every policy that blocks or restricts sign-in. Report-only policies don't need the exclusion. Then set up an alert on every sign-in by those accounts and test them at least every 90 days, as Microsoft recommends. Store the keys in separate, secure locations.

These three replace what security defaults gave you, with the ability to manage exceptions. All require at least Microsoft Entra ID P1.

• Target admin policies at directory roles, not named people, so anyone added to a role later is covered automatically.
• Before CA02 goes live, register a passkey, security key or Windows Hello for Business for every admin. Our guide to phishing-resistant MFA covers the rollout.
• Before CA03, find what still uses legacy authentication in the sign-in logs. Old printers and scripts are the usual surprise.

Once the identity basics are solid, add policies that look at where and from what people sign in:

• CA04 Block countries you never work from. Microsoft suggests creating a named location of allowed countries and blocking everything outside it, with the break-glass accounts excluded. Remember that travel and VPNs will trip it; give staff a way to ask for a temporary exception.
• CA05 Require a compliant device for sensitive apps. This needs devices enrolled in Intune with a compliance policy. Start with admin portals or finance systems, not everything at once.
• CA06 Require approved apps or app protection on mobile. Useful for personal phones where you don't want full device management.
• CA07 Secure MFA registration. Restrict where users can register security info (for example, only from a trusted location or compliant device) so a stolen password can't be used to enrol an attacker's phone.
• CA08 and CA09 Risk-based policies, if you have Entra ID P2: require a secure password change for high user risk and MFA or block for high sign-in risk.

1. 01

   Create every new policy in Report-only

   Templates start this way by default. A report-only policy evaluates real sign-ins without enforcing anything.

2. 02

   Wait at least a week

   Microsoft's deployment plan recommends a week in report-only before enforcement. Monthly processes, such as payroll exports or a scanner used once a week, need time to show up.

3. 03

   Review results

   In Entra sign-in logs, open sign-ins and select the Report-only tab, or use the Conditional Access insights and reporting workbook (requires sign-in logs sent to a Log Analytics workspace).

4. 04

   Pilot, then expand

   Turn the policy on for IT staff, then a pilot group, then everyone. Tell users what will change and when.

5. 05

   Switch to On

   Move Enable policy from Report-only to On and watch sign-in failures closely for the next few days.

Every exclusion is a hole. That's acceptable when it's deliberate, narrow and recorded. It's dangerous when it's a person who complained once and nobody remembers why. Microsoft's own example policies recommend excluding emergency access accounts and service accounts, and replacing scripted service accounts with managed identities where possible.

• Exclude groups, never individual users, so the exclusion is visible and reviewable.
• For each excluded group record: which policy, why, who approved it, what compensating control applies (for example, an IP restriction), and an expiry date.
• Keep the register outside the tenant as well, so it survives an admin account compromise.

Sources: Microsoft Learn, 'Plan a Conditional Access deployment', 'Block legacy authentication with Conditional Access' and 'Manage emergency access accounts in Microsoft Entra ID'. Setting names are current as of October 2026; Microsoft renames portal items often, so confirm before you build.

• Monthly: check emergency access account alerts and any sign-ins; review new exclusions.
• Quarterly: test break-glass sign-in (Microsoft recommends at least every 90 days); compare policies against Microsoft's current template list; remove expired exclusions.
• After every incident or major change (new app, merger, office move): re-run report-only on affected policies.
• Annually: confirm licence tiers still match the policies you depend on, especially P2 risk policies.