API security examples show why cryptographic identity matters

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Raidiam's blog post: Weak authentication, static keys, and absent runtime controls turn APIs into identity problems as much as application problems.

Why it matters: It matters because API governance now depends on cryptographic identity, token scope, and monitoring patterns that IAM, PAM, and NHI teams can actually govern.

By the numbers:

• 84% of surveyed organisations are exposing sensitive data via weak API security practices.

Context

APIs are now a primary trust boundary for digital services, and the security problem is no longer limited to application flaws. When a client can authenticate with a reusable key or secret, the API behaves like an identity system with weak issuance, weak binding, and weak revocation.

This article focuses on cryptographic identity for APIs, meaning the client proves who it is with a certificate or signed assertion rather than a shared secret alone. That framing matters for IAM and NHI governance because API access can outlive the business relationship, the deployment context, or the original risk decision.

Raidiam’s examples show the same pattern across misuse, scraping, and data breach scenarios: access control fails when identity is easy to copy, replay, or overextend. That is a typical failure mode in modern API estates, not an edge case.

Key questions

Q: What breaks when APIs still rely on static keys and shared secrets?

A: Static keys break the assumption that a client credential is hard to copy, hard to replay, and easy to revoke. Once keys are embedded in apps or reused across environments, anyone who extracts them can act as the client until the secret is replaced, so blast radius grows quickly.

Q: Why do weak API credentials and service accounts increase breach risk?

A: Weak credentials and over-privileged service accounts increase risk because attackers only need one successful authentication path to move from access to abuse. In API environments, machine identities often have long-lived trust and broad entitlements, which makes them attractive targets. The more persistent the credential, the more time an attacker has to explore and extract data.

Q: How can security teams tell whether API access is properly scoped?

A: A simple test is whether a valid low-privilege credential can reach another customer’s object, another device, or an adjacent record outside its assigned scope. If that succeeds, the API is enforcing identity but not object-level permission, and the access model is too broad for the data it protects.

Q: What should teams do when an API endpoint is exposed without rate limits or monitoring?

A: Treat the endpoint as abuse-ready and restrict it before scaling traffic or adding new partners. Apply throttling, validation, logging, and alerting together, because once an attacker can automate calls, the API can become a data-scraping or enumeration path very quickly.

Technical breakdown

Why static API keys fail as identity

A static API key is a reusable bearer credential. If it is hardcoded in a mobile app, copied into logs, or shared across services, anyone who sees it can reuse it until someone rotates it. The problem is not just secrecy but lack of binding, scope, and expiry. In practical terms, the credential proves possession, not context, so an attacker who extracts the key can act exactly like the legitimate client. This is why static keys become a governance problem as soon as APIs carry real customer or operational data.

Practical implication: treat reusable API keys as a temporary compatibility measure, not a long-term trust model.

How mTLS and private_key_jwt change client authentication

Mutual TLS and private_key_jwt turn client authentication into a cryptographic proof, not a shared-secret lookup. mTLS binds the client to a certificate at transport level, while private_key_jwt uses a signed assertion that is harder to replay or intercept than a client secret. Together they raise the cost of impersonation because the token or session is tied to a specific key pair or certificate. This shifts API security from password-like authentication toward identity proofing for machine clients, which is closer to how regulated open banking and federated ecosystems have to operate.

Practical implication: prefer cryptographic client authentication wherever an API carries sensitive or high-volume data.

Why rate limits and token binding are access control, not just performance tuning

Rate limiting is often treated as a traffic-management feature, but in API security it is a containment control. Without throttling, attackers can enumerate records, scrape data, and brute-force weak endpoints at machine speed. Token binding, short-lived access tokens, and certificate-bound access tokens reduce the value of theft because the stolen token is not enough on its own. The broader architectural point is that API authorisation must account for replay, automation, and misuse patterns, not only for legitimate business calls.

Practical implication: combine throttling, anomaly detection, and token binding as one control layer around sensitive APIs.

Threat narrative

Attacker objective: The attacker wants reusable access to API-backed data or functions at scale without needing ongoing authorization from the real client.

1. Entry occurs when an attacker gains access to a weak API client credential, a public endpoint, or a partner-style access path that does not strongly bind identity to the caller.
2. Credential access follows through exposed static keys, weak OAuth client authentication, or replayable tokens that can be copied and reused outside the intended client context.
3. Escalation happens when the attacker can automate requests at scale, enumerate records, or bypass missing rate limits and validation to expand the scope of access.
4. Impact is mass data exposure, scraping, or unauthorized modification of customer and operational records, often before the abuse is detected.

