Session Invalidation: Why Changing a Password Doesn't Kill Active Sessions
Session invalidation is how a web application terminates active sessions when the credential behind them changes, like a password change, role change, or logout. Most applications do not do this by default. Once a user logs in, their session token stays valid until it expires, so changing a password usually does not log out other devices.
When a customer leaves your company, you disable the account. When an employee changes a password after a suspected compromise, you assume the old access is gone. In most web applications, that assumption is wrong. A changed password revokes the credential, but the sessions created before the change keep working, sometimes for hours, sometimes until the timeout clock runs out. The missing session invalidation is one of the most common patterns in our authenticated web application assessments: the application validates the password once, at login, and then trusts the session token without checking whether the identity behind it is still current.
The stakes on access management are not sitting still. CISA published an alert on October 16, 2026, urging organizations to patch a critical vulnerability in BeyondTrust Remote Support, a product whose core job is to manage privileged remote sessions [2]. And the cost of getting access wrong keeps climbing. IBM's Cost of a Data Breach Report 2026 puts the global average cost of a data breach at $4.99M, up 12% year over year, and reports a 56% increase in AI-driven attacks, led by deepfake impersonations and AI-enabled malware [3]. A session that outlives its owner is a standing invitation, and the attackers on the other side of your login screen are more capable than they were a year ago.
Does Changing Your Password Invalidate Other Sessions?
No, not by default. A password change invalidates the credential, not the sessions that were built on top of it.
Here is how the login flow actually works. The user types the password, the application checks it, and the application issues a session token. From that moment on, the token is what travels with every request. OWASP's session management guidance puts it directly: once an authenticated session has been established, the session ID is temporarily equivalent to the strongest authentication method the application uses [1]. If the strongest method was username and password, the token now is username and password. And the application checked the password exactly once, at login.
In our assessments, this is the pattern we keep finding. The password reset flow works. The new credentials log in immediately. And every session that was already open keeps working until its natural expiration, because the application validated the identity once and never re-checks it. The team that built the reset flow tested the question "can I log in with the new password?" and almost never tested the question that actually matters: "does the old session still work?"
Why Do Sessions Outlive the Credentials That Created Them?
Because HTTP is stateless, and the application's trust model checks the token, not the identity behind it.
Every request the browser makes has to carry its own proof of who it is. That proof is the session token, and a token is cheap to issue and, if the application never looks behind it, cheap to trust for the life of the session. A well-built session design keeps the token short-lived and the identity current. The gap opens the moment the token becomes the whole security decision, and the application stops asking whether the person it is talking to is still the person it authenticated.
What the implementation should get right
There are three layers to check, and they are all in the public guidance, which is the problem. They are documented, so they are assumed.
The token itself. OWASP requires at least 64 bits of entropy, generated by a cryptographically secure random number generator. In its own example calculation, 64 bits of entropy takes about 585 years to brute-force at 10,000 guesses per second against 100,000 active sessions [1]. The sheet also recommends generating tokens with at least 128 bits, and storing them hashed rather than in plain text where the session store could be read [1]. High entropy protects you from guessing. It does nothing for a token that is simply exposed.
The cookie flags. Secure and HttpOnly are mandatory in OWASP's guidance, not optional. SameSite should be set explicitly, to Strict or Lax, and the __Host- prefix binds the cookie to HTTPS at the browser level [1].
The exchange mechanism. The token should travel only in cookies. If the application also accepts a session ID in a URL parameter, the token leaks into logs, referrer headers, and browser history, and it opens the door to session fixation. OWASP is explicit that applications should test every accepted mechanism and limit it to cookies [1]. In testing, we check this deliberately, and some applications still accept URL-based session IDs as a fallback for legacy clients.
What Should a Working Session Invalidation Design Include?
Every credential and role event should be an invalidation event. The session has to die the moment the identity behind it changes, not the moment the clock runs out.
The Clone Systems Session Lifecycle 6-Point Check is the list we use to grade the gap between what a web app's design says and what the application actually does:
- Regenerate on login. The session identifier should be re-issued after every successful authentication, so a pre-login or stolen token cannot be carried into the authenticated session.
- Invalidate on logout. Server-side. Clearing the cookie in the browser leaves the token valid until it expires.
- Invalidate on password change. Every active session for that user should terminate the moment the password changes. This is the one most applications skip.
- Invalidate on role change and deactivation. A promotion, a demotion, and a termination are all identity events. In our assessments, role changes and offboarding rarely reach existing sessions. A tester who is promoted, or deactivated, during an engagement can often keep working at the old clearance level for hours, because the session was issued against the old role and the application never re-derives it.
- Enforce both timeouts. An idle timeout and an absolute timeout, sized to the data the session can reach. The timeout caps your maximum exposure. It is not a substitute for invalidation, and invalidation is not a substitute for it.
- Verify SSO revocation at both layers. When the application trusts a token from the identity provider, a password change at the identity layer does not touch the application session. Most deployments enforce revocation at only one of the two layers. Test which one is yours.
How Do You Find Out Whether Your Application Actually Invalidates Sessions?
You test it while logged in. A scanner that walks your application logged out cannot see session behavior at all, because the behavior only exists after authentication.
Here is the test you can run on your own staging environment, with no tooling required:
- Log in to the application in one browser.
- Log in as the same user in a second browser, or a private window.
- Change the password in the first browser.
- Go back to the second browser and keep working.
If the second browser keeps working, your application does not invalidate sessions on password change. Then repeat the exercise with a role change, and with single sign-on if you use it. Fifteen minutes of manual testing answers a question that no scan report will. It also shows the developers exactly what the expectation is, which is the part that usually gets left out of the requirements.
The BeyondTrust alert from CISA [2] is useful here for a second reason. It shows what happens when the product that manages sessions and access carries a critical defect. The vendor ships the patch. The process gap, the quiet assumption that sessions die when credentials die, is the one you own. And the IBM 2026 numbers [3] describe who is knocking: a 56% increase in AI-driven attacks, led by deepfake impersonations and AI-enabled malware. The attackers who reach your login screen are more capable than they were last year. A long-lived session is a standing invitation, and it is the kind of finding that only shows up when you test the application logged in.
If you are not sure what your application actually does here, an authenticated web application security scan is the fastest way to find out. Clone Systems' credentialed and web application scanning covers session behavior as part of testing with logged-in access. Credentialed and web application scanning
Session Invalidation vs Session Timeout: What Is the Difference?
A timeout is a clock. Invalidation is an event.
- A timeout fires on a schedule, either when the user is idle or when the session hits its absolute limit. Invalidation fires the moment a credential or role event happens.
- A timeout catches a password change only when the clock runs out. Invalidation catches it immediately, if it is implemented.
- A timeout does nothing for a role change. Invalidation can, if it is wired to the identity store.
- A timeout caps your maximum exposure. Invalidation keeps the access state correct.
A secure application has both, and neither one covers the other. A timeout that never expires is not a timeout, it is an open door. And the 585-year brute-force number in OWASP's example [1] only protects you if the token actually dies when the identity does.
How Clone Systems Can Help
Our credentialed and web application scanning programs test the application the way a real session would experience it: logged in, across multiple concurrent sessions, with credential and role changes applied mid-test. We check token regeneration, cookie attributes, the accepted exchange mechanisms, and invalidation on each credential event, and we document the difference between what the design says and what the application actually does. The output is a list of the specific events your application fails to react to, which is exactly the list your developers need to work from. See the credentialed and web application scanning service. If you would rather see a live walkthrough, you can reach us through the contact page.
Frequently Asked Questions
Does changing your password log out other sessions? No, not in most web applications. A password change revokes the credential, but existing session tokens keep working until they expire, unless the application is built to invalidate them on that event.
What is session invalidation in a web application? It is the termination of active sessions when the credential, role, or account status behind them changes. It is the difference between a session that dies with its owner and one that lives on to its timeout.
How long should a web application session last? Use both an idle timeout and an absolute timeout, and size them to the data the session can reach. There is no single correct number, because the right value depends on sensitivity and on whether invalidation on credential events is implemented.
How do you test whether your application invalidates sessions? You test it while logged in, with a credentialed web application security assessment. Log in from two sessions, change the password in one, and see whether the other keeps working.
Does single sign-on change how session invalidation works? Yes. When the application trusts a token from the identity provider, a password change at the identity layer does not touch the application session, so revocation has to be enforced at both layers.
Conclusion
The password is the door. The session is the person already inside. Most applications are built to check the door and then stop checking. The organizations that get session handling right treat the session as a claim about the current identity, and invalidate it the moment that claim goes stale. Run the two-browser test this week. If your second browser keeps working after the password change, you now know exactly where your gap is. And when you are ready for the full picture of what your application does while logged in, Clone Systems is the place to start.
References
[1] Session Management Cheat Sheet, OWASP Cheat Sheet Series, 2026. https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html [2] Cybersecurity Alerts and Advisories, CISA, 2026. https://www.cisa.gov/news-events/cybersecurity-advisories [3] Cost of a Data Breach Report 2026, IBM Security and Ponemon Institute, 2026. https://www.ibm.com/reports/data-breach [4] Clone Systems, Credentialed and Web Application Scanning. https://www.clone-systems.com/credentialed-scanning/