API security in 2025 exposes identity and access control gaps

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Raidiam's blog post: Most enterprises still under-secure APIs because authentication, authorisation, and monitoring do not match the sensitivity of the data they expose.

Why it matters: IAM, security architecture, and PAM teams need to treat APIs as identity-bound access paths, because weak request-level controls turn every integration into a data exposure risk.

By the numbers:

• Over 80% of enterprises had API defenses dangerously misaligned with the sensitivity of their data.
• Only one of 68 organizations used full mTLS and certificate-bound tokens.
• Over 70% of surveyed organizations lacked any form of contextual or fine-grained access control.

Context

API security is the control problem that sits between identity assurance and data exposure. When APIs become the default integration layer, every request inherits an access decision, and weak binding between client identity, user context, and transport protection turns that decision into a durable risk.

Raidiam’s checklist frames the issue as a governance gap, not simply a coding problem. The article ties authentication strength, fine-grained authorisation, transport integrity, and monitoring to financial-grade API expectations, which is the right lens for enterprises that still treat API controls as a thin technical layer.

The practical takeaway is that API programmes now need to be managed as identity pathways with explicit ownership, measurable assurance, and runtime enforcement. That starting point is typical across modern enterprises, but the depth of control maturity is still highly uneven.

Key questions

Q: What fails when workloads still rely on shared API keys and static secrets?

A: Shared secrets make workload identity opaque, because the same credential can be copied across services, pipelines, and runtimes without any reliable proof of which workload used it. That weakens revocation, provenance, and accountability, and it expands blast radius when one secret leaks. The governance failure is treating machine access like a reusable human password.

Q: Why do poorly designed APIs create such a large data exposure risk?

A: Poorly designed APIs often expose too much data, fail to validate access consistently, or rely on outdated controls that no longer match current attack patterns. Because APIs connect services and expose structured objects, a single weakness can let attackers enumerate records, automate requests, and extract sensitive information at scale. The risk grows when design, implementation, and configuration are not reviewed together.

Q: What are the signs that an API authorization control is failing in practice?

A: Common warning signs include endpoints returning valid data without a token, access to records that should be scoped to another user, and responses that expose credentials or keys in configuration data. Another indicator is when iterating a parameter reveals large volumes of records in predictable increments. Those patterns suggest broken object or function level authorization, not just a minor configuration issue.

Q: Should security teams prioritise mTLS or ABAC first for API protection?

A: They solve different problems, so the answer depends on the gap. mTLS strengthens caller authentication and token binding, while ABAC reduces what a validated caller can do. If the main weakness is credential replay, start with mTLS. If the main weakness is excessive data access, start with contextual authorisation.

Technical breakdown

Why static API keys fail as an identity control

Static keys and shared secrets identify a calling system only at provision time, not at request time. Once issued, they can be copied, replayed, or reused outside their intended context unless the organisation binds them to transport, client certificate, or token claims. That is why OAuth 2.0 with PKCE, private_key_jwt, and mTLS matter: they make the authentication event harder to transplant. Certificate-bound tokens add another layer by tying authorisation to the presenting certificate rather than to a bearer token alone.

Practical implication: treat any API key that cannot prove the caller’s live identity as an exposure path, not an acceptable default.

How fine-grained authorisation limits API blast radius

Authorisation depth determines how much damage a valid caller can do after authentication succeeds. Attribute-Based Access Control and OAuth scopes make the decision depend on client identity, user context, and requested action, rather than on broad application membership. That matters because APIs often expose more fields, objects, or functions than the request actually needs. In practice, least privilege for APIs is not a slogan. It is the difference between a narrow data transaction and a bulk extraction path.

Practical implication: constrain each API to the smallest data set and function set the transaction actually requires.

Why monitoring belongs inside the API trust model

APIs need monitoring because identity controls fail quietly when abuse looks like normal traffic. Rate limiting, logging, anomaly detection, and endpoint-level audit trails are how teams detect scraping, partner misuse, token replay, and low-and-slow data extraction. Without that telemetry, the defender cannot distinguish legitimate integration from adversarial automation until the loss is already large. In identity terms, detection is part of authorisation assurance because it validates whether the original trust decision still holds.

