Notifications
Clear all
Topic starter
06/06/2026 2:24 am
TL;DR: API keys are simple but brittle at scale, while JWTs add claims, expiry and local validation for distributed systems, according to Aembit. Both still depend on secrets, which is why workload identity federation is emerging as the cleaner path for service-to-service access.
NHIMG editorial — based on content published by Aembit: API keys, JWTs and workload identity federation for API authentication
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Inventory every API key and JWT signing secret Map where each credential exists across code repositories, CI/CD systems, chat tools and deployment variables.
- 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.
- 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.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Practical examples of when API keys remain acceptable for low-risk integrations and when they become a governance liability.
- JWT validation guidance covering signature algorithms, claim checks and failure modes that implementation teams need to test.
- A step-by-step explanation of workload identity federation across major cloud platforms and CI/CD environments.
- A direct comparison of secret bootstrap patterns versus secretless runtime attestation for service access.
👉 Read Aembit's analysis of API keys, JWTs and workload identity federation →
API keys vs JWTs: where static secrets stop scaling?
Explore further
06/06/2026 4:04 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: API keys vs JWTs: why secretless workload identity is next
