Microsoft announced the public preview of Entra Conditional Access policy plans on 4 November 2026. The feature groups related access controls around a shared objective. Microsoft identifies Entra ID P1 or P2 customers as eligible to begin in the admin center with the Conditional Access Administrator role. This is a preview, not general availability.
For a team maintaining many access policies, a smaller configuration list can be attractive. The useful acceptance test is whether the intended people, applications and exceptions still receive the intended decision.
Read the effective access decision
Microsoft’s concept guide explains that shared targeting and scenario-specific rules are combined. Existing policies and plan rules are evaluated independently: every applicable policy and rule must be satisfied, with no precedence. During preview, user-targeted plans using Location issue one-hour access tokens without instant IP enforcement. Do not read a location condition as a guarantee of immediate interruption when a user changes networks.
That makes timing part of the review, alongside who is included. Write down the response time your workflow needs before deciding whether this preview fits it.
Check the controls’ licenses
The licensing guide keeps feature requirements separate: Conditional Access based on user or sign-in risk needs Entra ID P2, and agent Conditional Access requires an eligible Microsoft Agent 365 arrangement. Other connected products can require their own licenses. Access to the plan interface does not establish entitlement to every control used inside it.
Validate before retiring old policies
Microsoft’s migration procedure leaves original policies unchanged and creates the new rules Off. It calls for Report-only evaluation, comparison with the originals in sign-in logs or impact metrics, and enabling the rules only after validation. Disable the originals after enabling and validating the replacement; deletion comes later, subject to the organization’s validation, change-management and retention requirements.
A practical review record could include:
- Expected result: name a representative user, application and condition, then record whether access should succeed and which controls should apply.
- Observed result: capture the relevant evaluation and investigate mismatches rather than treating a successful sign-in alone as proof of equivalent protection.
- Recovery responsibility: identify who can restore the approved configuration if the rollout behaves unexpectedly. Check recovery access before expanding the change.
Start with a bounded change that your team can explain and reverse. These are proposed operational checks, not results from testing a customer tenant. A tidier policy inventory is useful only when its access behavior remains understood.