A zombie API is a deprecated or abandoned interface that remains accessible after the organisation believes it should be retired. It is risky because old permissions, secrets, or backend trust can survive the business purpose, turning legacy access into an active exposure.
Expanded Definition
A zombie API is not simply an old endpoint. It is an interface that remains reachable after the business team has treated it as retired, often with dormant routing, stale trust relationships, or preserved credentials still able to invoke it. In NHI governance, that makes it a lifecycle failure, not just technical debt.
Definitions vary across vendors on whether a zombie API must be undocumented, unmaintained, or merely deprecated, but the security concern is consistent: access survives longer than intent. That is why practitioners should treat it as part of the broader NHI lifecycle alongside offboarding, secret rotation, and entitlement cleanup, as reflected in the NIST Cybersecurity Framework 2.0 and NHIMG guidance in the Ultimate Guide to NHIs.
The key distinction is between a harmless deprecated interface and one that still has valid backend trust, api key, service account permissions, or partner integrations. Zombie APIs often sit outside normal change management because teams assume retirement automatically means inaccessibility. The most common misapplication is assuming an endpoint is safe once developers stop using it, which occurs when decommissioning does not include verification of routing, authentication, and downstream authorization.
Examples and Use Cases
Implementing zombie API retirement rigorously often introduces operational overhead, requiring organisations to weigh faster product change against the cost of discovery, validation, and access revocation.
- A legacy payments endpoint remains live for one partner after the official migration, and its API key still authorizes transactions because no offboarding process was completed.
- An internal mobile backend is replaced, but DNS, load balancer rules, and service account permissions continue to expose the old route to authenticated callers.
- A deprecated admin API is removed from documentation yet remains callable from a CI/CD pipeline because the pipeline secret was never rotated.
- A third-party integration continues to access an archived customer data service after contract end, revealing why NHIs outlive application ownership when revocation is not enforced, as discussed in the Ultimate Guide to NHIs.
- An api gateway blocks traffic at the front door, but a direct backend route remains open, showing the difference between visible deprecation and actual asset retirement.
For lifecycle and exposure management, the same review should be mapped against NIST Cybersecurity Framework 2.0 so decommissioning includes discovery, access validation, and revocation.
Why It Matters in NHI Security
Zombie APIs are dangerous because they preserve the exact conditions attackers look for: forgotten trust, long-lived secrets, and low monitoring coverage. NHIMG research shows that 79% of organisations have experienced secrets leaks, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. A zombie API can turn both of those realities into an active breach path.
When an endpoint is believed to be retired, teams often stop logging, alert tuning, and access review. That creates a blind spot where attackers can probe old routes, reuse leaked tokens, or exploit partner credentials that were never revoked. The NHI problem is not only whether the API exists, but whether the identity and authorization model behind it has truly been dismantled. In practice, this means retired interfaces must be treated as security assets until they are proven dead, not merely undocumented.
Organisations typically encounter the consequence only after a breach review, when an incident reveals that a “dead” API was still processing requests, at which point zombie API cleanup becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Zombie APIs expose forgotten NHI attack paths and stale access. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege and access review principles apply to dormant API access. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous validation, even for legacy interfaces. |
Treat every old API as untrusted until its authentication and authorization are explicitly removed.
