API keys vs JWTs: why secretless workload identity is next

At a glance

What this is: This article compares API keys and JWTs for API authentication and argues that both remain limited by credential storage, sprawl and rotation burden.

Why it matters: It matters because IAM teams must govern service accounts, CI/CD identities and workload access with the same discipline they use for human access, especially when static secrets become the weakest link.

👉 Read Aembit's analysis of API keys, JWTs and workload identity federation

Context

API authentication still fails when the organisation treats a credential as the identity instead of a proof of runtime trust. API keys are fast to deploy, but they create a governance problem as soon as they spread into repositories, pipelines and chat threads. In identity programmes, that is not a tooling issue. It is a lifecycle problem for non-human identities.

JWTs improve context by carrying claims, expiry and audience checks, but they do not remove the need to protect signing keys and validate every token correctly. The real governance shift is toward workload identity federation, where a service proves where it is running instead of presenting a long-lived secret. That changes how IAM, PAM and platform teams think about service trust boundaries.

Key questions

Q: What breaks when API keys are used for service-to-service access at scale?

A: API keys break down when teams need scoped permissions, short-lived access or reliable revocation. A leaked key can survive in code, pipelines and chat logs long after it should be removed, and the organisation often cannot inventory every copy. At scale, the problem becomes lifecycle control, not simple authentication.

Q: Why do JWTs still leave organisations with identity risk?

A: JWTs reduce reliance on central sessions, but they still depend on signing keys, validation logic and refresh flows. If claim checks are weak or the signing key leaks, the token model can be abused quickly. JWTs improve context, but they do not eliminate secret handling or governance burden.

Q: How do security teams know when to move from API keys to workload identity?

A: The pivot is justified when access must be tied to runtime context rather than static possession. If credentials are spreading into repositories, CI/CD systems or chat tools, the current model is already harder to govern than it looks. Workload identity is the cleaner choice when secret distribution has become the main risk.

Q: What is the difference between secret rotation and workload identity federation?

A: Secret rotation keeps the credential model intact and changes the value on a schedule. Workload identity federation removes the stored secret from the flow and exchanges runtime proof for temporary credentials. For workloads, that difference matters because federation reduces the number of places a durable secret can leak.

Technical breakdown

API keys as static non-human identities

An API key is a long-lived bearer credential. Whoever possesses it can use it until the issuer revokes it, which makes the key a static identifier rather than a rich authorisation object. That model is easy to understand, but it creates a weak lifecycle posture because the same secret often appears in code, pipelines, local configs and chat. Once spread, the key is difficult to inventory, rotate or scope precisely. The result is secrets sprawl, which turns one identity into many untracked copies.

Practical implication: treat every API key as an inventory and revocation problem, not just an authentication mechanism.

JWT claims, validation and the limits of context-aware tokens

A JWT is a signed token that can carry identity, scope and time-based claims, which makes it useful for distributed services that need local validation. The security value depends on correct enforcement of signature checks, issuer, audience and expiry. If validation is weak, or if the signing key is exposed, the token format creates false confidence. JWTs reduce some reliance on central sessions, but they still depend on secret material and disciplined lifecycle control for keys and refresh flows.

Practical implication: validate every JWT claim explicitly and treat signing-key protection as part of identity governance.

Workload identity federation and the secret-zero problem

Workload identity federation replaces stored secrets with runtime attestation. The service proves its identity through the environment it is running in, then exchanges that proof for short-lived credentials. This removes the bootstrap secret that many teams need to get started, which is the secret-zero problem. It also changes governance because access is tied to runtime trust relationships rather than a static credential copied into multiple systems. In practice, this aligns better with zero standing privilege for workloads.

Practical implication: move high-trust service interactions toward federated runtime identity instead of long-lived embedded secrets.

Threat narrative

Attacker objective: The attacker aims to turn one leaked machine credential into durable service access that can be reused across environments and workflows.

1. Entry occurs when an API key or JWT signing secret is copied into source code, CI/CD variables, local configs or chat threads and then exposed outside the intended control boundary.
2. Credential access follows when an attacker or contractor reuse path locates the leaked secret in one of the many stored copies and tests it against the API.
3. Escalation happens when the same credential grants broader access than intended, or when a signing key lets the attacker mint accepted JWTs for additional requests.
4. Impact is unauthorised service access, data exposure, or downstream abuse across systems that trusted the static credential as proof of identity.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static API credentials are lifecycle failures, not just authentication weaknesses. API keys answer the question of who called the API, but they do not answer whether the credential should still exist six months later. That is why the problem shows up in repositories, pipelines and chat systems rather than in the auth flow itself. The security failure is the absence of lifecycle control for a non-human identity. Practitioners should treat key sprawl as a governance defect, not a developer convenience.

