FAPI and mTLS expose the limits of static API key security

At a glance

What this is: This is an API security analysis arguing that FAPI and mTLS are becoming the practical baseline for protecting sensitive machine-to-machine access.

Why it matters: It matters because IAM, PAM, and NHI teams must treat API access as identity-governed privilege, not as a static secret exchange that can be safely reused.

By the numbers:

• 27 days
• 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.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Raidiam's analysis of FAPI, mTLS, and API key risk

Context

API security fails when a shared secret becomes the identity. Static API keys and bearer tokens are easy to copy, hard to scope, and often survive long after the access relationship that created them has changed. In practice, that turns machine-to-machine access into a standing privilege problem, which is exactly where IAM, NHI governance, and PAM controls must take over.

The article argues that FAPI-style controls, especially mTLS, certificate-based client identity, and sender-constrained tokens, close the trust gap left by static secrets. For security teams, the real issue is not whether APIs are encrypted, but whether each request is bound to a verifiable identity and a revocable credential state.

Key questions

Q: How should security teams replace static API keys in sensitive integrations?

A: Security teams should move sensitive integrations to certificate-bound client authentication, preferably with mTLS and sender-constrained tokens. That changes the trust model from secret possession to client proof, which reduces replay risk and makes stolen credentials less useful outside the original calling environment. It also creates a clearer lifecycle for revocation and review.

Q: Why do static API keys create more risk than many teams expect?

A: Static API keys create more risk because they are bearer credentials. Whoever holds the key can use it, often without additional proof of device, client identity, or request context. Once keys leak into code, logs, or tooling, they can be reused silently and indefinitely unless the organisation detects and revokes them quickly.

Q: What breaks when API access is managed like a shared secret instead of an identity?

A: What breaks is accountability, revocation, and scope control. Shared secrets can be copied, replayed, and embedded in multiple systems, so you lose confidence about who is calling, where the credential is stored, and whether access still matches the current integration. That is why API access must be governed as a machine identity lifecycle problem.

Q: Which frameworks should guide certificate-based API security decisions?

A: Teams should align sensitive API governance with the OWASP Non-Human Identity Top 10, NIST Cybersecurity Framework 2.0, and Zero Trust Architecture. Those frameworks help connect authentication strength, least privilege, lifecycle control, and detection into one operating model for machine-to-machine access.

Technical breakdown

Why static API keys create standing privilege

Static API keys are bearer credentials, which means possession is enough to use them. Once exposed in repositories, configuration files, logs, or developer tooling, they behave like long-lived secrets with no native proof-of-possession. That makes them fragile in modern delivery pipelines where machine access moves quickly across environments. The security weakness is not encryption alone, but the lack of identity binding, lifecycle controls, and request-level assurance. In NHI terms, the key becomes a standing credential rather than a governed workload identity.

Practical implication: classify every API key as a governed NHI secret and remove any dependency on long-lived bearer access for sensitive integrations.

How FAPI uses mTLS and sender-constrained tokens

Financial-grade API patterns extend OAuth 2.0 and OpenID Connect with mutual TLS, PKI-backed client identity, and certificate-bound access tokens. mTLS proves the client holds the private key associated with the certificate, while sender-constrained tokens ensure a stolen token cannot be replayed from another endpoint without the bound certificate. This is a different trust model from basic OAuth because the token is no longer sufficient on its own. The API call is authenticated as both a request and an identity event, which is why the model is attractive for high-value integrations.

Practical implication: move sensitive APIs toward certificate-bound authentication so that stolen tokens and copied secrets lose standalone value.

Why API security is becoming an identity governance problem

Once APIs carry payment, health, or partner data, access policy is no longer a developer convenience issue. It becomes lifecycle governance for non-human identities: who issued the credential, what it can reach, how it is revoked, and whether the client identity can be proven at runtime. FAPI matters because it shifts control from static shared secrets to managed client identities with revocation and assurance properties. That makes the operating model closer to NHI governance than traditional application configuration.

Practical implication: put API credentials into the same governance model you use for other non-human identities, including provisioning, review, and revocation.

Threat narrative

Attacker objective: The attacker wants to use a leaked machine credential to impersonate a trusted integration and operate through the API as if it were legitimate traffic.

1. Entry occurs when a static API key is exposed in code, configuration, or another reachable store and is then copied by an attacker.
2. Escalation follows when the key is replayed as a bearer credential, allowing access without device proof, certificate binding, or session-specific assurance.
3. Impact arrives when the compromised API identity is used to read, move, or alter data through privileged backend integrations that traditional perimeter controls do not see.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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 keys are a standing privilege model disguised as convenience. The article is right to treat bearer credentials as a structural weakness rather than a deployment shortcut. A copied key is indistinguishable from a legitimate caller, which means the control boundary collapses the moment the secret escapes its intended store. For IAM and NHI teams, that is a governance failure, not just a hygiene problem.