Practical implication: instrument every sensitive API with request logging and anomaly detection that can surface abuse before it becomes a breach.

Threat narrative

Attacker objective: The objective is to extract sensitive data or abuse trusted API functions without triggering controls that would normally constrain or detect the request pattern.

1. Entry begins when an attacker or abusive partner uses an exposed API path, weak authentication, or a compromised integration credential to reach data or functions that should have been constrained.
2. Credential abuse or authorisation failure follows when static keys, broad scopes, or missing context checks let the caller operate beyond its intended trust boundary.
3. Impact occurs when the API is used for scraping, excessive data retrieval, or sustained unauthorised access before monitoring detects the activity.

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.
• Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.

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

API security is now an identity assurance problem before it is a transport problem. The article is strongest when it shows that most enterprise failures are not about API volume but about whether the caller can prove who it is, what it may do, and whether its behaviour stays within the expected boundary. That places API governance squarely inside IAM, not beside it. Practitioners should treat request-level identity as the primary control plane.

Fine-grained authorisation is the real blast-radius control for APIs. Broad application access has become too coarse for modern integration patterns, especially where one API path can expose many records or functions. ABAC, scopes, and contextual policy are not optional extras. They are the mechanism that stops valid access from becoming bulk exposure, and that is the control question security leaders must keep asking.

Monitoring is part of access governance, not a separate operations afterthought. A request that looks legitimate can still represent abuse, scraping, or excessive extraction if telemetry is too thin to detect patterns over time. That is why API logging, anomaly detection, and auditability belong in the same governance conversation as authentication and authorisation. Teams that separate them are governing half the trust model.

Context-bound identity is the named concept this article points toward. API security in 2025 depends on binding the caller, the context, and the transaction together so that a credential alone is never the full basis for trust. The implication is clear: identity programmes that stop at issuance will keep missing the real control boundary. Practitioners need request-time assurance, not just provisioning-time control.

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.
• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: API Key Management Guide

What this signals

Context-bound identity: API programmes now need to prove that the caller, the request, and the data being accessed belong together. If authentication is static and authorisation is broad, the control breaks at the exact point where integration becomes exposure.

The governance shift for practitioners is from protecting an API perimeter to governing each request as an identity event. That is why request logging, contextual policy, and token binding need to be treated as control requirements, not optional hardening.

For practitioners

• Replace static API keys with stronger caller identity Move sensitive integrations to OAuth 2.0 with PKCE, private_key_jwt, or mTLS so the caller proves identity at request time instead of relying on a reusable shared secret.
• Bind tokens to the presenting certificate Use certificate-bound tokens for high-value APIs so token replay is harder and the request is tied to the authenticated client certificate.
• Apply contextual policy to every sensitive endpoint Use ABAC and scoped authorisation to narrow access by client, user, and action, especially where APIs expose multiple objects or datasets.
• Add endpoint-level telemetry for abuse detection Log requests, watch for scraping patterns, and alert on unusual access volume so monitoring can validate whether the original trust decision still holds.
• Assign explicit API security ownership Give product, engineering, and security teams a shared control model for authentication, authorisation, and auditability so gaps do not fall between functions.

Key takeaways

• API risk in 2025 is driven less by the existence of integrations than by weak caller identity, broad authorisation, and thin monitoring.
• Raidiam’s research shows a large mismatch between enterprise API defences and the sensitivity of the data those APIs reach, with mTLS and fine-grained access still uncommon.
• The practical response is to bind access to live identity, limit what each request can do, and instrument sensitive endpoints so misuse can be detected early.

Key terms

• API Key: A unique identifier used to authenticate a software application or service when calling an API. API keys are static, long-lived credentials and a major source of secrets sprawl. In 2024, over 50 million leaked API keys were found on the dark web.
• 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.
• Fine-Grained Authorization: Fine-grained authorization is access control that evaluates specific resources, actions, and context rather than granting broad application-level permission. For AI agents, this is the difference between merely connecting to a system and being limited to the exact data or action the task requires.
• Contextual Access Control: Contextual access control changes access decisions based on factors such as device posture, application risk, location, or data sensitivity. In cloud security, it helps move access policy from static entitlements toward decisions that reflect the actual conditions of use.

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.