Lesson 40 — Microsoft Entra Conditional Access Session Controls
Microsoft Entra Conditional Access Session Controls determine what happens after access has been granted and how long that access remains valid.
Session Controls can require users to sign in again after a defined period, control whether browser sessions remain persistent, restrict application actions on unmanaged devices and respond to changing risk through Continuous Access Evaluation.
This lesson explains sign-in frequency, persistent browser sessions, Conditional Access App Control, application-enforced restrictions, token behaviour, Continuous Access Evaluation, troubleshooting and the Zero Trust principle that access should be continuously reassessed rather than trusted indefinitely.
What you will learn
This lesson explains how Session Controls manage access duration, browser persistence, application behaviour and continuous reassessment.
Learning objectives
After completing this lesson, you should be able to design, test and troubleshoot Conditional Access Session Controls.
- Explain the purpose of Session Controls.
- Configure sign-in frequency.
- Control persistent browser sessions.
- Understand application-enforced restrictions.
- Use Conditional Access App Control.
- Explain Continuous Access Evaluation.
- Investigate unexpected reauthentication.
- Apply Zero Trust session principles.
The problem this solves
Granting access once does not mean the user, device and risk state should be trusted forever.
Session Controls shape how access behaves after sign-in and when Microsoft Entra should require fresh authentication.
Session evaluation flow
What are Session Controls?
Session Controls influence the duration, persistence and behaviour of an authenticated session.
They do not replace Grant Controls; they operate after access has been permitted.
Where they fit
Assignments and conditions determine when a policy applies. Grant Controls determine whether access begins.
Session Controls determine how the resulting session behaves.
Grant Controls versus Session Controls
| Control | When it acts | Purpose |
|---|---|---|
| Grant Control | Before access | Require MFA, authentication strength, device or application assurance |
| Session Control | After access | Control duration, persistence and application behaviour |
| Continuous Access Evaluation | During access | Respond to critical events and policy changes |
Sign-in frequency
Sign-in frequency controls how often a user must perform fresh authentication for a protected resource.
It can be configured using a time interval or, in supported scenarios, every time.
Fresh authentication
When the configured frequency is reached, Microsoft Entra requires a new authentication event rather than silently extending the existing session.
The exact user experience depends on token state, client behaviour and authentication requirements.
Sign-in frequency flow
Time-based frequency
A time-based setting can require reauthentication after a defined number of hours or days.
Short intervals increase assurance but can also increase user disruption and support calls.
Every time
Every-time sign-in frequency is intended for highly sensitive actions or resources where repeated fresh authentication is justified.
It should not be applied broadly without testing the user experience.
Sign-in frequency design
| Design | Benefit | Caution |
|---|---|---|
| Longer interval | Lower user friction | Longer exposure if session context changes |
| Shorter interval | More frequent reassessment | Higher authentication fatigue |
| Every time | Maximum freshness for sensitive actions | Can severely disrupt normal workflows |
| Risk-based design | Stronger controls where needed | Requires clear application and user segmentation |
Persistent browser sessions
This control determines whether users can remain signed in after closing and reopening the browser.
It can override the normal stay-signed-in experience for targeted sessions.
Always persistent
Always persistent allows supported browser sessions to remain signed in across browser restarts.
It should be limited to scenarios where device and user assurance justify the convenience.
Never persistent
Never persistent prevents the browser session from surviving after the browser is closed.
This can reduce exposure on shared or unmanaged devices.
Persistent session comparison
| Setting | User experience | Typical scenario |
|---|---|---|
| Always persistent | User remains signed in across browser restarts | Trusted managed devices |
| Never persistent | Browser closure ends persistence | Shared or unmanaged devices |
| Not configured | Default platform and application behaviour | Baseline environments |
Application-enforced restrictions
Application-enforced restrictions allow supported applications to limit actions based on the Conditional Access session context.
A common example is restricting downloads from unmanaged devices.
Unmanaged browser access
Instead of blocking all access, organisations can permit restricted browser sessions that prevent downloading, printing or synchronising sensitive content.
This creates a controlled BYOD access path.
Restricted browser workflow
Conditional Access App Control
Conditional Access App Control integrates with Microsoft Defender for Cloud Apps to monitor or control sessions in supported applications.
It can apply real-time session policies after access is granted.
Monitor only
Monitor-only scenarios provide visibility into user activity without immediately blocking actions.
This is useful when validating expected behaviour before enforcement.
Block downloads
Session policies can block file downloads while still allowing users to view cloud content.
This can reduce data loss risk from unmanaged or high-risk sessions.
Custom session policies
Defender for Cloud Apps can apply more granular controls based on user, device, application and activity context.
Supported applications and licensing must be verified before design.
Application session control comparison
| Control | Primary function | Example |
|---|---|---|
| Application-enforced restrictions | Application applies limited-access behaviour | Restrict SharePoint downloads |
| Conditional Access App Control | Proxy and inspect supported sessions | Monitor or block risky activity |
| Persistent browser control | Control browser sign-in persistence | Prevent session survival on shared devices |
| Sign-in frequency | Require fresh authentication | Reauthenticate administrators regularly |
Continuous Access Evaluation
Continuous Access Evaluation allows supported services to respond more quickly to critical identity and policy events during an active session.
This reduces reliance on waiting for a token to expire naturally.
Critical events
Examples can include user disablement, password change, high user risk and significant policy changes.
Support varies by application, client and event type.
Continuous Access Evaluation flow
Token lifetime is not session lifetime
Access tokens, refresh tokens, browser cookies and application sessions have different behaviours.
Troubleshooting must identify which component is controlling the observed experience.
Client differences
Browsers, Office applications, mobile clients and legacy clients can respond differently to the same session policy.
Testing must cover every supported client path.
Guest sessions
Guest and external users may have different home-tenant authentication and session behaviour.
Cross-tenant policies should be tested rather than assumed.
Administrator sessions
Privileged access may justify shorter sign-in frequency, non-persistent browser sessions and stronger continuous monitoring.
Balance security with the operational impact of repeated prompts.
Agent Foskett investigation: “The user signed out… but the session stayed alive.”
Investigation evidence
- User Sign-in Logs
- Conditional Access session results
- Authentication details
- Token and client information
- Browser persistence behaviour
- Sign-in frequency configuration
- Continuous Access Evaluation events
- Defender for Cloud Apps session logs
Troubleshooting workflow
Common mistakes
- Assuming sign-out instantly invalidates every session component.
- Using aggressive sign-in frequency everywhere.
- Ignoring persistent browser settings.
- Expecting unsupported applications to enforce restrictions.
- Confusing token lifetime with session lifetime.
- Testing only one browser or client.
- Assuming Continuous Access Evaluation covers every event.
Best practices
- Use shorter sessions for privileged access.
- Prevent persistence on shared and unmanaged devices.
- Use restricted browser access instead of unnecessary blocking.
- Test application support before enforcement.
- Use report-only and monitoring where available.
- Document expected token and session behaviour.
- Review user experience before broad rollout.
Key takeaways
- Session Controls act after access is granted.
- Sign-in frequency requires fresh authentication at defined intervals.
- Persistent browser controls influence whether sessions survive browser restarts.
- Application-enforced restrictions can limit unmanaged-device actions.
- Conditional Access App Control provides real-time session monitoring and enforcement.
- Continuous Access Evaluation can respond to critical events during active sessions.
- Token lifetime and session lifetime are not the same.
- Browser, desktop and mobile clients can behave differently.
- Investigations must review all applicable policies and session components.
- Zero Trust continuously reassesses access rather than granting permanent trust.
Related Agent Foskett resources
Continue learning
Microsoft Entra Conditional Access Session Controls
Microsoft Entra Conditional Access Session Controls manage sign-in frequency, persistent browser sessions, application-enforced restrictions, Conditional Access App Control and Continuous Access Evaluation.
Microsoft Entra Academy Lesson 40 — Conditional Access Session Controls
This Agent Foskett lesson explains session duration, browser persistence, restricted unmanaged access, Defender for Cloud Apps integration, token behaviour, Continuous Access Evaluation and session troubleshooting.
