> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Conditional Access Review

> Inventory a tenant's Conditional Access policies to find overlaps, legacy-auth gaps, unprotected apps, with report-only discipline for changes.

<Info>
  **Category:** Microsoft 365 Administration · [View source ↗](https://github.com/Thread-Magic/super-magic-skills/blob/main/skills/m365-administration/conditional-access-review/SKILL.md)
</Info>

**Runs as:** <span className="thread-chips" data-skill-tier="skill"><span className="thread-chip thread-chip-tier-skill">Skill</span></span> — you run it in Super Magic and confirm each write; there's no Flow trigger for this one.

**Connectors:** <span className="thread-chips"><span className="thread-chip">IT Glue</span><span className="thread-chip">Hudu</span></span>

**Role:** [Security & Compliance Owner](/start-here/roles/security-compliance-owner)

**Outcome:** Risk & Compliance

**When to use:** A scheduled/periodic CA review for a managed tenant (quarterly is typical), "are \<client>'s conditional access policies any good?" / insurance or audit prep, after an identity incident to find why CA didn't stop it, or before consolidating or migrating policies (e.g., off security defaults — see the security-defaults-vs-ca skill). CA policy sets rot in a specific way: exceptions accumulate, new apps arrive unprotected, and two policies quietly fight. This review inventories what the policies actually do today, finds the gaps, and enforces the report-only discipline for anything that changes.

**Run it:** as an on-demand review across every CA policy in the tenant — you compile the inventory, rank findings, and build remediation tickets, a technician exports policies and runs any changes (not a Flow: no schedule trigger, and changes need a human at the console).

## Prompt

```
You compile and rank; the tech exports policies and runs every change. Apply the Write
Guardrails base skill — never invent policy contents or sign-in counts; when in doubt about
a policy's effect leave it in report-only and say so.

1. Inventory. Tech exports every CA policy, disabled and report-only included: state, users
   and groups in and out, apps, conditions (locations, platforms, client apps, risk),
   grants, session controls and last-modified date in one dated table — the artefact. Pull the client's documented CA standard from their documentation and the
   knowledge base (Connector Degradation base skill if neither is on).

2. Non-negotiables first:
   - Legacy authentication blocked for all users — the highest-value policy there is. Verify
     against sign-in logs filtered to legacy client apps; real traffic means blocking gets
     its own remediation ticket, not a silent enable.
   - MFA for all users; phishing-resistant MFA — plain MFA at minimum — on every admin role.
   - Break-glass accounts excluded from every policy (cross-check break-glass-account-audit).
     Critical both ways: no exclusion is a lockout risk, an excluded daily-driver account is
     a bypass. Verify these exclusions before ANY enablement from this review.

3. Find the rot:
   - Stale exceptions. Every exclusion needs a written justification and expiry
     (conditional-access-exception); any nobody can explain is a finding.
   - Overlaps. Same users or apps, different grants: work out the effective result (block
     wins, grants combine) and flag pairs nobody intended.
   - Coverage gaps. Apps or populations no policy touches, "All apps" versus named-app
     policies, admin roles missing from the admin policy, guests unhandled.
   - Report-only orphans. Months in report-only is a decision nobody made: graduate, or
     delete.
   Rank worst-first, a remediation each: step 2 failures critical, unjustified exclusions
   and sensitive-app gaps high, overlaps and naming medium. Sign-in-log evidence may be
   capped — apply Sweep Honesty: state the window, label counts observed-in-window, and say
   what you couldn't check.

4. Report-only discipline on every change: create in report-only, collect real sign-in data
   over days not minutes, have the tech review it for legitimate traffic that would have been
   blocked, then enable, with client approval for anything that can block users. What-if spot
   checks supplement report-only data, never replace it. Never enable a blocking policy the
   day it was written.

5. Output a note (PSA Note Discipline base skill: plain text, no markdown or emojis): dated
   table, ranked findings with evidence, remediation list. Raise a ticket per remediation,
   and schedule the next review. Keep tenant identifiers, full policy JSON and user lists
   out of PSA-synced notes; summarize, and store the export in the docs system.
```


## Related topics

- [Break-Glass Account Audit](/skill-library/m365-administration/break-glass-account-audit.md)
- [Conditional Access Exception](/skill-library/onboarding-and-access/conditional-access-exception.md)
- [Security Defaults vs Conditional Access](/skill-library/m365-administration/security-defaults-vs-ca.md)
