Session Hijacking Risks

A software vendor had implemented FIDO2 hardware key MFA for all employees , an authentication posture frequently described as the strongest broadly-available option. Their session management, however, issued access tokens with a twenty-four hour validity period and refresh tokens with a thirty-day validity period. An attacker who compromised an employee's workstation through a phishing-delivered malware payload did not attempt to defeat the hardware key MFA , they simply harvested the session tokens from the browser's token storage. The valid access token provided twenty-four hours of API access. The valid refresh token provided thirty days of session renewal without any reauthentication. The attacker maintained access to the vendor's systems for nineteen days before the compromise was detected through downstream anomalies. During those nineteen days, the attacker accessed customer data, exfiltrated configuration details, and established persistence through additional mechanisms. The authentication was phishing-resistant and undefeated throughout. The session management that followed the authentication was the attack surface the attacker used.

What are Session Hijacking Risks, Really?

Session hijacking is the attack technique of stealing the post-authentication session credential , typically a session cookie, access token, or refresh token , and using it to access systems as the authenticated user without repeating the authentication process. Modern web applications and APIs use bearer tokens for session management: after authentication, a token is issued to the client that the client presents to prove prior authentication on subsequent requests. Whoever holds the token can make requests as the authenticated user , the token itself carries the authentication assertion, independent of the identity of whoever presents it.

The token theft attack surface is diverse and larger than most authentication-focused security programs account for. Tokens can be stolen from browser storage (cookies and localStorage) through cross-site scripting vulnerabilities or browser extension compromise. They can be captured from memory on compromised endpoints. They can be harvested from log files that inadvertently capture token values. They can be extracted from network traffic if TLS is not enforced end-to-end. They can be obtained through open redirect attacks that route token delivery to attacker-controlled endpoints. Each of these theft vectors bypasses authentication entirely , the attacker never needs the user's password or MFA device.

Token lifetime management is the primary governance lever for session hijacking risk. A short-lived access token (fifteen minutes) limits the attacker's window to the token's remaining validity at the time of theft. A long-lived access token (twenty-four hours) provides the attacker a full day of access. A refresh token (thirty days) provides the ability to renew access indefinitely without reauthentication. Token lifetime decisions that optimise for user experience , reducing reauthentication friction , systematically expand the session hijacking attack window. The most convenient session management for users is the most valuable session management for attackers.

• Long-lived access tokens , token validity periods measured in hours or days rather than minutes
• Long-lived or non-expiring refresh tokens , persistent refresh capability providing extended access without reauthentication
• Token storage in vulnerable client-side storage , browser localStorage, session storage, or insecure cookie configurations
• No token binding or device binding , tokens that are valid from any device after being issued to a specific one
• No anomalous token usage detection , token use from unusual IPs, devices, or geolocations not flagged

Why this matters

Session hijacking risk matters for TPRM because vendors who hold valid session tokens for customer environment access provide an additional attack vector beyond credential theft. Even if vendor employee credentials and MFA are secure, their session tokens represent valid access that can be stolen from endpoints, from memory, or from network traffic. A vendor with robust authentication but weak session management is providing an attacker with a credential alternative that bypasses the strongest authentication entirely.

The token persistence in cloud and SaaS environments has made session hijacking increasingly consequential. Modern cloud APIs use long-lived access tokens and persistent refresh tokens for operational convenience , developers and integrations need sessions that do not expire during long-running operations. These same long-lived tokens are the target of session hijacking attacks against cloud infrastructure and SaaS platforms. An attacker who obtains a cloud console access token with a twenty-four hour validity has cloud access for twenty-four hours regardless of the authentication posture that produced the token.

Where most teams get this wrong

The most consistent failure is treating authentication strength as equivalent to post-authentication security. FIDO2 hardware keys are unphishable. The session token they produce after authentication is a bearer token that provides equivalent access to anyone who holds it. Authentication security and token security are different properties requiring different controls. Confirming the first without assessing the second describes half the access security posture.

• Treating authentication strength as equivalent to session security
• Token lifetime not assessed , access and refresh token validity periods
• Token storage security not evaluated , browser storage, cookie flags, client-side token handling
• No anomalous token usage detection assessed
• Token binding capability not assessed , whether tokens are device-bound or freely transferable

What good looks like

