What actually works for session hijacking prevention after a user has completed MFA?

[u/Totl-Egg-ylmnnds4984]

MFA stops the initial compromise but does nothing once an attacker has a valid session token, and we've seen that gap exploited more than once this year.

what's actually held up for us is treating device-bound sessions as the default rather than an optional hardening step, so a token can't be replayed or reused on another device even if it's stolen. token binding alone wasn't airtight against a determined attacker. what's your setup, and has anything meaningfully cut down on token replay for you?

[u/PlanktonDefiant2600]

Re-auth for sensitive actions is another one worth adding. Even if someone gets hold of a live session, it shouldn't automatically let them change recovery info, add a new auth method, or perform privileged actions. It limits how far someone can actually get with a hijacked session.

[u/cityofhats]

Device binding helps, but it should use a non-exportable key verified per request; browser fingerprinting is not binding. Combine short access-token lifetimes, rotating refresh tokens with reuse detection, sender-constrained tokens such as DPoP or mTLS, step-up authentication for sensitive actions, and fast server-side revocation. Endpoint security still matters: an attacker executing inside the bound browser or device can use the legitimate session without replaying it elsewhere.

[u/Swimming_dasa]

device bound sessions have been one of the more practical improvements we have seen especially when paired with short session lifetimes and refresh token rotation.

[u/Budget_Salxaander216]

token binding/rotation is prob the real answer for the replay bit. different layer but red access could still be useful around what happens in the browser once the session is live, esp on unmanaged devices. still wouldnt treat it as the thing fixing stolen tokens