Conditional Access Policy Plan Worksheet

A conditional access policy plan is a table that lists every access policy you intend to run, who and what it targets, the conditions and controls it applies, who is excluded and why, and when it moved from report-only to enforced. Writing it down before you build stops the three common failures: locking out admins, gaps where an app or user falls outside every policy, and exclusions nobody remembers adding. This worksheet is written for Microsoft Entra Conditional Access, which most readers searching for it use, but the columns work for Okta authentication and global session policies and for other IdP policy engines with the field names changed.

How to use this worksheet

1. Agree the naming standard (section 1) and the exclusion groups (section 3) first.
2. Copy the baseline set (section 2) into the inventory (section 4), then add your own policies. Group apps with the same requirements into one policy instead of one policy per app.
3. Create every policy in report-only mode, record the date, and leave it for at least a week before enforcing. Microsoft's deployment plan recommends "report-only mode for at least one week before enforcement" (Microsoft Learn).
4. Run the go-live checklist (section 5) for each policy, then fill in the enforced date.
5. Review the whole worksheet [quarterly] and after any IdP or licensing change.

Background: conditional access and the conditional access policies implementation guide.

1. Naming standard

Microsoft recommends that a policy name show a sequence number, the apps it applies to, the response, who it applies to, and when it applies, and that disabled contingency policies start with "ENABLE IN EMERGENCY" (plan a Conditional Access deployment). Policies have no built-in owner attribute, so encode ownership in the name or keep it in this worksheet.

Our format: [CA###]-[Persona]-[Apps]-[Response]-[Condition]

Examples:

• CA001-AllUsers-AllApps-RequireMFA-AnyLocation
• CA010-Admins-AllApps-RequirePhishResistantMFA
• EM01-ENABLE IN EMERGENCY: MFA disruption [1/2]-AllUsers-Office-RequireCompliantDevice

Guidance: number in blocks by persona (001-099 all users, 100-199 admins, 200-299 guests, 300-399 workload identities) so the number tells the help desk which population is affected.

2. Baseline policy set

This baseline follows the three deployment phases in Microsoft's Conditional Access deployment plan and the secure foundation templates. Microsoft lists the license each needs; risk-based policies need Entra ID P2. Templates create policies in report-only mode by default and exclude only the person creating them, so add your emergency access group yourself.

Guidance: Microsoft's phase 3 restricts device code flow and authentication transfer. Device code flow is the channel abused in device code phishing, so restrict it to the devices that need it. Service principals are not blocked by policies scoped to users, so CA300 is the only baseline item that covers them; see the NHI policy template.

3. Exclusions register

Microsoft recommends excluding emergency access accounts from policies that block or restrict sign-in, and notes that report-only policies do not need the exclusion (emergency access accounts). Every other exclusion is a hole that needs an owner and an end date.

Guidance: exclude groups, never individual users, so the register is the group membership. Microsoft's testing advice: "Ensure you test the exclusion criteria of a policy", because another policy may still apply to the excluded user.

4. Policy inventory

One row per policy. Keep this table as the source of truth and the tenant as its implementation; export the JSON definitions alongside it.

Coverage checks to run against the inventory:

• Every app is covered by at least one policy. Microsoft's advice is to target All resources in baseline policies so new apps are covered automatically.
• Every persona (all users, admins, guests, workload identities, emergency access) appears in at least one row.
• Policy count is well under the tenant limit (Microsoft documents 240 policies per tenant, counting report-only and off policies).
• No policy lists individual users where a group would do.

5. Go-live checklist (per policy)

• Emergency access group excluded, if the policy blocks or restricts.
• Tested with a non-admin test user and the What If tool.
• In report-only for [7+] days. Reviewed the report-only results in sign-in logs or the insights workbook: count of "Report-only: Failure" and "User action required" understood.
• For report-only policies that require a compliant device: macOS, iOS and Android excluded during report-only, because Microsoft warns those users can be prompted for a device certificate even though nothing is enforced (report-only mode).
• Users told what changes and how to get help.
• Rollback written down: disable the policy, or exclude the affected group temporarily.
• Protected actions enabled so changing Conditional Access needs fresh strong authentication.

6. Contingency policies

7. Change log

Related

• MFA and authentication standard (what the authentication strengths should be)
• Privileged access policy (break-glass accounts)
• Zero trust rollout
• ADFS to Entra migration
• Primary refresh token theft and token replay against unbound endpoints