Follow login and the session after it

Review MFA coverage separately from the mechanisms that stop an authenticated session.

When to use this guide

Use this when administrative, contractor, and recovery access have different entry and invalidation routes.

Describe authentication exceptions and the scope of sessions that can be invalidated.

1 / 3
Map all identity routes
Map normal, emergency, and recovery routes for each identity type from configuration records.
Evidence to retain
Routes, covered identities, owners, and exceptions.
2 / 3
Compare methods and exceptions
Review MFA methods and coverage, including ownership of exceptions and legacy methods.
Evidence to retain
Enforcement conditions and the rationale and owner for exceptions.
3 / 3
Trace invalidation to the receiver
Use existing implementation and test records to trace which sessions are rejected and when.
Evidence to retain
Session type, environment, and records demonstrating rejection.

Administrators use MFA, but recovery or contractor access follows separate routes.

Use configuration records to map identity types and login routes without opening secret values.

A suspected endpoint compromise requires understanding which authenticated sessions can be stopped.

Read where the identity provider and application maintain sessions and how invalidation is designed.

Stolen credentials for a contractor administrator account without MFA enabled a ransomware intrusion.

A compromised service account accessed support files. Session tokens in HAR attachments enabled hijacking of some customer sessions.

Selected examples. Each record retains its evidence status, unknowns, and sources.

Multifactor authentication: Authentication combining different factor types, such as knowledge and possession. Review the method and the routes where it is enforced.; Are administrative and recovery routes covered by the intended policy?; Open the related inspection rule →
Session: The mechanism maintaining identity after login. Where and how it can be invalidated depends on the service.; Where is continued use stopped after logout or a compromise response?; Open the related inspection rule →
Revocation: Making an old credential or session unusable at the accepting system. Verify this separately from issuing a replacement.; What evidence shows that the old credential is rejected after replacement?; Open the related inspection rule →

MFA availability alone does not verify controls for an already compromised session.
Treat service-account authentication and production invalidation actions as separate scopes.

Use separate evidence for strengthening authentication and stopping continued authenticated use.

References and review dates

OWASP: Multifactor Authentication Cheat Sheet ↗
Passkeys; MFA Attack Patterns and Mitigations
OWASP: Session Management Cheat Sheet ↗
Session Expiration; Automatic Session Expiration

Learning review 2026-11-12 · Catalog review 2026-11-09

Share these two rules and examples without expanding the scope. Checks without evidence remain unverified.

Check what was actually deployed
Connect the running version with the external code executed on its way to deployment.
Review secret handling without opening values
Map exposure paths and the process for invalidating old credentials after replacement.
Review exposure and data that remains
Review storage exposure together with the handling of retired environments and data copies.
Keep user and organization data separated
Connect resource authorization with the boundaries controlling reuse of generated responses.
Trace input into queries and file processing
Follow inputs from entry points to SQL construction and file storage or processing.
Separate the blast radius from recovery
Connect reachable resources with containment and restoration records.
Set AI boundaries before delegating a task
Review destinations, action authorization, and traceable records at the execution boundary.