API sprawl in financial services is outpacing security governance

At a glance

What this is: This is an analysis of how rapid API growth in financial services and insurance is exposing governance, visibility, and production security gaps.

Why it matters: It matters to IAM practitioners because API security now intersects with service identity, access scope, and runtime control across cloud and application programmes.

By the numbers:

• Over 50% of financial services and insurance organisations manage more than 500 APIs for development, delivery, and integration.
• 62% of financial services or insurance organisations have seen APIs increase by 50% or more in the past year.
• 25% of companies in the sector experienced an actual API breach in the past year.
• Only 1 in 5 organisations have an API posture governance strategy.

👉 Read Salt's report on API security risks in financial services and insurance

Context

API security has moved from a narrow application concern to a governance problem because the number of interfaces, services, and integrations now outstrips what many programmes can inventory and monitor. In financial services and insurance, that pressure is amplified by sensitive data, cloud migration, and the large number of APIs tied to customer-facing and internal workflows. The primary issue is not only exposure, but the lack of reliable visibility into what exists, what it touches, and who or what is allowed to use it.

For identity teams, the important connection is that APIs are often the enforcement point for service accounts, tokens, and delegated access paths. When inventories are incomplete and posture governance is weak, entitlement decisions become guesswork, and non-human identity controls cannot be applied consistently across the application estate. That starting position is now typical in sectors moving quickly through digital transformation.

Key questions

Q: What breaks when API inventories are incomplete?

A: When inventories are incomplete, teams cannot reliably know which APIs exist, what data they expose, or which identities and tokens can reach them. That breaks risk assessment, ownership, logging coverage, and incident scoping. The result is usually delayed remediation, hidden exposure, and inconsistent control enforcement across production services.

Q: Why do APIs create identity governance risk across machine and human access?

A: APIs often carry the real access decision for service accounts, tokens, and human sessions. If an API accepts the wrong identity context, broadens scope during errors, or leaks data in failure paths, the governance model is broken even when the application appears to work.

Q: How can teams tell whether API governance is actually working?

A: A working programme can answer four questions quickly: who owns the consumer, what it can access, where the policy is enforced, and how the call is logged. If any of those answers differ across protocols or gateways, the control model is fragmented and needs consolidation.

Q: Who is accountable when an API exposes regulated data?

A: Accountability usually sits with the business owner, security owner, and operational owner together. For regulated environments, teams need clear assignment for inventory, change approval, incident escalation, and evidence retention. If no one owns the API lifecycle end to end, compliance and response both degrade quickly.

Technical breakdown

Why API inventory gaps create security blind spots

An API inventory is the authoritative record of interfaces, owners, data exposure, and lifecycle state. When 14% of organisations are very confident their inventories are complete, the more common condition is partial discovery, stale documentation, and unclear ownership. That makes risk assessment difficult because defenders cannot map endpoints to business services, secrets, or privilege boundaries. In practice, missing inventory means unknown APIs may still accept authentication, expose sensitive data, or bypass standard review workflows. This is not just an application visibility issue, it is a control-plane failure for access governance.

Practical implication: establish continuous API discovery and ownership mapping before attempting broader security optimisation.

How production API posture governance reduces exposure

API posture governance is the set of controls that checks whether APIs are configured, documented, authenticated, authorised, and monitored according to policy. The report shows only 1 in 5 organisations have such a strategy, which means many are relying on ad hoc review rather than repeatable control checks. Posture governance matters because production APIs change quickly, while manual review cycles do not. When controls lag behind deployment, security teams find vulnerabilities only after release, or after attackers probe exposed endpoints. This is especially relevant where APIs mediate access for human users, service identities, and third-party integrations.

Practical implication: tie API posture checks to deployment gates and drift detection so configuration failures are caught in production workflows.

Why API security and identity governance now converge

APIs are increasingly the way applications authenticate, call services, and exchange data, so the security question is no longer limited to code quality. It becomes a question of identity scope, token handling, and access delegation. In identity terms, APIs often represent the runtime path through which non-human identities act, which means excessive permissions, weak secret hygiene, and poor offboarding can all surface as API risk. The governance problem grows when teams treat APIs as isolated technical assets instead of as part of the wider identity and access model across cloud and application stacks.

Practical implication: connect API governance to service identity, secrets, and entitlement reviews rather than managing it as a separate silo.

Threat narrative

Attacker objective: The attacker aims to reach sensitive business data or privileged application functions through the API layer while avoiding controls that were never fully mapped or enforced.

1. Entry occurs through externally reachable API endpoints that are undiscovered, undocumented, or poorly governed, giving attackers a large search surface to probe for weak authentication or exposed data paths.
2. Escalation follows when attackers abuse over-permissioned service access, weak token handling, or missing policy checks to move from one endpoint to another or to call privileged functions.
3. Impact comes from production API compromise, including unauthorised data access, service disruption, and delayed releases as organisations attempt to contain the exposure.

NHI Mgmt Group analysis

API posture governance is becoming a control requirement, not a maturity exercise. When only a minority of organisations can say their inventories are complete, the real failure is not that APIs exist, but that defenders cannot prove what is in scope. That uncertainty weakens authorisation, logging, and incident response at the same time. For security leaders, the practitioner conclusion is simple: without posture governance, API security remains reactive rather than enforceable.

Service identity blind spots sit underneath most API governance failures. APIs are frequently the runtime path for tokens, service accounts, and delegated access, which means weak API governance becomes weak identity governance by another name. The policy problem is not just endpoint exposure, it is that entitlement scope and credential ownership are often disconnected from the APIs that use them. Teams should treat API inventory as part of identity lifecycle control, not only application operations.

Production risk rises faster than documentation can catch up. The report’s pattern is familiar: growth, delayed remediation, and confidence gaps all move in the wrong direction at once. That creates a gap between release velocity and governance velocity, which attackers can exploit through the least reviewed endpoints. The practical conclusion is that security teams need continuous control validation, not periodic assurance.

API sprawl creates a new form of governance debt. As environments scale, undocumented endpoints and stale ownership become accumulated risk that behaves like technical debt but is harder to see. This matters because every unknown API is also an unknown access path, unknown data exposure point, and potential exception to policy. The practitioner implication is to prioritise visibility and ownership before expanding security tooling coverage further.

What this signals

API security programmes now need to be read as identity programmes in disguise, because tokens, service accounts, and delegated access are what actually move through the interface layer. Interface-to-identity drift: the gap between what an API exposes and what the underlying identity policy actually permits. Teams that do not close this gap will keep discovering that application controls are only as strong as the service identities behind them.

The broader signal is that posture governance is moving from documentation discipline to operational enforcement. That makes alignment with the NIST Cybersecurity Framework 2.0 and the NIST SP 800-53 Rev 5 Security and Privacy Controls more relevant, especially around access control, auditability, and configuration management. For practitioners, the watchpoint is whether APIs can be governed continuously rather than reviewed after exposure.

As cloud migration expands the API surface, the practical question is whether security, application, and identity teams share a single control model for runtime access. If they do not, inventories stay incomplete, ownership stays ambiguous, and response stays slow. The next maturity step is not more inventory reporting, but tighter linkage between discovery, entitlement, and runtime policy enforcement.

For practitioners

• Implement continuous API discovery Build automated discovery across cloud and application environments so new, shadow, and deprecated APIs are identified before they become unmanaged exposure points.
• Tie posture checks to deployment gates Add policy checks for authentication, authorisation, logging, and schema drift into CI/CD and release pipelines so production APIs cannot bypass review.
• Map service identities to API ownership Require every API to have a named owner, a linked service identity, and documented token or secret dependencies so entitlement reviews can be completed with evidence.

Key takeaways

• API growth in regulated sectors is creating a governance problem that security teams can no longer treat as a documentation issue.
• Incomplete inventories, weak posture strategy, and delayed production updates are the control gaps most likely to turn API expansion into breach exposure.
• Identity governance must extend into the API layer because service identities, tokens, and delegated access are now part of the attack surface.

Key terms

• API Posture Governance: API posture governance is the set of controls used to verify that APIs are configured, documented, authenticated, authorised, and monitored according to policy. It turns API security from ad hoc review into repeatable assurance across development and production environments.
• API Inventory: An API inventory is the authoritative record of what interfaces exist, who owns them, what data they touch, and how they are authenticated. For identity governance, it is the baseline control that makes review, monitoring, offboarding, and risk prioritisation possible across distributed services.
• Service Identity: A service identity is a non-human identity used by applications, workloads, or automation to authenticate and access resources. It may be a role, token, key, or certificate, and it needs the same lifecycle discipline as any privileged identity because it can directly expose data.
• Production API Drift: Production API drift is the gap between what security policy expects and what deployed APIs actually do over time. It emerges when configuration, permissions, documentation, or logging change faster than governance can validate them, creating hidden exposure in live environments.

What's in the full article

Salt's full report covers the operational detail this post intentionally leaves for the source:

• Sector-by-sector API growth patterns and how they differ across financial services and insurance.
• Production API breach and vulnerability breakdowns that support operational prioritisation.
• Practical posture governance benchmarks for discovery, documentation, and release gating.
• The report's own C-level priority data for teams building executive cases.

👉 Salt's full report covers the breach rates, inventory gaps, and governance data behind these findings.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programmes their organisations already run.