TL;DR: APIs now underpin core business systems, but 94% of organisations have seen API security problems in production and 19% have already had an API-related breach, according to SALT. That shifts API security from a technical hygiene task into a governance problem where discovery, runtime control, and change velocity all matter.
NHIMG editorial — based on content published by SALT: How Protecting Your APIs Protects Your Bottom Line
By the numbers:
- 94% of survey respondents had experienced API security problems in production, with 19% admitting to an API-related breach.
- 11% of respondents update their APIs daily, and 31% update them weekly.
- Businesses that utilize APIs were 12.7% more profitable over the past decade than those that did not use APIs.
Questions worth separating out
Q: How should security teams govern APIs that change frequently?
A: Security teams should treat fast-changing APIs as continuously governed assets, not quarterly review items.
Q: Why do AI agents create new risk for IAM and NHI programmes?
A: Because they can execute actions, inherit permissions, and connect to sensitive systems without a human acting each time.
Q: What breaks when API security is based only on vulnerability scanning?
A: What breaks is the assumption that every API risk is a code flaw.
Practitioner guidance
- Map every API to an owning identity and business process Build an authoritative inventory that links each API to a service account, token issuer, application owner, and data class.
- Add runtime authorisation checks to high-value APIs Validate scope, role, and request context during live traffic, especially where APIs carry customer data or trigger financial actions.
- Include API credentials in lifecycle and rotation controls Treat API keys, OAuth tokens, and certificates as governed secrets with expiry, rotation, and offboarding rules.
What's in the full article
SALT's full ebook covers the operational detail this post intentionally leaves for the source:
- Benchmark-style discussion of how API security ties to risk reduction, compliance exposure, and revenue outcomes.
- Business cases for reducing remediation cost and downtime by improving API visibility and runtime detection.
- Practical discussion of how security teams can use AI and ML to automate manual API security workloads.
- Examples of how organisations evaluate whether API protection is reducing control gaps at production scale.
👉 Read SALT's ebook on how protecting APIs protects the bottom line →
API security and attack surface control: what IAM teams need to know?
Explore further
API security is now an identity governance issue, not a niche application-control problem. APIs are the place where tokens, service accounts, and partner access intersect with business logic, so weak visibility becomes an identity failure as much as an application one. Traditional IAM controls struggle when access is mediated by machine credentials and rapidly changing integrations. The practitioner conclusion is clear: API governance must be treated as part of the access fabric, not a separate security silo.
A question worth separating out:
Q: Who is accountable when a partner API exposes customer data?
A: Accountability sits with both the API owner and the team governing the credential lifecycle. If third-party access is not scoped, monitored, and revoked when no longer needed, the organisation has accepted standing trust without lifecycle control. Frameworks such as NIST CSF and zero trust place that responsibility on access governance.
👉 Read our full editorial: API security is now a governance issue, not just a breach issue