Microsoft 365 Stay Signed In Security Risks: What Decision Makers Must Know
The "Stay signed in" feature in Microsoft 365 may seem like a harmless convenience, but it introduces a hidden vulnerability that can quietly undermine your organisation’s entire security posture.
While most IT teams focus on enabling multi-factor authentication (MFA), disabling legacy protocols and enforcing conditional access, few realise that a single checkbox at login can bypass these protections. This blog post explores the overlooked risks of persistent sessions in Microsoft 365 and outlines the steps decision makers must take to mitigate them.
The Convenience Trap: Why “Stay Signed In” Is a Security Blind Spot
The “Stay signed in” prompt appears after a user enters their credentials on the Microsoft 365 login page. If selected, it stores a persistent cookie in the browser that allows refresh tokens to silently renew access tokens for up to 90 days. This means users can remain authenticated without re-entering passwords or passing MFA checks, even after restarting their browser or device.
On personal or trusted devices, this may seem acceptable. But on shared or unmanaged machines, it becomes a serious liability. Anyone with access to the same browser session could inherit the authenticated state and gain access to sensitive data without ever signing in. This undermines the very controls organisations rely on to protect their digital assets.
For decision makers, this is not just a technical oversight—it’s a strategic risk. Persistent sessions can lead to unauthorised access, data leakage and compliance violations, especially in regulated industries. The solution is simple but powerful: disable the “Stay signed in” prompt and enforce reauthentication through conditional access policies.
How Persistent Cookies Bypass Your Security Stack
When a user logs into Microsoft 365, they receive an access token that lasts for about an hour. Once it expires, a refresh token is used to silently generate a new access token. If the “Stay signed in” option is enabled, Microsoft places a persistent cookie in the browser that allows this refresh token to continue working for up to 90 days.
This persistent cookie survives browser restarts and system reboots. It effectively creates a long-lived session that bypasses password prompts and MFA challenges. On a shared device, this means that someone else could open the same browser days or weeks later and still have access to Microsoft 365 services.
This behaviour is particularly dangerous in environments where devices are shared across departments or used by contractors. A single click can leave a door open for weeks, allowing unauthorised access to email, SharePoint, Teams and other sensitive resources. Even if your organisation has robust security policies, this one setting can quietly erode their effectiveness.
Disabling the “Stay signed in” prompt is a critical first step. It ensures that users must reauthenticate, reducing the risk of session hijacking and reinforcing your organisation’s security posture.
Conditional Access: Enforcing Sign-In Frequency for Better Control
Disabling persistent sessions is essential, but layered security is the key to resilience. Microsoft Entra ID allows administrators to create conditional access policies that enforce sign-in frequency. This means users will be prompted to reauthenticate at intervals you define, even if they are on trusted devices or apps.
For example, you can set a policy that requires users to sign in every four or eight hours. This ensures that long-lived sessions are periodically interrupted, forcing users to re-enter credentials and pass MFA checks. It adds a layer of control that prevents silent access and ensures that authentication remains active and intentional.
Conditional access policies can be targeted to specific users, groups or resources. You might choose to apply stricter policies to departments handling sensitive data, such as finance or legal. The flexibility of Microsoft Entra ID allows you to tailor your security strategy to your organisation’s risk profile.
Implementing sign-in frequency policies is straightforward. In the Entra admin centre, navigate to Conditional Access, create a new policy, select your target users and resources, and define the session controls. This small change can significantly reduce the risk of persistent session abuse and strengthen your overall security framework.