JWTs reduce session dependence, but they do not eliminate identity trust debt. A signed token is only as strong as its validation logic, signing-key protection and claim boundaries. Organisations often celebrate the move from API keys to JWTs without noticing that the same secret-handling burden remains underneath. That means the governance model improves on context, but not on secret elimination. The implication is that token sophistication is not the same as identity maturity.

Secretless workload identity is the point where non-human identity governance becomes structurally cleaner. Workload identity federation shifts trust from stored credentials to runtime attestation, which aligns access with execution context rather than static possession. That matters because possession-based models fail as soon as secrets are copied into places governance cannot see. For IAM and platform teams, this is the category boundary where credential management stops being the centre of the design.

Secret sprawl is the named concept this article exposes. A single API key or signing secret becomes a distributed identity fragment when it is copied into code, chat, CI/CD and local environments. Once that happens, revocation becomes a coordination problem across systems rather than a single control action. Practitioners should recognise that the real blast radius is created by copies, not by the original credential alone.

Workload identity governance is now part of mainstream IAM, not a niche cloud pattern. The same access principles used for humans, service accounts and privileged workflows now have to cover federated workloads that never should have had durable secrets in the first place. This is where NHI governance, zero standing privilege and platform identity controls converge. Teams that keep secrets as the default will keep inheriting the same failure mode in a new form.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• For the adjacent control problem, read Guide to the Secret Sprawl Challenge for the remediation and inventory patterns that make secretless migration practical.

What this signals

Secret sprawl is now a governance signal, not a hygiene issue. When credentials are living in code and collaboration tools, the identity programme is already operating with incomplete visibility. The practical response is to tighten ownership, lifecycle tracking and revocation across workload identities before the next exposure forces it.

The migration path is increasingly clear for platform teams: keep static secrets only where there is a narrow, low-risk need, and push high-trust service access toward federated runtime identity. That shift reduces the number of durable credentials that IAM, PAM and cloud teams have to police across environments.

As organisations adopt more machine-to-machine access, the control question changes from how to rotate every secret faster to how to remove the secret entirely. That is the structural change that separates modern NHI governance from legacy service authentication.

For practitioners

• Inventory every API key and JWT signing secret Map where each credential exists across code repositories, CI/CD systems, chat tools and deployment variables. Assign an owner, a purpose and a revocation path for every instance, not just the original issuance record.
• Reduce standing credential scope Limit API keys to the smallest possible use case and remove any permission that is not required for the calling workload. Where the request needs user context or service scope, prefer short-lived JWTs with explicit audience and expiry controls.
• Treat signing keys as high-value NHI assets Place JWT signing material under stronger protection than ordinary application secrets, with controlled issuance, rotation and access logging. A compromised signing key can invalidate every token minted from it.
• Replace secret bootstrap flows with federation Move CI/CD and service-to-service access toward workload identity federation so the runtime environment proves identity directly. The goal is to eliminate the bootstrap secret that starts the secret-zero problem.

Key takeaways

• API keys are easy to deploy but poor at scale because they do not carry enough context to support modern service governance.
• JWTs add claims and expiry, but they still depend on strong validation and protected signing keys, which means the secret problem remains.
• Workload identity federation is the cleaner control model because it replaces durable secrets with runtime proof and temporary credentials.

Key terms

• Api Key: A long-lived bearer credential used to identify an application or service when it calls an API. It is simple to issue and simple to misuse because possession is usually enough to gain access, so lifecycle control and revocation discipline are essential.
• Json Web Token: A signed token that carries claims about identity, scope and timing. In practice, it is useful when a service needs context-aware authorisation without a central session lookup, but its security depends on strict validation and protected signing keys.
• Workload Identity Federation: A method of proving a workload’s identity at runtime and exchanging that proof for temporary credentials. It reduces dependence on embedded secrets by tying access to the environment and trust relationship rather than to a stored credential.
• Secret Zero: The initial credential needed to bootstrap access into a more secure system such as a vault or cloud service. It is a recurring weak point because the first secret often has to be stored somewhere before safer controls can take over.

Deepen your knowledge

API keys, JWTs and workload identity federation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are moving from static secrets to federated access, this is the right place to build the governance foundation.

This post draws on content published by Aembit: API keys, JWTs and workload identity federation for API authentication. Read the original.