JUMP TO SECTIONChoose a lesson section
Four advanced access decisions—and the evidence behind each.
A Conditional Access policy evaluates signals and applies controls to an identity accessing a resource or operation. Advanced features extend that model after sign-in, at a particular sensitive resource, and during privileged administration. Microsoft calls these capabilities Continuous Access Evaluation, authentication context, protected actions and policy templates.
First identify what triggered the policy.
Continuous Access Evaluation
What changes after sign-in?For supported clients and resources, critical events and eligible location changes can trigger access re-evaluation before the access token expires. CAE isn't a universal sign-out switch, and not all policy or group changes propagate instantly.
CHECK: Confirm the affected client, resource-provider support, critical event, token behavior and actual access attempts.Authentication context
Which resource requested the extra control?An authentication context connects a sensitive site or application operation to a named Conditional Access requirement. The supported resource must request the context (often via a claims challenge), and the user must satisfy its scoped controls.
CHECK: Check the context is published, bound to the resource/label, targeted by the policy and actually requested.Protected actions
Does the admin operation need a new claim?Supported directory permissions can be assigned an authentication context so that privileged changes require stronger authentication. The operator still needs normal role permissions. Configure and enable the policy before protecting the action.
CHECK: Validate the permission, CA targeting, enabled state, authentication claims and the audit trail for the actual edit.Policy templates
Can this baseline go live safely?Microsoft's templates give a useful starting configuration, not a universally safe production policy. Standard template policies start in report-only and commonly exclude only the creator, so emergency access and app/user scope demand review.
CHECK: Compare template assignments, emergency exclusions, What If evaluation, report-only sign-ins and tested rollback.An unexpired token doesn't always mean access is still allowed.
Traditional access tokens have an expiration time. With Continuous Access Evaluation (CAE), a supported resource provider and client can react to supported critical events and certain IP-based location changes before that time arrives. However, CAE does not promise immediate enforcement for every resource, group change or custom application.
Three controls people frequently confuse
Continuous Access Evaluation
Trigger: A supported critical event or resource-aware location transition
Effect: A participating resource can challenge or reject an otherwise-unexpired token.
Not a guarantee that every app instantly logs out.Sign-in frequency
Trigger: A Conditional Access session control based on the configured interval
Effect: The sign-in/session experience can require authentication again based on policy.
Not the same as event-driven CAE revocation.Revoke sessions / refresh tokens
Trigger: An administrative response to a user incident
Effect: Revokes refresh sessions/tokens for supported identity flows; resource access token/session behavior can differ.
Not evidence that an unrelated SaaS session has terminated.CAE IP-based named location checks are not the same as country/region rules or legacy MFA trusted IPs. Split-tunnel VPN, multiple egress paths, IPv4/IPv6 differences and Global Secure Access scenarios can change how Entra and the resource provider see the user's IP. Microsoft documents a strict location enforcement preview; enable it only for well-known dedicated egress paths after careful pilot testing.
Step up only when the sensitive resource requests it.
Northstar's standard SharePoint intranet is accessible with ordinary identity requirements. Its payroll site needs stronger assurance. Rather than impose the most restrictive controls on every SharePoint page, Northstar can define a published authentication context, target it with a Conditional Access policy, and attach it to a supported site or sensitivity label. Supported custom applications can also request a context and handle the claims challenge.
Define & publish the context
In Entra ID → Conditional Access → Authentication context, create a descriptive, reusable context (such as Sensitive Finance). Publish to apps so supported integrations can select it.
Target the context with a CA policy
Scope the intended users and authentication context, then set appropriate grant controls—such as a phishing-resistant authentication strength or compliant device. Review break-glass exclusions.
Bind the protected resource
Configure a supported SharePoint site, sensitivity label, custom application, or other resource to request that context. A created context does not automatically enforce requirements everywhere.
Validate real user behavior
Verify a normal intranet resource remains accessible and the sensitive site triggers the intended step-up. Use sign-in logs, policy detail and supported client tests.
The protected resource must actually request it, and a matching CA policy must be configured and enabled for enforcement. SharePoint integrations also have licensing and client support limitations; test actual supported browsers and affected Office clients before broad rollout.
The admin has the role. Does the action require stronger proof?
Protected actions let an organization require Conditional Access controls when an authorized administrator attempts a supported sensitive directory permission—such as editing a Conditional Access policy. They do not create permissions or replace role-based access control (RBAC); they add a separate authentication requirement at the time of the protected operation.
Create and publish an authentication context
Choose a clear security meaning and confirm the administrative role and supported Entra license.
Create the CA policy and enable it
Target that context and define the grant control. Protected actions require an enabled policy; report-only does not enforce the step-up.
Bind the supported directory permission
In Entra Roles & admins → Protected actions, associate the permission with the context; keep ordinary RBAC authorization intact.
Test from an authorized administrator
Confirm satisfied MFA/authentication-strength claims and the policy outcome. A prior satisfied claim can avoid a visible new prompt.
Preserve recovery and evidence
Keep emergency access, audit logs, approved change procedures and a tested rollback. Avoid protecting the only route needed to undo a broken policy.
Microsoft requires a corresponding Conditional Access policy to be On before a supported permission is assigned as a protected action. Report-only policies cannot enforce that operation. An already-satisfied authentication claim may mean no additional prompt appears; inspect sign-in evidence rather than assuming the control failed.
A Microsoft template is a starting configuration—not change approval.
Template categories such as Secure foundation, Zero Trust, Remote work and Protect administrator help create recommended policies faster. They still require organizational scope review, necessary emergency access exclusions, sign-in evidence and rollback planning.
Start with a recommended baseline
Choose a suitable template category, such as Secure foundation, Zero Trust, Remote work, Protect administrator or Emerging threats. Review the actual targeting and grant conditions rather than adopting the name as a guarantee.
Confirm default policy state
A standard Conditional Access template policy is created in report-only. This records a projected impact at real sign-ins without prompting users or blocking access.
Protect emergency-access paths
Microsoft notes that templates targeting users exclude only the person creating the template. Explicitly review emergency accounts, service dependencies and all relevant user groups.
Test what the tools can and cannot prove
Use What If for hypothetical applicability and report-only sign-in results for observed outcomes. What If doesn't model every Microsoft 365 dependency or every real workflow.
Enable progressively with rollback
Pilot permitted and denied flows, check sign-in and audit logs, monitor impact, confirm a recovery owner, then enable the scoped policy using approved change management.
If a sign-in log shows Report-only: User action required, a policy would have required interaction, but the report-only policy did not itself challenge the user. The What If simulator is useful for evaluating matching conditions, not for guaranteeing every downstream Microsoft 365 service dependency or end-to-end user flow.
Read the four report-only outcomes before turning a policy on
Northstar pilots a device-compliance policy for Finance. The report-only column is a projection of what the configured policy would require, not proof that it blocked or challenged someone. Diagnose the observed sign-in before changing the policy state.
The requirements were already satisfied.
The policy matched and its evaluated controls were satisfied, perhaps because the device was compliant or an existing claim met the authentication requirement.
Verify: Sign-in details, authentication claims, device state and the policy's specific grant controls. Success is not evidence of a fresh MFA prompt.A required control was not satisfied.
The policy matched, but an evaluated control such as a compliant-device requirement or a block configuration would not have passed if enforced.
Verify: Device/compliance details and policy grant settings. A report-only failure does not itself mean the real sign-in was blocked.The user would have needed an interaction.
A requirement such as MFA or Terms of Use would need user action under enforcement. Report-only doesn't display that challenge on behalf of this policy.
Verify: Required authentication strength, existing claims and whether a pilot user can complete the actual challenge safely.The sign-in didn't match the policy.
A condition, user assignment, target resource or exclusion prevented a match. No enforcement decision can be inferred for this policy from the unmatched event.
Verify: Resource, identity, device platform, client app, network conditions and exclusions; compare the event with What If using the same inputs.What If predicts applicability for supplied conditions; sign-in logs show an actual evaluation with its real device, app and network context. Neither alone proves a downstream application session behaves correctly. Preserve emergency access and pilot both allowed and denied workflows before enabling the policy.
What does the policy control after the user signs in?
Northstar's employees work from managed laptops, unmanaged browsers and native Microsoft 365 clients. A short sign-in frequency, a non-persistent browser session, a CAE event and an application download restriction are four different controls. Designing a policy starts by defining which user experience must change, and what evidence would prove the change.
Sign-in frequency
Choose a reauthentication interval or Every time for the targeted resource, client and identity.
COMMON TRAP It is not a timer that forces a prompt on every click. Reauthentication depends on the app/session reaching a supported evaluation point.VALIDATION Review Entra sign-in logs, device PRT state, client protocol, app redirects and a real timed interaction.Persistent browser session
Allow or prevent the Microsoft Entra browser session from remaining persistent across browser restarts.
COMMON TRAP This is not universal sign-out and does not override every application cookie. Entra persistent browser session policies require All resources targeting.VALIDATION Test supported browser profiles and reopening, inspect app SSO, browser state and CA session policy applicability.Continuous Access Evaluation
Participating resources and clients can respond to certain critical events and supported location changes before access-token expiry.
COMMON TRAP Not every resource or third-party SaaS app participates; group and ordinary policy edits are not universally near-real-time.VALIDATION Compare event timing, CAE client/resource support, identity sign-in and actual resource access.App-enforced / App Control
Application-enforced restrictions can limit a supported Exchange/SharePoint experience; Defender for Cloud Apps session control can monitor or govern supported proxy sessions.
COMMON TRAP These are application/session experiences, not substitutes for CA reauthentication or a universal SaaS token revocation.VALIDATION Check the target app integration, session policy, client support and observed allowed/blocked action.Sign-in frequency is reevaluated when the application returns to Entra for a supported authentication/session evaluation. An application can retain its own session and delay an observable prompt. Similarly, never-persistent browser settings do not instantly revoke every app token. Confirm the client, protocol and resource behavior using real sign-in evidence.
Run a safe session policy validation
Inventory identity, target resource, client platform, browser/native app, network and licensing. Protect emergency access before enabling a broad policy.
Define the required experience separately: shorter sign-in lifetime, no persistent browser session, limited download, real-time event revocation or protected actions.
Use explicit assignments and exclusions. Scope a test group; validate All resources requirements for persistent browser sessions and record policy mode.
Use What If for policy matching, then report-only sign-in logs for observed projected decisions. What If cannot validate all dependent Microsoft 365 service calls.
Pilot real sign-ins, browser close/reopen, native-app interactions, authentication redirects, allowed/denied behavior and supported CAE event changes.
Enable in stages with approved change controls, support monitoring, recovery owner and a tested rollback. Never claim What If alone proves enforcement.
Cross-resource dependencies (such as Microsoft 365 services behind an application), application cookies, and when a client requests a token still require observed tests. A report-only policy does not itself reauthenticate, block or limit a session. Compare report-only details with real user behavior before changing the policy to On.
Five Northstar checkpoints cover policy design, browser persistence, Every time prompts, CAE gaps, and evidence-led rollout.
Configure a simulated scoped session policy, inspect report-only evidence, enable the policy and test six browser, native-client and emergency-access cases.
Open Session Policy Validation workbench →Make the right decision at the right boundary.
Investigate CAE session revocation, VPN location mismatches, SharePoint step-up requirements, and protected policy edits. Each case shows fictional evidence and asks you to identify a defensible next action.
Four incidents. A different trigger in each.
Trace the actual identity and resource boundary, choose the most defensible next action, and review why it works.
The account is disabled. Why is the SaaS tab still open?
OBSERVED EVIDENCE
- The identity was disabled 5 minutes ago.
- Outlook access has changed, but another SaaS tab still appears active.
- The unsupported SaaS integration has no confirmed CAE capability.
Verify supported behavior before enforcing policy.
Microsoft Entra, SharePoint and resource-provider features have different prerequisites and limitations. Use these official guides to validate the implementation details in your own environment.
Can you prove the policy did what you intended?
Practice 018 includes 16 concept cards, 16 explained questions and two original Northstar identity investigations.