Security
SSO Conditional Access Policy Cleanup: Remove Rules After Risk Models Change
Conditional access policies are often created during a security push, merger, incident, device rollout, or compliance review. Years later, the identity platform may have better risk scoring, new device posture checks, or different application assignments, but the old policy still blocks logins, forces extra prompts, or grants exceptions no one can explain.
Cleanup should make identity controls easier to reason about without weakening the risk model.
Review the rule as a decision
For each policy, capture the original threat, included users, excluded users, target apps, device conditions, network conditions, grant controls, report-only history, and owner.
| Policy area | What to inspect | Cleanup concern |
|---|---|---|
| Included groups | Current membership and business role | Stale groups can over-block or under-protect users |
| Exclusions | Break-glass accounts, service accounts, executives, contractors | Exceptions may be more dangerous than the rule |
| Target apps | App ownership and replacement apps | Policies can protect retired apps while missing new ones |
| Conditions | Device, location, risk, and client type | Old assumptions may not match current access patterns |
| Sign-in evidence | Denies, challenges, bypasses, and helpdesk tickets | User pain and security value should both be visible |
Use identity-platform reports to export policy impact and sign-in outcomes. Keep the first pass in report mode or analysis mode where possible.
Do not rush these changes
Slow down when a policy affects privileged roles, production admin consoles, financial systems, source control, HR data, or customer support tooling. Also slow down when exclusions contain emergency access accounts; cleanup should preserve a tested break-glass path.
Retire by replacing intent
First, restate the risk the rule handled. Second, identify the current control that handles the same risk, such as stronger phishing-resistant authentication, device compliance, app-specific access, or privileged access workflows. Third, test the replacement against real sign-in logs. Fourth, remove or narrow the stale policy only after affected app owners and security owners agree.
If the rule remains, rename it so the intent is visible. A policy called “Temporary block” that survives two years is a cleanup failure even if it still protects something.
Prevent policy sprawl
New conditional access policies should include a threat statement, owner, target apps, excluded identities, review date, and expected retirement condition. Temporary incident policies should expire by default. Application onboarding should include access policy review so new apps do not inherit broad legacy rules by accident.
Key takeaways
- Conditional access cleanup is about preserving risk intent with fewer stale rules.
- Exclusions need as much review as blocks and challenges.
- Sign-in evidence should be paired with app owner and security owner approval.
- Temporary identity policies need expiry dates when created.