FAPI is winning because it turns API access into identity proof, not secret possession. Mutual TLS, PKI-based client identity, and sender-constrained tokens shift the trust anchor from a reusable string to a verifiable client. That is why this model maps cleanly to OWASP NHI and Zero Trust thinking: access is no longer presumed because a token exists, it is established because the caller can prove who it is at request time. Practitioners should read this as the next governance tier for sensitive machine identities.

Identity does not stay static long enough for bearer secrets to remain a safe governance primitive. The assumption that an API credential can be provisioned once, trusted broadly, and reviewed later was designed for stable access patterns. That assumption fails when modern delivery systems replicate secrets across repos, pipelines, logs, and partner integrations in minutes. The implication is that API governance must stop treating long-lived secrets as a manageable exception and start treating them as a broken premise.

API security is converging with NHI lifecycle governance. The article shows that the control question is no longer just authentication strength, but whether a machine credential has a clear owner, lifecycle, revocation path, and verification standard. That is the same governance pattern seen in service account management, workload identity, and privileged integrations. Practitioners should align API programmes with NHI governance rather than leave them in application security silos.

Certificate-bound access is becoming the practical dividing line for high-value APIs. Where an API moves money, regulated data, or partner trust, static secrets create too much replay risk to remain the default. FAPI-style controls do not eliminate abuse, but they sharply narrow what a stolen credential can do. For security architects, the implication is to prioritise identity-bound API access over universal bearer-token patterns.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• In the same research, AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• That pattern reinforces why organisations need to move from static bearer secrets to governed machine identities, as explored in the Guide to the Secret Sprawl Challenge.

What this signals

Secret exposure is now a governance problem, not just an incident response problem. If 64% of valid leaked secrets are still exploitable, teams that rely on detection without automated revocation are operating with a false sense of closure. The programme signal is simple: machine credentials need the same lifecycle discipline as other privileged identities, especially in API-heavy environments.

Static API keys will keep failing under modern delivery patterns because they cannot express trust context. As credentials spread through repositories, pipelines, and operational tooling, the control surface shifts from authentication to provenance and revocation. The practical signal is to treat every API integration as an NHI lifecycle object, not a developer convenience artifact.

Certificate-bound access is becoming the dividing line for sensitive APIs. In environments where replay or impersonation would be material, FAPI-style control patterns align better with Zero Trust and workload identity models than shared secrets do. Teams should watch their highest-value integrations first, then use that work to reset the rest of the machine access programme.

For practitioners

• Replace reusable bearer secrets in high-risk APIs Move sensitive integrations to certificate-bound client authentication and remove shared API keys from payment, health, and partner-facing flows.
• Inventory where API credentials actually live Search code repositories, CI/CD variables, logs, configuration files, and ticketing systems for exposed API keys and tokens, then classify them as governed NHI secrets.
• Bind access to client identity, not token possession Use mTLS and sender-constrained tokens for APIs where replay would create material impact, especially where backend systems trust the caller automatically.
• Put API credentials on a lifecycle schedule Assign an owner, review cadence, and revocation path to every machine credential so that API access is managed like other non-human identities.

Key takeaways

• Static API keys behave like standing privileges, which makes them a poor fit for sensitive machine-to-machine access.
• FAPI-style controls matter because mTLS and certificate-bound tokens turn API calls into verifiable identity events instead of reusable secret checks.
• IAM teams should manage API credentials as governed NHI assets with ownership, review, and revocation, not as application-only configuration.

Key terms

• Bearer Credential: A bearer credential is a secret that grants access to whoever possesses it, without additional proof of identity at use time. In API security, bearer design is convenient but fragile because copied tokens and keys can be replayed from anywhere until they are revoked or expire.
• Mutual TLS: Mutual TLS is a transport security pattern where both sides of the connection present certificates and verify each other. For API governance, it strengthens client authentication by binding access to a cryptographic identity rather than to a reusable shared secret.
• Sender-Constrained Token: A sender-constrained token is an access token that can only be used by the client that proves possession of the bound key or certificate. This reduces replay risk because stealing the token alone is not enough to impersonate the original caller.
• Machine Identity Lifecycle: Machine identity lifecycle is the end-to-end governance of non-human credentials from issuance to review, rotation, and revocation. It matters for APIs because access becomes sustainable only when each credential has a clear owner, purpose, expiry, and removal path.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Raidiam: The Leaders Are Already Securing APIs with FAPI + mTLS. Read the original.