Max age is an OpenID Connect parameter that tells the authorization server how old the user’s last authentication may be before reauthentication is required. It turns freshness into an enforceable policy. When the age exceeds the limit, the user must complete a new interactive challenge.
Expanded Definition
Max age is an OpenID Connect request parameter used to enforce authentication freshness. It limits how long the relying party will accept a prior user authentication before requiring a new interactive sign-in, even if a session or token is still otherwise valid. In practice, it is a policy control for time-based reauthentication, not a replacement for token expiry, session lifetime, or step-up authentication.
In NHI and agentic environments, the term matters because autonomous workflows often inherit human-authenticated context, and freshness requirements can determine when a high-risk action must pause for renewed proof of presence. Guidance varies across vendors on how max age interacts with SSO sessions, prompt caching, and downstream authorization decisions, so implementers should verify the relying party’s interpretation rather than assuming uniform behaviour. For protocol context, the OpenID Connect Core specification defines how authentication requests and session state can be evaluated, while NIST Cybersecurity Framework 2.0 helps frame freshness as part of access control governance. The most common misapplication is treating max age as a token expiration setting, which occurs when teams assume it will invalidate access tokens instead of forcing reauthentication at the next interactive checkpoint.
Examples and Use Cases
Implementing max age rigorously often introduces user friction and workflow interruption, requiring organisations to weigh stronger assurance against lower automation continuity.
- A finance portal sets max age to a short interval before wire approvals, so a user must reauthenticate before releasing funds after a period of inactivity.
- An AI-assisted admin console uses max age to ensure a privileged operator reenters credentials before approving secret rotation or IAM policy changes.
- A healthcare application binds max age to sensitive record access, so a clinician returning to a session must prove fresh authentication before viewing restricted data.
- An NHI governance review references the Ultimate Guide to NHIs to distinguish human authentication freshness from service account lifecycle controls.
- A standards-led implementation checks the OpenID Connect Core model alongside the NIST Cybersecurity Framework 2.0 to align reauthentication triggers with access review requirements.
Why It Matters in NHI Security
Max age matters because stale authentication context can become a hidden trust gap when humans approve actions that affect NHIs, secrets, or automation pipelines. If an operator authenticated hours ago and then returns to approve an API key export, deployment override, or agent instruction, the system may be relying on an assurance state that no longer reflects current intent. That creates a governance problem, not just a login problem.
NHIMG research shows only 5.7% of organisations have full visibility into their service accounts, and 79% have experienced secrets leaks, with 77% of those incidents resulting in tangible damage, according to Ultimate Guide to NHIs. In that environment, freshness controls help reduce the chance that a delayed approval or hijacked session becomes the last step before compromise. They also support broader zero-trust expectations described in NIST Cybersecurity Framework 2.0. Organisations typically encounter the need for max age only after a privileged session is abused or an approval occurs long after the original authentication, at which point reauthentication becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL2 | AALs define how strong and recent an authenticator event must be for access decisions. |
| NIST Zero Trust (SP 800-207) | PE-3 | Zero Trust decisions depend on continuously re-evaluated access context, including session freshness. |
| NIST CSF 2.0 | PR.AC-1 | Access control governance includes authentication recency and session assurance. |
| OWASP Agentic AI Top 10 | AGENT-08 | Agentic workflows must not rely on stale human approval when executing privileged actions. |
| OWASP Non-Human Identity Top 10 | NHI-01 | NHI governance depends on controlling when human-authenticated context can be reused. |
Require reauthentication freshness aligned to the needed assurance level before sensitive actions.
