Who is accountable when a protected API is exposed outside WAF coverage?

Why This Matters for Security Teams

A protected API that sits outside WAF coverage is not just “missing a control”; it is a boundary failure that breaks the assumption that internet traffic is uniformly inspected before reaching a service. Accountability usually lands with the service owner for exposing the endpoint and the security team for control coverage, but the real issue is shared governance: asset inventory, exception handling, and enforcement drift. NHI Management Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now highlights that 80% of identity breaches involved compromised non-human identities such as service accounts and api key, which makes unmanaged API exposure especially dangerous.

Security teams often treat WAF placement as a network diagram issue, but exposure outside coverage is also a control ownership problem. If the endpoint is live, reachable, and not covered, then the organisation has already accepted a risk without the same rigor it would apply to privileged credentials or production secrets. That gap becomes more serious when the API is tied to automation, partner integrations, or service accounts that can be abused at machine speed. The control failure is visible only after the endpoint is probed, not when it is introduced.

Practitioners should compare this with patterns seen in The 52 NHI breaches Report and the broader evidence in Ultimate Guide to NHIs: exposure is usually discovered late, after a secret leak, misrouted endpoint, or unsanctioned integration has already expanded the attack surface. In practice, many security teams encounter unprotected internet-facing APIs only after abuse telemetry or an external scan has already found them.

How It Works in Practice

Accountability should be mapped to the service owner because they control the endpoint, its deployment path, and the decision to place it behind the WAF. The security team is accountable for policy design, coverage monitoring, and exceptions that do not silently expire into permanent gaps. Current guidance from NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls supports this split: asset ownership, access control, and monitoring are shared governance duties, not one team’s isolated task.

In operational terms, the organisation needs three things working together:

• A complete inventory of all internet-facing APIs, including shadow, deprecated, and partner-exposed endpoints.
• A coverage map showing which endpoints are protected by the WAF, which are intentionally exempt, and which are missing coverage by mistake.
• A remediation workflow that assigns a named owner, a due date, and a fallback control for anything outside coverage.

That workflow should include change-management hooks so a new endpoint cannot go live without an explicit decision on WAF placement or compensating controls. For APIs that are hard to place behind a WAF, teams often add rate limiting, mutual TLS, strict authentication, schema validation, and per-route policy checks. Those controls are not equivalent to a WAF, but they reduce exposure when architectural constraints exist. The key is to document whether the gap is temporary, accepted, or under active remediation, and to keep that status visible in the same system that tracks production risk.

This becomes especially important when APIs are backed by service accounts, machine tokens, or other NHIs, because the endpoint and the identity risk compound each other. The 52 NHI Breaches Analysis shows how quickly identity misuse can turn exposure into compromise, especially when visibility is incomplete or ownership is unclear. These controls tend to break down when cloud teams, application teams, and security operations each believe the other group owns endpoint protection.

Common Variations and Edge Cases

Tighter WAF enforcement often increases deployment friction, requiring organisations to balance developer speed against consistent inspection and governance. That tradeoff is real, especially for APIs used by partners, mobile apps, or internal automation where false positives can disrupt business workflows. Best practice is evolving, and there is no universal standard for this yet, but current guidance suggests documenting the exception rather than normalising the absence of coverage.

Some endpoints may sit outside a traditional WAF because they are server-to-server, use non-HTTP protocols, or are protected by a gateway elsewhere in the path. In those cases, accountability does not disappear. The owner still needs to prove what control exists at the edge, what compensating control is in place, and who accepted the residual risk. The same is true for temporary cutovers, regional failovers, and migration windows, where teams sometimes forget to restore coverage after the change.

For organisations with heavy NHI usage, the practical question is not only whether the API is exposed, but whether the credentials behind it are also over-permissioned or long-lived. NHI Management Group’s research shows that 97% of NHIs carry excessive privileges, which means an exposed endpoint may have far more blast radius than the service team expects. In practice, the hardest cases are not the obvious public APIs; they are the forgotten endpoints, one-off integrations, and “temporary” exceptions that became permanent because no one owned the closure.

Related resources from NHI Mgmt Group

• Who is accountable when API-layer attacks on AI agent workflows bypass legacy WAF coverage?
• What is the difference between role-based access and API key governance for NHI security?
• How should security teams govern API keys used for generative AI access?
• When does a short-lived API key still create material risk?