Users think of passwords as the credential that keeps them signed in, but many applications stop asking for the password after authentication. Instead, the browser or application receives a session credential that proves the user has already authenticated.
What a session token does
A session cookie or token allows repeated requests without asking for the password each time. It improves usability but becomes a valuable credential while it remains valid.
Password changes may not end sessions
Some services invalidate existing sessions after a password reset; others do not. During an incident, explicitly review session revocation and refresh-token controls rather than assuming a password change is sufficient.
Browser security matters
Malware, malicious extensions, insecure devices, and browser-profile compromise can expose session data. Device protection is therefore part of account security.
Use appropriate cookie controls
Web applications should use secure cookie attributes, HTTPS, appropriate session lifetimes, and protections against cross-site scripting and request forgery. The exact implementation depends on the application architecture.
Shorter sessions reduce exposure
Highly privileged systems may justify shorter idle or absolute session lifetimes. Convenience and risk need to be balanced according to the sensitivity of the application.
Include sessions in incident playbooks
Credential-response procedures should identify whether administrators can revoke sessions, refresh tokens, remembered devices, and application-specific tokens.