API security is becoming a cyber insurance governance issue

At a glance

What this is: Salt argues that cyber insurance underwriting is starting to treat API security as a governance and evidence problem, not just a technical control problem.

Why it matters: IAM, API, and security teams now need defensible proof of API inventory, authorisation, and runtime monitoring because insurers are assessing the full attack surface behind coverage decisions.

Context

Cyber insurance is increasingly being shaped by evidence of control maturity, not just the presence of standard security tools. APIs matter because they expose business logic, move sensitive data, and often sit outside the visibility of traditional perimeter controls, which makes them difficult to assure in underwriting questionnaires.

For identity and access programmes, the key issue is that API security now intersects with authorisation, authentication, and monitoring evidence. If an organisation cannot show who or what can access an API, how access is validated, and how abuse is detected, the insurer will infer that the exposure is larger than the control story suggests.

Key questions

Q: What breaks when API discovery is incomplete in a cyber insurance review?

A: Incomplete discovery means the organisation cannot credibly show which APIs exist, who owns them, or whether they are tested and monitored. That weakens underwriting evidence because shadow and zombie APIs can hide unassessed exposure, making coverage decisions and premium calculations more conservative. The practical failure is not only technical blind spots but governance blind spots that insurers now treat as material risk.

Q: Why do weak API authorization controls increase insurance risk?

A: Weak authorization lets authenticated traffic reach objects or functions it should not touch, which can turn a normal-looking request into data loss or business disruption. Insurers care because loss severity rises when the organisation cannot prove that access is constrained at the object level. Authentication alone does not close that gap, so the control story remains incomplete.

Q: How do security teams know whether API edge protection is actually working?

A: Teams should look for lower rates of malicious requests reaching core services, faster detection of automated attack patterns, and fewer successful abuse cases such as credential sharing, account takeover, and inventory hoarding. Effective protection should also show consistent policy enforcement across device types and clear visibility into traffic patterns at the network edge.

Q: Who is accountable for API security evidence in a cyber insurance application?

A: Accountability usually sits across application owners, identity teams, and security governance, because API risk spans discovery, authorization, and monitoring. The key is to assign ownership for the API inventory, the access model, and the evidence package separately. If no one can attest to those three areas, the insurer will likely treat the control environment as immature.

Technical breakdown

Why API discovery now matters to underwriting evidence

API discovery is the process of finding and classifying every interface that can be called by users, services, partners, or attackers. In practice, the risk is not only exposed public endpoints but shadow and zombie APIs that remain live without current ownership, testing, or monitoring. Underwriters care because undiscovered APIs make the control set unverifiable. If the inventory is incomplete, statements about testing coverage, logging coverage, or authorisation coverage are incomplete too. That changes the insurance conversation from control existence to control evidence.

Practical implication: maintain a complete API inventory with ownership, exposure status, and business criticality before you treat your coverage position as defensible.

How BOLA and weak authorisation create a governance failure

Broken Object Level Authorization, or BOLA, occurs when an API accepts a request from an authenticated caller but fails to verify that the caller is allowed to access the specific object or record requested. That is a direct governance failure because authentication alone does not prove entitlement. Weak authentication, improper authorization, and missing rate limits can combine to let legitimate-looking traffic exfiltrate data at scale. For insurers, this is especially concerning because the loss event may look like normal API activity until the damage is already done.

Practical implication: test object-level access decisions explicitly, not just login flows, and document the controls that prove API calls are authorised at the data-object level.

Why runtime API monitoring has to go beyond gateways

API gateways and perimeter filters can block obvious misuse, but they often miss subtle abuse patterns that look valid at the request level. Runtime protection for APIs has to understand sequences, call context, and deviations from normal behaviour, because attackers frequently chain legitimate calls to reach data they should not see. This is where API security becomes closer to an identity and trust problem than a pure network problem: the control must verify that the actor, the token, the object, and the action still align at runtime.

Practical implication: add behavioural monitoring for API call chains and alert on unusual object access, sequence abuse, and credential-driven anomalies.

Threat narrative

