Exclusion age and reason
Match each exclusion to a documented reason and a date, not an assumption that it is still needed.
Independent IT security review
Find where Conditional Access coverage quietly stops.
A tenant can show strong-looking Conditional Access policies and still leave real sign-in paths uncovered. This review looks specifically for the gap patterns a policy list does not show on its own.
- Before any access
- Written question and scope
- Agreed evidence method
- No automatic tenant changes
Audit exclusions as their own inventory.
Exclusions accumulate one exception at a time and rarely get revisited. Treating them as a standalone list-separate from the policies that reference them-reveals patterns an individual policy review misses.
Stacked exclusions
Identify accounts or groups excluded from multiple policies at once, which can add up to an effectively unprotected identity.
Owner accountability
Confirm someone is responsible for each exclusion, since an unowned exception tends to outlive its original justification.
Trace legacy and unsupported authentication paths.
Older protocols and clients can bypass modern Conditional Access controls even when the tenant blocks legacy authentication in principle.
Protocol exposure
Check sign-in logs for legacy authentication attempts against mail and other protocols the tenant intends to block.
Application coverage
Confirm whether older desktop clients, scripts, or line-of-business applications authenticate through a path the policy actually reaches.
Blocking verification
Distinguish a policy that reports legacy sign-ins from one that actually blocks them in enforced mode.
Test policy interaction, not policies in isolation.
Two reasonable-looking policies can interact in a way neither author intended-one loosening what the other tries to enforce.
Grant control conflicts
Identify where an “or” condition across policies allows a weaker method to satisfy a stronger requirement elsewhere.
Session control gaps
Review sign-in frequency and persistent browser session settings for paths that quietly extend trust longer than intended.
Report-only residue
Confirm that policies still in report-only mode are not mistaken for enforced coverage during planning or audits.
Confirm MFA registration matches assumed coverage.
A Conditional Access policy that requires MFA is only as strong as the registration behind it. Gaps in registration or recovery paths can undermine an otherwise correct policy.
Registration completeness
Compare required MFA populations against actual registration status, including accounts created after the policy was set.
Recovery method strength
Review self-service password reset and recovery methods for paths that could reintroduce single-factor access.
Break-glass accounts
Confirm emergency access accounts are deliberately isolated, monitored, and tested rather than treated as a convenient shortcut.
Next step
Define the review before sharing evidence.
Start with the trigger, decision, and known boundaries. Do not send passwords, recovery codes, or tenant exports.