7 Session Lifetime Controls That Contain Token Theft

A stolen session token skips your password and your MFA prompt entirely, and the length of the session — not the strength of the authentication factor — usually decides how much damage one compromise can do. The seven session lifetime controls below shrink that exposure window across AWS STS and Microsoft Entra ID using settings that already exist in both platforms, with no new product purchase required.

The threat model is documented, not hypothetical. NIST and CISA jointly published an interagency report on protecting tokens and assertions, warning that hybrid and multi-cloud environments increasingly rely on signed tokens and assertions that adversaries target for forgery, theft, and misuse to move laterally across enterprise networks and reach sensitive data. Session lifetime policy is one of the few controls that keeps working after the initial theft.

Why tokens outlive MFA

Modern phishing kits do not try to defeat your second factor; they proxy the login, harvest the resulting session cookie or bearer token, and replay it from infrastructure the attacker controls. From the provider’s point of view, the replayed request carries a validly issued credential, so it succeeds until that credential expires or is revoked. MFA protects the front door; token lifetime controls how long the intruder gets to stay inside once the door has been opened.

That distinction matters operationally. A team that assumes MFA equals protection tends to set generous session lengths for convenience, which quietly converts every successful phishing email into hours — sometimes days — of access that no authentication step will ever challenge again. Treat session duration as a blast-radius control and the math changes: every hour you remove is an hour an attacker cannot use.

Set hard session ceilings in AWS

AWS gives you the knob directly in STS. AssumeRole accepts durations from 900 seconds (15 minutes) up to the role’s maximum session duration of 1 hour to 12 hours, with a default of 3600 seconds, and role chaining caps any chained session at one hour. Most break-glass and interactive roles need far less than the ceiling, so lower the role-level maximum rather than hoping callers pass a short DurationSeconds value.

Three moves cover the AWS side:

1. Reduce the maximum session duration on every human-facing role to the shortest value your workflows tolerate; automation that legitimately needs longer should get its own role with a documented reason.
2. Add the aws:MultiFactorAuthPresent condition to trust policies for privileged roles, so assuming them without a valid MFA context is denied at the API layer, not just at the console login.
3. Use role chaining deliberately for the most sensitive work: because chaining limits sessions to one hour, a pipeline that chains roles gets a hard expiry for free.

Pair this with restricting how roles and endpoints can be reached in the first place — the controls described for function URL abuse prevention follow the same principle of shrinking reachable surface before worrying about exploitation.

Tighten Microsoft Entra token lifetimes

Entra ID’s defaults are reasonable but not conservative: the Microsoft identity platform assigns a default access token lifetime as a random value ranging between 60-90 minutes (75 minutes on average), while Continuous Access Evaluation sessions can extend tokens to 24-28 hours when both client and resource support it. CAE tokens are revoked in near real time on critical events such as account disablement and password changes, which is why the longer window is allowed — but only for CAE-capable clients.

The configuration surface has traps worth knowing. Since January 30, 2021, refresh and session token lifetimes are no longer configurable through token lifetime policies; the AccessTokenLifetime property, which governs access, ID and SAML2 tokens, spans 10 minutes to 23:59:59 and is managed only through Microsoft Graph or its PowerShell SDK, with no portal UI. To force more frequent reauthentication of users, Conditional Access sign-in frequency and session lifetime controls are the supported path.

A seven-control session checklist

The last row is the one teams skip: lifetime controls buy time, and detection tells you whether you needed it. Alerts on impossible-travel token use, or a session suddenly originating from a new network, convert a passive ceiling into an active defense.

Trade-offs teams must accept

Every reduction in session length trades user friction and token-service load for containment. Shorter access tokens mean more token requests, which can surface rate limits during peak hours and break scripts that cache credentials for hours. CAE mitigates the revocation gap but only for clients that negotiate it, so a mixed estate still carries long-lived tokens unless you inventory which applications actually support CAE.

The discipline is the same one that governs cryptographic key rotation — you accept recurring operational work because it bounds the lifetime of any single stolen secret. The migration planning approach outlined for post-quantum cryptography migrations applies here: inventory first, classify by blast radius, then roll out ceilings in stages with rollback criteria.

Start with privileged roles and administrator accounts, measure complaint volume for two weeks, then extend to routine workforce access. Teams that go the other direction — blanket one-hour limits for everyone on day one — usually generate enough breakage that the policy gets rolled back entirely.

Sources

• AWS Security Token Service — AssumeRole API Reference
• Microsoft Learn — Configurable token lifetimes in the Microsoft identity platform
• CISA — Protecting Tokens and Assertions from Forgery, Theft, and Misuse