Conditional Access Policy Library

What this library covers

Conditional Access is the policy engine inside Microsoft Entra ID (formerly Azure AD). It evaluates every sign-in against signals like user risk, sign-in risk, device compliance, location and application, then enforces controls like MFA, block, or session limits.

This library is grouped into five layers: baseline, identity protection, device, admin hardening, and session controls. Numbering uses CA001 to CA999 so policies are easy to reference in tickets and documentation.

Before you create a single policy

Mandatory pre-work

1. Create at least two break-glass accounts. Cloud-only, very long random passphrase, no MFA, excluded from every Conditional Access policy. Store credentials offline (printed, locked safe, two named custodians).
2. Inventory cloud apps in use across your tenant. Service principals, third-party SaaS, federated apps. Conditional Access can break things you forgot existed.
3. Review existing security defaults or legacy MFA configuration. Disable security defaults before enabling Conditional Access; they conflict.
4. Enable sign-in logs and ship to a SIEM. You will need them for troubleshooting and audit.
5. Use Report-only mode first. Every policy below should be deployed in Report-only for at least 7 days before enforcement.

Layer 1: Baseline policies (every tenant)

These four policies are the minimum baseline for any Microsoft 365 tenant. If you are not running these, your tenant is not adequately protected regardless of other security investment.

Layer 2: Identity protection (Entra ID P2)

Entra ID Protection generates user risk and sign-in risk signals based on Microsoft threat intelligence. These policies act on those signals automatically. Requires Entra ID P2.

Layer 3: Device and compliance

These policies require devices to be managed and compliant before sensitive workloads are accessed. Pair with Intune compliance policies that enforce encryption, OS version, antivirus state, and a passcode.

Layer 4: Admin hardening

Privileged accounts are the prize for attackers. These policies harden directory roles specifically. Pair with Privileged Identity Management (PIM) for just-in-time elevation.

Layer 5: Session controls

Session controls limit what an authenticated session can do, and how long it lasts. They reduce the value of a stolen token to an attacker.

Rollout sequence and testing

The order matters. Policies have dependencies and the rollout has to avoid lockouts.

1. Create break-glass accounts. Exclude from every policy.
2. Disable security defaults. Confirm legacy MFA configuration is replaced.
3. Deploy CA001 (block legacy auth) in Report-only for 7 days. Review sign-in logs for any legitimate legacy traffic. Remediate, then enforce.
4. Deploy CA002 (require MFA) in Report-only for 7 days, register all users for MFA, then enforce.
5. Deploy CA003 (location restrictions) and CA004 (sign-in risk) together, Report-only for 7 days, then enforce.
6. Roll out Layer 3 device policies after Intune compliance is fully deployed. Do not require a compliant device until you actually have compliance signals.
7. Roll out Layer 4 admin hardening with PIM enabled. Test break-glass procedure end-to-end before enforcement.
8. Roll out Layer 5 session controls last. These have the highest user-experience impact and benefit from baseline first.

Testing every policy

• Use the What If tool in Conditional Access to simulate a user, location, app and risk combination before enforcement.
• Pilot on the IT team first, then a non-critical department, then the rest of the business.
• Document every policy in a Conditional Access Register: name, scope, conditions, grant, session, exclusions, owner, last review date.

Australian regulatory alignment

This policy library aligns to several Australian frameworks. The mappings below are indicative, not formal compliance certification.