Mature session security programs combine short token lifetimes with continuous access evaluation , short-lived access tokens that limit the theft window, refresh tokens that require additional verification for renewal, continuous access evaluation that revokes sessions in real time when risk signals change, and anomalous token usage detection that flags tokens being used from unexpected locations.

• Short access token lifetimes , fifteen to sixty minutes for sensitive resource access
• Continuous access evaluation , session validity continuously assessed against current risk signals, not just at authentication
• Anomalous token usage detection , tokens used from different IPs, devices, or geolocations than original authentication
• Secure token storage , HttpOnly, SameSite, Secure cookie flags; access tokens not stored in localStorage
• Token revocation capability , ability to revoke all active sessions for a compromised identity immediately

Tooling

Continuous Access Evaluation , Microsoft Entra CAE, Okta Continuous Access

Continuous access evaluation platforms re-evaluate session validity in real time rather than relying on token expiry alone , revoking sessions immediately when risk conditions change (password reset, account suspension, network change) without waiting for the token to expire. Microsoft Entra's CAE integration with Microsoft 365 and Azure services provides near-real-time session revocation for risk events. For TPRM practitioners, asking whether the vendor uses continuous access evaluation for sessions with customer environment access provides a specific post-authentication security question.

Token Security , PKCE for OAuth, DPoP token binding, Secure cookie configuration

Proof Key for Code Exchange (PKCE) prevents authorisation code interception attacks. DPoP (Demonstrating Proof of Possession) token binding binds access tokens to the specific client that requested them, preventing tokens from being used from different clients if stolen. For TPRM practitioners, asking whether the vendor implements token binding for API access tokens provides a specific token theft mitigation question.

Governance challenges

The governance challenge with session management is the usability tension. Short token lifetimes and continuous reauthentication requirements create friction for users and operational disruption for automated processes. Session security that is optimised purely for security is often unusable in practice. The governance resolution is risk-tiered session management: shortest token lifetimes for highest-risk access (production environment admin), longer lifetimes with continuous evaluation for standard access, and separate token management for machine-to-machine access.

• Ask about access and refresh token lifetime for sensitive resource access
• Ask about continuous access evaluation , real-time session revocation capability
• Ask about anomalous token usage detection , sessions used from unexpected locations
• Ask about token revocation capability , how quickly all sessions can be revoked for a compromised identity
• Include session security in identity security assessment alongside authentication strength

If you are a small team

Ask your highest-risk vendors two questions that specifically target the post-authentication attack surface. First: what is the validity period of the access tokens and refresh tokens issued after authentication to your platform , and can those tokens be used from any device or are they bound to the authenticating device? Second: if a vendor employee's session token were stolen by malware on their workstation today, how long would the attacker have valid access to your systems before the token expires or before you could detect and revoke it? The second question forces a concrete assessment of the session hijacking window.

• Ask about access and refresh token validity periods
• Ask whether tokens are device-bound or freely transferable
• Ask how long a stolen token would provide valid access
• Ask about continuous access evaluation and session revocation capability

What to require

Ask directly:

"What are the validity periods for your access tokens and refresh tokens , and how long would a stolen session token provide valid access to your systems before expiring or being revocable?"

"Do you implement continuous access evaluation that revokes sessions in real time when risk conditions change , or does session validity depend solely on token expiry timers?"

Expect as evidence

• Access and refresh token lifetime documentation
• Continuous access evaluation implementation confirmation
• Session revocation capability and response time
• Anomalous token usage detection description

A vendor who confirms FIDO2 hardware key MFA should be asked what the validity period of the session token issued after that authentication is , and whether the token can be used from a different device if stolen. The authentication was unphishable. The token is a bearer credential. Those are different security properties. Ask about both.

How to evidence it

• Token lifetime documentation for sensitive resource access
• Continuous access evaluation implementation
• Session revocation capability confirmation
• Token security assessment records

Key Takeaway

The strongest authentication issues a bearer token at its conclusion. That token is the target. An attacker who cannot defeat FIDO2 hardware key MFA can defeat a twenty-four hour session token that was stored in browser memory and extracted by malware in sixty seconds. The authentication security and the session security are independent properties. The nineteen-day attacker access was through the token, not through the authentication , the hardware key was never touched. Short-lived tokens, continuous access evaluation, anomalous usage detection, and session revocation capability are the session security controls that limit what an attacker can do with a stolen token. The authentication front door is secure. The session window determines how long the stolen key keeps working.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations