Staying signed in to email keeps the inbox open without a password prompt, because the browser holds a session token after sign-in. The practice is reasonable on a private locked device with two-factor authentication, and risky on a shared, borrowed, public, or stolen device.
The safety question therefore turns on access to the device and the session, rather than on password strength. A signed-in session bypasses the password entirely, so anyone opening the browser on a device with a live session reaches the inbox without a sign-in check.
Signed-in sessions
At sign-in, a service checks the password and, where set up, the second factor, then gives the browser a session token, usually stored as a cookie, which the browser sends with later requests so sign-in is not required on every page. OWASP's session management guidance states that once an authenticated session is established, the session ID is temporarily equivalent to the strongest authentication method used, and that disclosure or capture of the ID leads to session hijacking, in which an attacker fully impersonates the victim. Whoever holds the token is treated as the account owner while the session lasts.
Session length extends that exposure. OWASP's Cornucopia card on session management describes a session with a long or missing inactivity timeout, or no overall time limit, as giving an attacker more time to use it, and recommends short inactivity timeouts and periodic termination even while a session is active. Neither Google nor Microsoft publishes a single default lifetime for a Gmail or Outlook web session, so a session cannot be assumed to expire soon on its own.
Private devices
A private device is the one case where staying signed in is easy to defend: the device belongs to one person, locks when idle, and the account has two-factor authentication, so exposure is limited to someone physically taking the unlocked device. Two habits still matter: a lock screen with a short timeout, because an unlocked laptop on a desk is effectively a signed-in inbox for anyone walking past, and trusted status only on a device that really is private.
Google's guidance on trusted computers explains that a trusted device skips the verification code on later sign-ins, and the two-step verification page states that the "Don't ask again on this computer" box should only be ticked on devices the person regularly uses and does not share.
Shared and borrowed devices
Shared and borrowed devices carry the most common failure: a family computer, a work computer used by several people, a friend's laptop, or a library computer all present the same problem, in that the next person to open the browser may already be signed in as someone else. Closing the browser tab does not fix this, because closing a tab hides the inbox without ending the session.
Google's guidance on staying signed in or out states that when a person signs in to a Google Account, that person stays signed in until signing out. For a public computer or someone else's device, Google advises browsing in private and closing all private browsing windows when done, which signs the person out automatically. That pattern is the safest for a borrowed device.
When sign-out on the device itself is no longer possible, remote sign-out is the remedy. Google's Gmail sign-out help describes signing out a lost or stolen device remotely through Security and sign-in, Your devices, Manage all devices. One detail is easy to miss: a device can show several sessions, and Google states that every session on a device must be signed out individually to ensure no account access from it. Skimwire's guide repeats that warning and adds a check of recent security events and Gmail forwarding settings after signing out, in case access was already used to set up forwarding.
The Microsoft side works differently, and the difference matters when time is short. Microsoft's sign out everywhere page states that after Sign out everywhere is used, the person is signed out of browsers, apps, and anywhere else the account is used to sign in within 24 hours, except an Xbox console, and that signing out may take up to 24 hours. A Microsoft remote sign-out is therefore not instant, and a password change as well stops the old device signing back in with a saved password. A detailed guide to removing a device syncing with Outlook.com makes the same point: removal on the device itself is reliable when the device is in hand, and Sign out everywhere plus a password change is the fallback when it is not.
Stolen devices
A stolen device combines both problems at once: the session is live, and the owner cannot reach the device to sign out. Remote sign-out remains the first move, but two limits apply. Signing out does not erase mail already downloaded to the device, so a stolen phone may still hold old messages. The Microsoft delay of up to 24 hours means a stolen device may keep working for some hours after the request. That is why a password change belongs in the same response, and why a lock screen and remote erase tools matter as a separate layer from the email account.
Two-factor authentication and live sessions
Two-factor authentication checks the sign-in, not the session that follows it: once the check has passed, the token is proof that it passed, and a copy of the token needs no second check. Notebookcheck's report on session cookie theft describes the mechanism plainly: an attacker needs neither the password nor the second factor, only the small file the browser stores after sign-in. Infostealer malware is the usual route, reading browser cookie storage on an infected machine and importing the cookie into the attacker's browser, after which the service sees a valid session and asks nothing more. IWTLP's piece on cookie theft explains the same mechanism from first principles: the token is the identity for the life of the session, so a copy is a working key that never passed the sign-in check.
The scale figures here are reported, not primary. Notebookcheck cites Flashpoint's Global Threat Intelligence Report as counting more than 11.1 million machines infected with infostealers in 2025, with 3.3 billion credentials and cloud tokens taken, excluding session cookies from that count. A separate article on browser-saved passwords and session cookies cites Flashpoint's mid-year 2026 figures of 7.4 million computers hit by infostealers in the first half of the year, with 1.7 billion credentials and session records taken. Vendor counts differ by methodology, so these are reported scale, not exact counts, and the mechanism does not depend on the exact number.
Changing the password after an infection is only half the fix. The Laurentiu article states that on many services a password reset stops new logins but does not immediately end active session cookies, so an attacker holding a stolen cookie can stay signed in for days unless the account security settings are used to end all sessions. Notebookcheck gives the same advice in the same order: for a malware infection, the system should be cleaned or reinstalled first, then passwords changed, then open sessions ended separately, because typing a new password on an infected machine hands it straight over.
Detection is also harder than expected: Mjolnir Security's detection guide notes that session cookies let an attacker walk straight past passwords and multi-factor prompts, and that a stolen session replayed from unfamiliar infrastructure is the signal that survives even when the host-side theft is missed. For an ordinary inbox owner, the visible version of that signal is an unrecognised device or location in the account's device list.
Device-bound session credentials
A developing fix for cookie theft is worth knowing about without overstating it. Chrome's device-bound session credentials tie a session to a cryptographic key held on the original device, so a copied cookie alone is not enough on another machine. TechSpot's report explains that the private key stays in protected hardware, such as the TPM on Windows or the Secure Enclave on Apple devices, and the site can require proof the browser still holds that key when refreshing the session, so a copied cookie without the key fails that challenge.
The rollout is not uniform. TechSpot describes a limited rollout for a subset of users, on Chrome 147 for Windows and 150 for macOS, while Notebookcheck describes a rollout since 25 May 2026 for Workspace accounts and personal Google accounts. The protection requires each site to support it, so it is not a blanket fix for every inbox yet, and it changes the future of session theft more than present practice.
Session measures
The measures that cover most cases follow from the sections above. Staying signed in is reasonable only on a private device with a lock screen. A "remember me" or "don't ask again" box should not be ticked on a shared or borrowed device, where a private window closed in full at the end of the task ends the session. The signed-in device list should be reviewed periodically, with anything unfamiliar signed out, remembering that Google requires each session on a device to be signed out individually. After a scare, the order is cleaning the device if malware is suspected, changing the password from a clean device, then ending all sessions explicitly. Guiding Tech's trusted device guide describes the revoke step for Google's trusted list, the same idea applied to trusted status: removing a device from the list means the second step is required again at the next sign-in.
Email aliases and signed-in sessions
AliasFleet gives every website its own email alias, so a site that leaks its customer list only ever held that site's alias, which can be paused or deactivated without touching the real inbox. The AliasFleet overview describes that per-site setup, and the AliasFleet homepage lists the same model: one real inbox, a separate alias per website, and a kill switch per alias.
That model does not fix a live session, and the limit should be stated plainly. An alias controls which address a website holds and what happens to mail sent to that address, but does nothing to a browser session already signed in to the inbox itself. If someone opens a signed-in inbox on a shared or stolen device, the mail is visible whatever address it was sent to. Aliases reduce the damage from the next site leak; they do not replace signing out, a lock screen, or ending sessions after a scare.
Session safety in brief
The answer splits by device: a private locked device with two-factor authentication makes staying signed in reasonable, while a shared, borrowed, public, or stolen device makes the same session an open inbox. Two-factor authentication guards the sign-in, not the session after it, and a password change on many services does not by itself end a live session. Device-bound credentials may narrow cookie theft, but until site support is universal, the session itself remains the thing to guard.
Top comments (0)