Do you know how persistent your browser session is when a Conditional Access policy is active, in which the setting Persistent browser session is set to Never persistent?
I assumed that the browser session would never be persistent, like the setting says. Maybe I just thought to simple, as I’m not an authentication expert, but the answer seems to be; it depends.
It depends on the authentication architecture of the web application, and on a setting in the browser.
I didn’t realize this was the behaviour of Teams in a web browser that I will be showing you in this post, or what the impact of a single browser setting would be. Therefore, I’m sharing this behaviour and some information about this in this blog post. To make more people aware of this and take action when needed.
The ‘problem’
Let me first describe the situation and what that ‘behaviour’ is that I mentioned already multiple times.
With Conditional Access policies, we enforce rules under which conditions an end-user can get access to corporate data, like Office 365 data. By default, we require a compliant Windows device to get access to corporate data. Besides that, we could also allow access to corporate data using BYOD (Windows) devices, but only when using a web browser. We can discuss whether that’s a good idea , but under certain conditions, companies want to allow their employees to access, for example, the mailbox on an unmanaged device or SharePoint data.
To secure access to corporate data from an unmanaged device, we would normally require app enforcement restrictions, a never-persistent browser session, and sign-in frequency. All enforced via a Conditional Access policy. This makes it a bit safer to access corporate data on unmanaged devices.
That would result in the limitation to not be able to sync or download files from the browser, a non-persistent browser session, and a forced reauthentication every x hours. Right?
Wrong!
This video shows the behaviour of Teams web, Outlook, and OneDrive that I’m talking about.
We see in the video that I sign-in with my credentials to Teams web using the Edge browser. Teams, OneDrive and Outlook are opened. The browser is closed and reopened. This shows Microsoft Teams doesn’t ask me to reauthenticate. I can browse through Teams and lookup people in the same tenant and see contact information like e-mail and phone number. I have access to the OneDrive folder structure, it wants me to authenticate when I open a Word document.
After opening several Microsoft 365 apps again, I configured the setting Open tabs from the previous session in Edge. When we now close and open the browser, the sessions are saved, which allows me to also open Outlook and OneDrive without reauthentication.
When we have a look at this video, we can see that Microsoft Teams is still signed in after closing and re-opening the Edge browser. This is even the case when we reboot the device and reopen the browser again.
Outlook (Exchange) and OneDrive (SharePoint) behave differently. When we close the Edge browser, usually we need to authenticate again before we get access to Outlook or OneDrive. But that’s not the case when we turn on the setting Open tabs from the previous session in the Edge browser (or an equivalent setting in another browser like Firefox).
With this setting turned on, Outlook and OneDrive also don’t require authentication when we close and start the browser again. We are just signed in to these applications, like we have seen before with Teams.
Web authentication
When reopening the browser to access Teams Web, reauthentication is typically not required — regardless of whether the browser is configured with settings such as “Open tabs from the previous session.” However, the behaviour of Outlook on the Web and OneDrive may differ depending on this browser setting.
What explains this difference between the web applications?
Although Microsoft Teams, Outlook on the Web and OneDrive all authenticate users through Microsoft Entra ID using OAuth 2.0, their session behaviour differs due to architectural differences.
All three applications:
- Authenticate via Microsoft Entra ID
- Use OAuth 2.0 and modern authentication
- Receive an access token (valid for approximately 1 hour)
- Receive a refresh token (longer validity, rotated on use)
More on refresh tokens on the Microsoft docs.
The differences arise in how each application maintains its session after authentication.
Microsoft Teams Web
Microsoft Teams Web is built as a modern Single Page Application (SPA).
While Microsoft does not explicitly document that Teams Web uses MSAL.js, the authentication pattern it follows aligns with MSAL’s SPA model — client-side OAuth handling with silent token renewal.
Teams:
- Uses a client-side authentication library pattern (MSAL-like behaviour)
- Uses browser-based token storage mechanisms (such as IndexedDB) to maintain OAuth tokens for silent renewal
- Relies heavily on silent token renewal
- Has less reliance on traditional long-lived application session cookies compared to Outlook or SharePoint.
Teams primarily trusts the presence of valid OAuth tokens. When an access token expires, it silently uses the refresh token to obtain a new one. Because refresh tokens are stored in the browser, Teams can often rebuild its session even after the browser is restarted.
This makes Teams less sensitive to cookie deletion and more resilient in maintaining login state.
Outlook on the Web
Outlook on the Web (Exchange Online) also uses OAuth via Entra ID, but its architecture is more hybrid.
Outlook:
- Uses OAuth tokens for authentication
- Relies on Exchange server session cookies
- Maintains backend session state
After token validation, Exchange establishes its own session using application cookies. These cookies help maintain state between requests.
If cookies are deleted or expire, Outlook is more likely to redirect the user back to Entra ID for authentication. Silent renewal may still occur if a refresh token is available, but cookie loss has a greater impact compared to Teams.
OneDrive (SharePoint Online)
OneDrive is built on SharePoint Online and uses OAuth authentication via Entra ID. However, it relies heavily on application session cookies.
SharePoint:
- Issues its own cookies (e.g., FedAuth and rtFa)
- Has a strong dependency on server-side session state
After Entra ID validates the user, SharePoint creates its own session and issues cookies to maintain it. These cookies are central to session continuity.
If SharePoint application cookies are removed, SharePoint typically requires a new authentication flow. Silent reauthentication may still occur if a valid Entra session and refresh token are available, but the app-level cookie dependency makes it more sensitive than Teams.
The authentication flow for SharePoint Online is nicely documented for people like me, who know a little about the authentication of Entra ID and its related M365 applications, but are not the deep-dive experts on this 😊
But to conclude, this authentication architecture makes OneDrive more sensitive to cookie loss than Teams.
Summary of architectural differences:
| Application | Primary Model | Dependency on Cookies | Sensitivity to Cookie Loss |
| Teams | Token-centric SPA | Low | Low |
| Outlook | Hybrid (Token + Server Session) | Medium | Medium |
| OneDrive | Server session + Cookies | High | High |
Because Teams relies primarily on refresh tokens stored in browser storage, it can often remain signed in even after a browser restart. Outlook, and especially OneDrive, rely more on application session cookies, meaning browser cookie behaviour has a greater impact on their session continuity.
All three applications are secured by the same Conditional Access policies (such as Sign-in Frequency and the browser persistence setting), but their underlying session architecture explains why their login behaviour may not look identical.
The impact of a browser setting
It’s now clear that there is a difference in behaviour among the three applications I used as examples. But another thing that comes around the corner is that the behaviour is also changed by a setting in the browser, and then, especially for the applications that rely (heavily) on cookies, like OneDrive and Outlook.
In Microsoft Edge, we can configure the browser to restore tabs by enabling the Open tabs from the previous session setting. In other browsers, we have a similar setting that restores tabs on reopening the browser. But this doesn’t just reopen the browser tabs we had open before we closed the browser; it preserves the state of the browser session, including cookies.
Configuring Persistent browser session to Never persistent ensures that Entra ID only issues session-scoped authentication cookies instead of persistent SSO cookies.
A session cookie is valid until the browser session ends. However, modern browsers treat “restore previous session” as a continuation of the same session. From the browser’s perspective, the session never ended — it was suspended and resumed.
Although Entra issued a non-persistent cookie, the browser may restore the session state. And thus, also Outlook and OneDrive might still be signed in after a browser restart (and even a reboot of the Windows device).
Limiting the impact
To my knowledge there isn’t really something we can do on our own to resolve this ‘issue’ with the web apps on unmanaged devices, but we can limit the impact.
The approach could be to fully block unmanaged Windows devices (I haven’t tested this on macOS, but assume the same behaviour is seen) or limit access to for example only the mailbox and block all other resources connected to Entra ID.
If we still allow access from unmanaged devices, we can ask our users to sign out of the Microsoft 365 apps instead of closing the browser or not configure the settings to save the browser session. But from a security perspective, that’s not the best option.
From a management perspective, we should at least bring back the number of hours we configure for sign-in frequency if unmanaged devices are allowed. We should find a good balance between end-user experience and security.
Without a configured Sign-in Frequency, refresh tokens can silently renew access tokens for extended periods, meaning a user may remain effectively signed in despite browser restarts.
But could Continuous Access Evaluation (CAE) change this behaviour?
Continuous Access Evaluation in Microsoft Entra ID helps enforce security events in near real time, for example when a user account is disabled, a password is changed, or a device becomes non-compliant. In those situations, access can be revoked quickly without waiting for a token to expire.
But CAE does not control how a browser handles session restoration and it does not replace Sign-in Frequency settings.
We can implement App Protection Policy Settings for Windows as additional security measures. It doesn’t solve the problem we have, Teams will not be forced to sign out when closing the browser, but it adds additional controls at the application level to keep data from leaking.
It applies restrictions such as blocking copy/paste, preventing “Save As” to local storage, and limiting data sharing to unmanaged apps.
App Protection Policies on Windows primarily apply when accessing resources through Microsoft Edge and do not control authentication token behaviour itself.
Another option could be to block unmanaged devices completely and provide a (frontline) Windows 365 Cloud PC to your users who really need access to certain data from an unmanaged device. Or provide them with corporate applications using Windows 365 Cloud Apps. But such a solution comes with an additional cost.
This shifts the trust boundary from the unmanaged endpoint to a managed cloud-hosted Windows environment, where session persistence is controlled.
That’s it for now in this post to make you aware of the web application behaviour on unmanaged devices. I wonder what your thoughts are about this topic and the steps you take to limit the impact of this.
