Why do short-lived OIDC tokens still leave organisations exposed?

Why This Matters for Security Teams

Short-lived OIDC tokens are often treated as a complete control, but token lifetime only limits how long a compromised credential can be replayed. It does not narrow what the identity can do during that window. If a CI/CD workflow, cloud deployment job, or AI agent can publish artifacts, assume broad roles, or chain into downstream systems, an attacker who hijacks that workflow still inherits too much authority.

This is why short TTLs must be paired with narrow trust boundaries, explicit audience restrictions, and request-time policy checks. The issue is visible across real incidents: OAuth and token abuse repeatedly turn “temporary” access into meaningful compromise, as seen in the Salesloft OAuth token breach and the OneLogin API Key Vulnerability. In practice, many security teams discover the real exposure only after a workflow has already been abused, not during the design review.

The broader pattern is also reflected in NHIMG research: the 2025 State of NHIs and Secrets in Cybersecurity reports that 60% of NHIs are overused, meaning the same identity is shared across multiple applications and blast radius grows quickly when one token is compromised.

How It Works in Practice

OIDC reduces static secret sprawl by letting a workload present a signed assertion and receive a short-lived token, but that token still carries the permissions assigned to the underlying identity. The security question is not “How short is the TTL?” but “What can this identity do if the token is stolen while valid?” That is why current guidance increasingly favors workload identity, just-in-time credential issuance, and context-aware authorization over broad standing entitlements. Standards-oriented approaches such as SPIFFE and policy engines like Open Policy Agent are often used to bind identity to workload and evaluate access at request time.

For agents and automation, this usually means three layers:

• Authenticate the workload itself, not just the job runner, using a cryptographic workload identity.
• Issue an ephemeral token for a single task, with audience, scope, and TTL constrained to that task.
• Check policy at runtime so the action is allowed only if the current context matches the approved intent.

That model is especially important when tokens can be exchanged into broader cloud privileges, package registries, or internal APIs. A short-lived token is safer than a long-lived one, but it is still a high-value bearer credential if the trust boundary is too wide. NHIMG’s 52 NHI Breaches Analysis shows how identity misuse often becomes a lateral-movement problem, not a simple credential theft problem. The same dynamic is appearing in agentic systems, where autonomous workflows can chain tools faster than defenders can review logs, a risk highlighted in Anthropic’s first AI-orchestrated cyber espionage campaign report.

These controls tend to break down when one identity is reused across many pipelines, because the token remains valid long enough to reach high-impact targets before revocation or detection can occur.

Common Variations and Edge Cases

Tighter token controls often increase operational overhead, requiring organisations to balance faster delivery against stronger request-time governance. There is no universal standard for this yet, especially in multi-agent or heavily automated environments where policy must be evaluated against intent, data sensitivity, and execution path all at once.

One common edge case is a “temporary” token that can still mint other credentials. In that scenario, the original TTL matters less than the downstream exchange path. Another is overly broad OIDC audience configuration, where a token issued for one service is accepted by several. A third is agentic automation that completes many actions inside a single short session: if the agent is compromised early, the attacker gets the full task chain before expiry.

Best practice is evolving toward narrower federation, explicit task scoping, and automated revocation on task completion. For teams that want to see how overexposed identities and token lifecycle failures compound, the Guide to the Secret Sprawl Challenge is a useful reference point. The practical lesson is that short-lived OIDC is a containment aid, not a full governance model, and it should be treated as one control in a layered trust design rather than the final control.

Related resources from NHI Mgmt Group

• When do short-lived access tokens still leave organisations exposed?
• Why do short-lived credentials still leave organisations exposed?
• Why do short-lived tokens still create major risk in CI/CD environments
• When does short-lived access still leave an organisation exposed?