Are Your Conditional Access Session Control Policies Letting Sessions Run Forever?

Let’s be direct about how most organisations handle Conditional Access session controls.

You built your policies. You required MFA. You targeted All Resources. You congratulated yourself and moved on.

But did you scroll down to the Session section before you saved?

If you are not sure, the answer is probably no, and that means your users can have authenticated browser sessions that live for up to 90 days, and anyone on an unmanaged device can close a browser, reopen it, and walk straight back in.

That is not a configuration you chose. It is a default you never questioned.

Never miss an article — subscribe here, and don’t forget the YouTube channel, Control Alt Delete Tech Bits.

What the Defaults Actually Do

Microsoft Entra ID has two session-related settings that most admins leave untouched.

Sign-in frequency controls how long a user can access a resource before being asked to authenticate again. If you have not configured this, the default is a rolling 90-day window. Entra will not prompt users to sign back in as long as the security posture of their session has not changed, no password reset, no device compliance failure, no admin-forced revocation. Ninety days is a long time for a session to coast along unquestioned.

Persistent browser session controls whether a browser session survives after the browser is closed. By default, users on personal devices see a Stay signed in? prompt at sign-in. If they click yes, a persistent cookie is set. Close the browser, reopen it the next day on the same machine, and they are still authenticated, no prompt, no challenge, no friction.

Neither of these defaults is catastrophic in isolation. On a managed, Entra-joined device with a compliant posture, a long session lifetime is a reasonable trade-off against user disruption. But the problem is that most tenants apply the same relaxed behaviour to every device, every user, every app, including personal laptops, shared workstations, and contractor machines your organisation has no visibility into.

This site and my YouTube channel are supported by Tech-Source.

Tech-Source is a UK-based technology supplier that works closely with IT teams across education, public sector, and commercial environments. They provide hardware, licensing, and infrastructure solutions, with a strong focus on practical advice rather than upselling.

Their support helps keep this site running and allows me to continue publishing in-depth, admin-focused content and walkthroughs without paywalls.

You can find out more about what they do at https://tech-source.co.uk/

The Risk You Are Carrying

Think about what persistent sessions mean in practice.

A user signs into SharePoint from a hotel lobby computer. They tick Stay signed in? out of habit. They close the browser and leave. The next guest sits down. They open the browser, navigate to SharePoint, and they are in, still authenticated as your user. No MFA. No prompt. No warning.

That scenario is not theoretical. It is the exact attack that session hijacking and pass-the-cookie techniques exploit. Stolen session cookies are a real and growing tactic precisely because they bypass MFA entirely. Authentication already happened. The session is valid. The token is live.

And if your sign-in frequency is sitting at the 90-day default, that token may well stay live for months.

Two Policies to Put in Place

There is no single Conditional Access policy that handles both situations perfectly, because the right behaviour depends on the device. The fix is two targeted policies.

Policy 1: Lock Down Unmanaged Devices

This is the critical one. Unmanaged devices, personal laptops, BYOD machines, anything not Entra-joined or Intune-compliant should never have persistent sessions, and sign-in frequency should be short.

Name: CA-Session-UnmanagedDevices-BrowserControls

Users: All users (exclude your break-glass accounts under Exclude)

Target resources: All resources

Conditions > Filter for devices:

• Set Configure to Yes
• Under Devices matching the rule, set to Include filtered devices in policy
• Rule syntax: device.trustType -ne "ServerAD" -or device.isCompliant -ne True

This targets any device that is either not hybrid joined or not compliant, in other words, unmanaged devices. This is the part most admins miss entirely.

Session:

• Sign-in frequency > Periodic reauthentication > 1 Hour (you can pick hours or even days)
• Persistent browser session > Never persistent

Enable policy: Start in Report-only first. Run it for a week and review the sign-in logs before enforcing.

Policy 2: Enforce Sign-In Frequency for Admins

Privileged accounts deserve their own policy regardless of device state. An admin session that persists for 90 days is a standing target.

Name: CA-Session-Admins-SignInFrequency

Users: Select users and groups > Directory roles

Include at minimum:

• Global Administrator
• Privileged Role Administrator
• User Administrator
• Exchange Administrator
• SharePoint Administrator
• Intune Administrator
• Security Administrator
• Conditional Access Administrator

Target resources: All resources

Session:

• Sign-in frequency > Periodic reauthentication > 4 hours (E3 tenants, per the CIS Microsoft 365 benchmark) or 24 hours (E5 with PIM — where PIM activation windows already enforce short-lived privilege)
• Persistent browser session > Never persistent

Enable policy: Report-only first, then enforce.

One Thing to Check Before You Save

Before you apply either policy, open Authentication methods > Policies > Microsoft Authenticator and confirm that Remember multifactor authentication on trusted devices is not enabled in your legacy per-user MFA settings.

Running sign-in frequency alongside the legacy Remember MFA setting creates a conflict. Users get prompted at unexpected intervals and the logic becomes unpredictable. If you find it enabled, disable it — Conditional Access session controls are the correct way to manage this in a modern tenant.

What Report-Only Actually Tells You

Once your policies are in report-only mode, head to Sign-in logs and filter by Conditional Access > select your new policy. You are looking for the Report-only: Would apply result.

Pay attention to:

• How many sign-ins come from unmanaged devices daily
• Whether any service accounts are being caught (exclude them if needed)
• Whether the admin policy is hitting shared service mailboxes or automation accounts

Report-only mode is not a formality. It is how you avoid locking out a team at 9am on a Monday because a policy swept up accounts it was never intended to catch.

Conditional Access MFA policies get all the attention. Session controls get almost none.

The default 90-day sign-in window and the Stay signed in? Prompts are not security features. They are convenience features that became the security baseline by default.

Two policies, one for unmanaged devices, one for admins, fix the most significant gaps without touching the experience for managed, compliant users. They take less than 15 minutes to configure and a week in report-only to validate.

The session behaviour that is running in your tenant right now is not something you decided on. It is just what Entra does until you tell it otherwise.

Time to tell it otherwise.

You also might like this article