# Conditional Access Policy Plan Worksheet

Source: https://startwithidentity.com/templates/conditional-access-policy-plan-worksheet/
Last updated: 2026-11-05
License: content by Start with Identity. Cite the source URL.

---

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](https://startwithidentity.com/vendors/iam/microsoft-entra/) Conditional Access, which most readers searching for it use, but the columns work for [Okta](https://startwithidentity.com/vendors/iam/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](https://learn.microsoft.com/en-us/entra/identity/conditional-access/plan-conditional-access)).
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](https://startwithidentity.com/glossary/conditional-access/) and the [conditional access policies implementation guide](https://startwithidentity.com/guides/implementation/conditional-access-policies-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](https://learn.microsoft.com/en-us/entra/identity/conditional-access/plan-conditional-access)). 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](https://learn.microsoft.com/en-us/entra/identity/conditional-access/plan-conditional-access) and the [secure foundation templates](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policy-common). 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.

| ID | Policy | Users | Apps | Grant / session | Phase |
|----|--------|-------|------|-----------------|-------|
| CA001 | Block legacy authentication | All users | All resources | Block (client apps: Exchange ActiveSync, other clients) | 1 |
| CA002 | Secure security info (MFA) registration | All users | User action: register security information | Require MFA or trusted location / Temporary Access Pass | 1 |
| CA100 | Phishing-resistant MFA for privileged roles | Directory roles `[list]` | All resources | Authentication strength: phishing-resistant MFA | 1 |
| CA003 | MFA for all users | All users | All resources | Authentication strength: `[MFA / passwordless / phishing-resistant]` | 2 |
| CA200 | MFA for guests | Guests and external users | All resources | Require MFA (decide whether to trust partner MFA claims) | 2 |
| CA004 | Approved apps or app protection on mobile | All users | Office 365 `[ ]` | Approved client app or app protection policy (iOS, Android) | 2 |
| CA005 | MFA for device join and registration | All users | User action: register or join devices | Require MFA | 2 |
| CA006 | Restrict high-risk sign-ins | All users | All resources | Require MFA, sign-in frequency every time (P2) | 3 |
| CA007 | Restrict high-risk users | All users | All resources | Require MFA and password change, or block (P2) | 3 |
| CA008 | Token protection for sign-in sessions | All users `[pilot]` | Supported apps `[ ]` | Session: require token protection | 3 |
| CA009 | Restrict device code flow | All users | All resources | Block authentication flow: device code (exclude `[conference room devices]`) | 3 |
| CA010 | Block authentication transfer | All users | All resources | Block authentication flow: authentication transfer | 3 |
| CA101 | Privileged access from PAWs only | Directory roles `[list]` | Admin portals | Require compliant device or device filter for PAWs | 3, after PAW rollout |
| CA011 | Require compliant or hybrid joined device, or MFA | All users | All resources | Compliant device OR hybrid joined OR MFA | `[optional]` |
| CA012 | No persistent browser on unmanaged devices | All users | All resources | Session: persistent browser never; sign-in frequency `[ ]` | `[optional]` |
| CA300 | Workload identities from known IPs | Service principals `[list]` | All resources | Block outside named locations (check the license requirement for workload identity policies) | `[optional]` |

> Guidance: Microsoft's phase 3 restricts device code flow and authentication transfer. Device code flow is the channel abused in [device code phishing](https://startwithidentity.com/techniques/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](https://startwithidentity.com/templates/service-account-non-human-identity-policy/).

## 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](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access)). Every other exclusion is a hole that needs an owner and an end date.

| Exclusion group | Members | Excluded from | Reason | Compensating control | Owner | Expires |
|-----------------|---------|---------------|--------|----------------------|-------|---------|
| `sg-CA-Exclude-EmergencyAccess` | `[2 break-glass accounts]` | All blocking or restricting policies | Lockout recovery | Phishing-resistant keys, alert on every sign-in | `[ ]` | Never (validate every 90 days) |
| `sg-CA-Exclude-DirSync` | `[sync account]` | CA003 | Non-interactive | Named location restriction | `[ ]` | `[ ]` |
| `sg-CA-Exclude-[name]` | `[ ]` | `[ ]` | `[ ]` | `[ ]` | `[ ]` | `[ ]` |

> 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.

| ID and name | Persona | Include users / groups / roles | Exclude | Target resources (apps, user actions, auth context) | Conditions (platform, location, client app, risk, device filter) | Grant | Session | Report-only from | Enforced on | Owner | Last reviewed |
|-------------|---------|-------------------------------|---------|-----------------------------------------------------|------------------------------------------------------------------|-------|---------|------------------|-------------|-------|---------------|
| `CA001-...` | All users | All users | `sg-CA-Exclude-EmergencyAccess` | All resources | Client apps: legacy | Block | None | `[date]` | `[date]` | `[ ]` | `[ ]` |
| `CA003-...` | All users | All users | `sg-CA-Exclude-EmergencyAccess` | All resources | Any | Auth strength `[ ]` | Sign-in frequency `[ ]` | `[date]` | `[date]` | `[ ]` | `[ ]` |
| `[ ]` | `[ ]` | `[ ]` | `[ ]` | `[ ]` | `[ ]` | `[ ]` | `[ ]` | `[ ]` | `[ ]` | `[ ]` | `[ ]` |

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](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-report-only)).
- [ ] 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

| ID | Name | Disruption | Enable order | What it changes | Tested |
|----|------|-----------|--------------|-----------------|--------|
| EM01 | `ENABLE IN EMERGENCY: MFA disruption [1/2]` | MFA provider outage | 1 | `[Require compliant device instead of MFA for Office apps]` | `[date]` |
| EM02 | `ENABLE IN EMERGENCY: MFA disruption [2/2]` | MFA provider outage | 2 | `[ ]` | `[date]` |

## 7. Change log

| Date | Policy | Change | Reason | Approved by |
|------|--------|--------|--------|-------------|
| `[ ]` | `[ ]` | `[ ]` | `[ ]` | `[ ]` |

## Related

- [MFA and authentication standard](https://startwithidentity.com/templates/mfa-authentication-standard/) (what the authentication strengths should be)
- [Privileged access policy](https://startwithidentity.com/templates/privileged-access-policy/) (break-glass accounts)
- [Zero trust rollout](https://startwithidentity.com/guides/implementation/zero-trust-rollout/)
- [ADFS to Entra migration](https://startwithidentity.com/guides/implementation/adfs-to-entra-migration/)
- [Primary refresh token theft](https://startwithidentity.com/techniques/primary-refresh-token-theft/) and [token replay against unbound endpoints](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/)