Breaches seen in the wild

• T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.
• Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cryptographic identity is now the control plane for API governance: APIs that rely on shared secrets treat machine clients like weakly authenticated users. That model collapses once partners, apps, and workloads all need different scopes, different trust levels, and different revocation paths. The implication is that API teams must govern clients as identities, not as convenience tokens.

Static secrets create identity reuse debt: A client secret or hardcoded API key is not just a credential, it is a reusable authorization shortcut that often outlives the business decision behind it. Once the same secret is copied into multiple environments or apps, revocation becomes uncertain and blast radius expands. Practitioners should read this as a lifecycle failure, not a single control miss.

API abuse is increasingly an IAM problem with application symptoms: Rate limits, monitoring, and scope design are now part of identity enforcement because they shape how far a client can go after authentication succeeds. That is why the strongest API security programmes pair cryptographic binding with least privilege and runtime detection. Teams that separate app security from identity governance miss the real control surface.

Bounded trust for machine clients: This article reinforces that machine identity cannot be governed as if authentication alone were enough. A valid client identity still needs proof of possession, scope containment, and replay resistance before the access decision is safe. The practitioner takeaway is to close the gap between who the client claims to be and what it can actually do.

API security maturity is moving toward federated trust models: The examples point toward architectures where certificates, signed assertions, and short-lived tokens replace reusable shared credentials. That direction aligns API security with modern identity governance because issuance, rotation, and revocation become explicit lifecycle events. Practitioners should expect API trust to look more like federated identity and less like static integration plumbing.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• Read next: API Key Management Guide

What this signals

Cryptographic identity for APIs: The real shift in API security is away from reusable shared secrets and toward identity proofs that can be scoped, bound, and revoked. That matters because machine clients are now part of the identity estate, not just a transport detail.

When an API client can be replayed from anywhere, access control is only as strong as the secrecy of the key. Practical governance has to move upstream to issuance, binding, and lifecycle control rather than relying on downstream detection alone.

The article’s examples also show that API abuse is often a control composition failure. Rate limits, validation, and token binding only work together when the access model is designed around machine identities from the start.

For practitioners

• Replace shared API secrets with cryptographic client authentication Use mutual TLS or private_key_jwt for clients that access sensitive data or high-value functions. Avoid relying on client_secret_post or client_secret_basic alone when the credential can be copied or replayed.
• Bind tokens to the client that received them Adopt certificate-bound access tokens or equivalent binding so a stolen token cannot be reused from another device, app, or partner integration.
• Enforce scope, expiry, and revocation discipline Issue the minimum scopes needed, keep access tokens short-lived, and maintain a clear revocation path for partner apps, service clients, and embedded mobile credentials.
• Instrument APIs for abuse, not just uptime Apply rate limits, anomaly detection, and request validation to exposed endpoints so scraping, enumeration, and brute-force abuse are constrained even when authentication succeeds.
• Review every hardcoded or embedded API key Search mobile code, repositories, and deployment artefacts for static keys, then classify each one by scope, expiry, and whether it can be safely retired or replaced.

Key takeaways

• Weak API security is no longer just an application flaw, because reusable credentials and permissive endpoints make machine access a governance problem as well.
• Raidiam reports that 84% of surveyed organisations are exposing sensitive data through weak API security practices, which suggests the issue is widespread rather than isolated.
• Cryptographic client authentication, short-lived tokens, and runtime abuse controls are the controls that change the risk profile most directly.

Key terms

• Cryptographic Identity: Cryptographic identity is a trust model in which authentication depends on verifiable keys, certificates, or signed assertions rather than shared secrets alone. It is essential for machines and agents because it gives the organisation a stronger way to prove identity and revoke access quickly.
• Certificate-Bound Token: A certificate-bound token is tied to a specific client certificate so it cannot be freely replayed from another device or session. This reduces interception risk and strengthens proof that the caller presenting the token is the same entity that was originally trusted.
• Client Authentication Method: A client authentication method is the mechanism an OIDC client uses to prove its identity to the token endpoint. Common methods include shared-secret approaches and private key JWT. The provider must recognise the registered method, otherwise the code exchange fails even when the rest of the flow is configured correctly.
• Rate Limiting: A control that restricts how many requests a caller can make within a defined period. It protects availability and reduces abuse, but it only works when paired with correct authentication, authorisation and endpoint design.

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 building or maturing an IAM programme, it is worth exploring.