Attacker objective: The attacker seeks to use legitimate-looking API access paths to extract data or disrupt business processes while evading the controls an insurer expects to see.

1. Entry begins when attackers reach exposed, shadow, or poorly governed API endpoints that the organisation has not fully inventoried or protected.
2. Credential or authorisation abuse follows when the API accepts authenticated requests but fails to enforce object-level entitlement checks, letting the caller access more data than intended.
3. Impact occurs through data theft, business disruption, or regulatory exposure that can translate into higher premiums, exclusions, or denial of coverage.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

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 has become an assurance problem, not just an engineering problem. The insurer is no longer only asking whether an API gateway exists, but whether the organisation can prove discovery, testing, and runtime control across the real attack surface. That shifts API security into the same governance class as IAM evidence, because the question is now what can be demonstrated, not what can be claimed. Practitioners should treat coverage conversations as a forcing function for control visibility.

Shadow and zombie APIs create control gaps that underwriting cannot ignore. An undiscovered endpoint is not just a technical oversight, it is an evidence failure because no one can attest to its owner, data path, or access model. This is where API governance overlaps with identity governance: if service accounts, tokens, or delegated access reach interfaces no one tracks, the organisation cannot credibly bound risk. Practitioners should align API inventory management with access governance and ownership reviews.

BOLA is the clearest example of why authentication evidence is not enough. An authenticated caller can still be unauthorized for a specific object, and that distinction matters when insurers look at loss scenarios. The specific named concept here is control evidence drift: teams prove they can authenticate traffic, but cannot prove they can stop overreach at the object layer. Practitioners should build evidence around object-level authorization and not stop at login assurance.

Runtime API protection is increasingly part of resilience economics. If an attack can blend into normal request patterns, then detection has to move beyond perimeter filtering and into behavioural context. That does not make gateways obsolete, but it does mean that insurers will increasingly expect runtime telemetry and response capability for API abuse. Practitioners should treat behavioural monitoring as a governance control with financial consequences, not just a SOC feature.

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

Cyber insurance is pushing API security out of the engineering silo and into governance evidence. Teams that can prove discovery, testing, and runtime visibility will be better placed to answer underwriting questions than teams that can only describe controls in theory.

Control evidence drift: this is the gap between authenticating API traffic and proving object-level entitlement, and it is exactly where BOLA, shadow APIs, and weak monitoring create underwriting exposure. The practical response is to align API inventory, identity governance, and runtime telemetry around the same ownership model.

For practitioners

• Inventory every exposed API and owner Create and maintain a complete inventory of internal, external, third-party, shadow, and zombie APIs, with business owner, data sensitivity, and authentication method recorded.
• Test object-level authorisation directly Use negative tests to confirm that authenticated users, service accounts, and partner integrations cannot retrieve records outside their permitted scope.
• Extend monitoring beyond the gateway Collect request sequences, object-access patterns, and unusual token behaviour so that runtime controls can detect abuse that looks valid at the endpoint.
• Package API control evidence for underwriting Document discovery coverage, test results, remediation status, and runtime detection controls so you can answer insurer questionnaires with verifiable evidence.

Key takeaways

• API security is moving into the underwriting conversation because insurers want proof of discovery, testing, and runtime control, not just a list of tools.
• Shadow APIs, BOLA, weak authorization, and shallow monitoring create a governance gap that can affect premiums, exclusions, and coverage decisions.
• The strongest defence is a verifiable control story that links API inventory, object-level access checks, and behavioural runtime detection.

Key terms

• API Discovery: API discovery is the process of finding and cataloging APIs across an environment so security teams know what exists, what data it exposes, and how it behaves. It is essential because shadow, zombie, unmanaged, and third party APIs are frequent blind spots that attackers can exploit without being noticed.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Runtime API Protection: Runtime API protection is the practice of securing application programming interfaces while they are actively handling live traffic. It combines authentication, authorization, schema validation, rate controls, anomaly detection, and abuse prevention to reduce misuse, data exposure, and unauthorized actions across internal, external, and machine-to-machine API interactions.

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 security and identity practitioners turn governance concepts into operational control.