The authentication path stays tied to secrets that can leak, be copied, or remain unrotated, so the organisation keeps the same NHI exposure even after adopting a newer trust model. Federation helps only when teams actually remove the standing credential from code, CI, and configuration paths.
Why stored API keys keep the old exposure model alive
Federation changes how an application proves who it is, but a stored api key still behaves like a standing bearer secret. That means the workload can continue to authenticate through a copied value instead of a shorter-lived, policy-bound trust path, so the older failure modes remain even after the new federation layer exists.
The practical difference is not just where the credential lives. With stored keys, compromise, reuse, and delayed rotation remain operationally normal, especially when the secret is embedded in source, CI, images, or deployment variables. With federation, the security gain only appears when the static credential is removed from those paths and the workload actually uses the federated identity path.
That is why stored API keys are often a migration smell rather than a harmless fallback. If the legacy key still grants production access, the organisation has not reduced its authentication exposure, it has only added another supported way to get in.
What still breaks when teams keep the secret in code and pipelines
The first break is blast radius. A stored key can be copied silently and reused anywhere it is accepted, which makes the workload harder to bind to environment, device, or runtime conditions. A federated flow is usually stronger because it can anchor access in issuer trust, audience checks, token lifetime, and workload context. The SPIFFE workload identity specification is a useful reference point for that model.
The second break is lifecycle control. Static secrets are easy to create and hard to retire cleanly, so they linger after migration, testing, vendor handoffs, or incident response. That is why an API key management program still matters during federation rollout, especially where a leftover key can bypass the intended trust path and keep code, CI, and configuration tied to long-lived access.
The third break is visibility. Teams often believe federation has solved the problem while old credentials remain valid in deployed artefacts, build logs, vaults, or environment stores. The most common operational failure is not technical incompatibility, it is partial migration, where both paths work and the weaker one becomes the default.
Why the migration is really about removing the standing credential
Federation is only a trust model if the workload stops depending on a reusable secret. In practice that means the application must exchange runtime trust for a token or assertion that is issued on demand, bound to the right audience, and short lived enough to limit reuse. The OpenID Connect Core 1.0 specification shows the same broader pattern on the authentication side: the security value comes from assertions and trust relationships, not from a secret that lives forever in the client.
For workloads, that migration usually succeeds only when teams also eliminate secret distribution paths. If the key remains in a config file, CI variable, or container image, the application still has a static credential that can be leaked, cloned, or inherited by downstream environments. A good migration therefore treats key removal as part of the trust-model change, not as a cleanup task that can happen later.
The best comparison is simple: federation reduces the need to store a reusable secret, but it does not automatically erase the secret that was already there. The security outcome depends on whether the old credential is truly removed from every execution path that can still use it.
Risk and Threat Considerations
Keeping stored API keys after federation is available creates a dual-control problem: the organisation now has a stronger path and a weaker path in parallel, and attackers will look for the weaker one. That raises the odds of secret leakage, replay, and silent persistence because a copied key can continue working even after the federated path is deployed.
Failure mechanism: The standing credential remains usable in code, CI, deployment configuration, or runtime variables, so compromise of any one of those locations still yields direct access.
Impact: The organisation carries forward the same non-human identity exposure, with longer-lived access, larger blast radius, and a higher chance that incident response will miss the real ingress path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Stored API keys are long-lived secrets that keep workload access reusable. |
| NHI-02 — Secret Leakage | The question centers on secrets that can leak from code, CI, or config. | |
| Recommendation — Replace static API keys with short-lived, federated credentials and remove standing secrets from runtime paths. Scan code, CI, and deployment paths for exposed keys and revoke any leaked secret immediately. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Stored API keys are authenticators whose lifecycle must be managed and revoked. |
| IA-9 — Service Identification and Authentication | Workload-to-workload federation changes how non-human services authenticate. | |
| AC-6 — Least Privilege | Residual API keys often preserve access broader than the new federated path needs. | |
| Recommendation — Rotate, revoke, and inventory authenticators so legacy keys cannot remain active after migration. Use service authentication controls that bind access to the workload and retire reusable shared secrets. Limit any remaining credential to the minimum scope needed and remove excess privileges during migration. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Federation commonly uses OIDC/OAuth flows instead of stored API keys. |
| Recommendation — Prefer federated authentication flows and validate token handling, issuer trust, and audience checks. | ||
| CIS Controls v8 | CIS-5 — Account Management | Legacy API keys are standing accounts that need lifecycle control and removal. |
| Recommendation — Inventory and disable obsolete access paths so deprecated keys do not remain usable after federation. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | API keys are the authentication mechanism that can remain weak after federation is introduced. |
| Recommendation — Replace weak or reusable API authentication with stronger federated identity and rotate deprecated keys. | ||
Practitioner Guidance
What to verify: Confirm that the workload no longer depends on the stored key at runtime, not just that federation has been configured. Test the live path in production-like conditions and check that the old secret can be removed without fallback failures.
Common mistake: Treating “federation enabled” as equivalent to “legacy secret retired”. That shortcut leaves standing access in place and undermines the main security benefit of the migration.
Decision rule: If a key can still authenticate to production, prioritise secret removal, rotation, and inventory cleanup before calling the migration complete. If the key is only needed for a short transition window, time-box it and require evidence of full decommissioning.
Practitioner takeaway: Federation improves the trust model only when the old bearer secret is actually eliminated; otherwise the workload keeps the same exposure with a newer front end.
Related resources from NHI Mgmt Group
- What breaks when GitHub Actions jobs still rely on static API keys?
- What breaks when deleted API keys can still authenticate after removal?
- What breaks when cloud workloads still rely on stored secrets instead of federated identities?
- How should security teams govern API keys used for generative AI access?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org