Users and roles
Review all-user baselines, administrators, guests, service accounts, synchronization identities, staged populations, group dependencies, and exclusions with documented purpose and ownership.
Planning guide · Conditional Access
Review Conditional Access as a policy system, not one policy at a time.
The goal is to understand who can reach which resources, under what conditions, with which safeguards—and where exclusions, dependencies, or unsafe changes could weaken that design.
Safety first
1. Establish the policy map before proposing changes.
- Inventory enabled, report-only, and disabled policies; their owners; intended outcomes; assignments; exclusions; and known dependencies.
- Confirm protected emergency-access design and the process used to validate those accounts without weakening everyday controls.
- Document identity sources, administrative roles, guests, service accounts, workload identities, device populations, locations, applications, and authentication methods.
- Identify licensing and data dependencies for user risk, sign-in risk, authentication strengths, device compliance, application controls, and other conditions in use.
- Review current sign-in evidence and report-only results before tightening broad assignments or removing exclusions.
Change boundary: an assessment can identify gaps and propose a safe sequence. Policy deployment should occur only through a separately approved, tested, and recoverable change process.
Coverage review
2. Evaluate the paths policies are meant to govern.
Resources and clients
Examine cloud-app coverage, user actions, authentication context where used, browser and mobile or desktop clients, device-code flows, and legacy authentication exposure.
Authentication
Assess multifactor authentication requirements, authentication strengths where applicable, registration dependencies, phishing-resistant options, frequency choices, and user experience.
Device state
Trace requirements for compliant or joined devices, supported platforms, unmanaged access, application protection, unknown devices, and the Intune signals behind access decisions.
Location and risk
Review named locations, trusted-network assumptions, country or region logic, network changes, user and sign-in risk policies where licensed, and the response to detected risk.
Sessions
Inspect sign-in frequency, persistent browser sessions, application-enforced restrictions, continuous access evaluation dependencies, and controls for sensitive workflows.
Exceptions and operations
3. Make every bypass visible and reviewable.
- Record why each excluded user, group, application, platform, or location exists; who approved it; its compensating controls; and when it will be reviewed.
- Check whether nested groups, dynamic membership, role changes, guest lifecycles, or emergency processes can change effective coverage.
- Separate human sign-in controls from service principals and other workload identities that require different safeguards.
- Review policy overlap, gaps between policies, grant-control combinations, block-policy precedence, and assumptions created by naming conventions.
4. Require a safe operating process.
- Use report-only analysis, targeted pilots, documented success and failure criteria, and stakeholder communication appropriate to the change.
- Protect recovery paths, define rollback, monitor sign-in outcomes, and keep a change record that explains intent.
- Assign owners for policy review, exclusion review, authentication changes, sign-in investigation, and license or architecture changes.
- Validate the relationship with Intune compliance, Microsoft Entra identity protection, application controls, and logging.
Place Conditional Access inside the broader Microsoft 365 assessment checklist, review TenantShield data-handling practices, or explore the assessment service.
Find the access paths the policy inventory can hide.
Run the free checker for an initial signal, or request an assessment for evidence-backed Conditional Access priorities in context.