Policy inventory and state
Review enabled, report-only, and disabled policies; policy purpose; owners; creation history; naming; duplication; gaps; and superseded designs.
Specialist assessment · Microsoft Entra Conditional Access
Know what your Conditional Access policies enforce, miss, and depend on.
A policy-level review that distinguishes enabled protection from report-only intent, identifies material gaps and overlaps, and plans change without creating an avoidable lockout.
Technical scope
Evaluate the policy system as a whole.
Applicability depends on Microsoft Entra licensing, identity architecture, authentication readiness, device management, application estate, user populations, and accepted business exceptions.
Assignments and exclusions
Evaluate users, groups, administrator roles, guest and external users, target resources, exclusions, emergency access accounts, and dynamic membership dependencies.
Conditions and signals
Review platforms, locations, client applications, device filters, authentication flows, user risk, and sign-in risk where licensed and applicable.
Grant and session controls
Assess block and grant decisions, multifactor authentication, authentication strengths, compliant or joined device requirements, terms of use, sign-in frequency, and persistent browser settings.
Coverage and interaction
Trace important sign-in scenarios across multiple policies to identify unintended gaps, conflicting requirements, redundant controls, and dependency failure modes.
Deployment and recovery
Review report-only evidence, pilot groups, change approval, monitoring, emergency access, rollback, support readiness, and policy-change auditability.
Questions this assessment can answer
Make enforcement decisions with fewer assumptions.
Which sign-ins are not covered?
Test representative users, roles, applications, platforms, locations, guests, service dependencies, and exceptional workflows against intended outcomes.
Which exclusions carry material risk?
Separate documented resilience or service requirements from broad, stale, nested, or ownerless exclusions.
What is safe to enforce next?
Use report-only and sign-in evidence, authentication-method readiness, device state, dependencies, and support impact to sequence rollout.
Assessment process
A controlled review from scope to decision.
Define required outcomes
Confirm important populations, applications, administrator paths, threat scenarios, device expectations, exceptions, and continuity requirements.
Map policy evaluation
Build a normalized policy inventory and trace assignments, exclusions, conditions, grant controls, session controls, and policy interactions.
Use evidence, not names
Compare policy intent with state, report-only results, sign-in evidence, authentication readiness, device dependencies, and operational records.
Plan controlled rollout
Prioritize gaps and simplify overlap with named pilots, monitoring, support, rollback, approval, and validation steps.
Deliverables
A policy map and an enforceable next-step plan.
- Executive summary of material access-policy risk and dependency
- Normalized Conditional Access policy inventory and coverage observations
- Exclusion, emergency access, and high-impact scenario review
- Policy overlap, gap, report-only, and rollout-readiness findings
- Prioritized change sequence with pilot, monitoring, rollback, and validation guidance
Boundaries
Clear scope protects the quality of the answer.
- Features and risk signals only where properly licensed, configured, and in scope
- No policy activation, disabling, deletion, or assignment change during assessment
- Policy analysis does not replace user-impact testing in the customer environment
- Service-principal and workload-identity controls are included only when explicitly scoped
- Emergency access exclusions are evaluated with their operational controls, not in isolation
Frequently asked questions
Questions to resolve before the work begins.
Will TenantShield enable or disable Conditional Access policies during the assessment?
No. The assessment reviews evidence and recommends a safe sequence. Policy changes require separate authorization, impact analysis, exclusions, rollback planning, and validation.
Are report-only policies included?
Yes, where they are in scope. Report-only state, evaluation evidence, intended population, dependencies, and readiness for enforcement can be reviewed without treating a configured policy as an enforced control.
How are Microsoft Entra ID P1 and P2 differences handled?
Core Conditional Access requires appropriate licensing. User-risk and sign-in-risk conditions and related Identity Protection evidence are evaluated only where the required Microsoft Entra licensing is available and the features are in scope.
Does the assessment account for emergency access accounts?
Yes. Exclusions are reviewed together with emergency access design, authentication, monitoring, ownership, testing, and recovery procedures so resilience is not confused with an undocumented bypass.
Related services and evidence
Continue with the level of review that fits the question.
Microsoft Entra ID Assessment
Review privileged roles, authentication methods, lifecycle, guests, applications, and consent alongside access policy.
Microsoft Intune Assessment
Review compliance and device-management evidence behind compliant-device access requirements.
Sample assessment
See how control evidence becomes a business-risk statement, recommended action, and validation step.
Start with the decision your team needs to make.
Share the business trigger, relevant Microsoft 365 licensing, approximate environment size, and decision deadline. No credentials or tenant exports are needed for the first conversation.