The standard incident-response playbook for a leaked credential is a password reset. It is fast and it is auditable, and against a stolen session cookie it is approximately useless, because most session infrastructure does not bind session validity to password state.
We sampled stealer records containing session cookies for services where validity could be tested passively, and measured the interval between an observable password change and actual session invalidation. The median window in our sample ran to days. For several enterprise SSO configurations, sessions survived until their natural expiry, up to three weeks after the "remediation".
SESSIONS SURVIVING THE RESET
sample · passively testable servicesThe fix is procedural rather than architectural: session revocation belongs in the same runbook step as the reset. If your identity provider exposes a "sign out all sessions" API, wire it into the credential-leak response. If it does not, that is a question worth asking your vendor this quarter.
This is also why Sherlog treats cookies as first-class records instead of metadata. A leak notification that says "password exposed" and omits "with 14 active session cookies" has reported the smaller half of the incident.