Shadow and zombie APIs expose the NHI governance gap

At a glance

What this is: This is an analysis of shadow and zombie APIs as hidden API security risks, with the core finding that unmanaged inventory and offboarding gaps create governance exposure.

Why it matters: It matters because IAM, NHI, and platform teams have to govern API access and secrets as lifecycle assets, not just discover them after exposure or incident response.

By the numbers:

• cyberattacks targeting APIs have surged by 137% in 2023 compared to the year before

Context

Shadow APIs and zombie APIs are hidden API assets that fall outside normal governance, but the real problem is not simply that they are hard to see. The security gap appears when access paths, authentication secrets, and ownership outlive the processes meant to inventory, review, and retire them.

For identity teams, this is an NHI governance issue as much as an API security issue. API keys, JWTs, and other authentication mechanisms can persist after the business need has changed, which turns discovery into only the first step of control rather than the control itself.

Key questions

Q: What breaks when shadow or zombie APIs are not in the approved inventory?

A: Governance breaks first because teams lose the ability to assign ownership, review access, and retire credentials on schedule. The endpoint may still function, but it is operating outside the controls that should constrain authentication, data exposure, and offboarding. That is how hidden APIs turn into unmanaged trust paths.

Q: Why do forgotten APIs create more risk than a simple visibility gap?

A: Because visibility is only useful if it leads to revocation. A forgotten API can still accept valid keys, tokens, or other secrets, which means attackers may gain access through a path that no longer has an active business owner. The security problem is persistent trust, not just poor inventory.

Q: How can security teams tell whether an API is truly retired?

A: A retired API should fail closed, with credentials revoked, authorization removed, and monitoring showing no legitimate traffic. If an endpoint still authenticates or reaches sensitive data after deprecation, it is not retired in a security sense, even if the development team has stopped using it.

Q: When should organisations treat API keys and tokens as NHI assets?

A: They should do so whenever those credentials can authenticate software, services, or external integrations without human interaction. At that point, the credential has a lifecycle, an owner, and a blast radius that must be governed like any other non-human identity.

Technical breakdown

Why shadow APIs evade governance controls

Shadow APIs are typically created outside the formal approval path, often when development teams integrate external services or expose interfaces without central oversight. The technical problem is not just undocumented infrastructure. It is that these endpoints may inherit application credentials, data access paths, or network reach without passing through the usual review for authentication, authorization, logging, or decommissioning. That makes them difficult to assess with standard control assumptions because they may never appear in the authoritative asset inventory. In practice, the hidden API becomes a bypass around lifecycle governance, not just a missed object in a scan.

Practical implication: tie API discovery to access ownership, not only to surface scanning.

How zombie APIs become backdoors

Zombie APIs are different because they were once approved, then abandoned or deprecated while remaining reachable. Their risk compounds over time because stale endpoints often miss patching, security updates, and access review. If an old API still accepts valid credentials or exposes sensitive objects, it can function like a standing backdoor even when no one believes it is in use. This is where offboarding discipline matters: retired functionality should not retain authentication trust, and old authorization paths should not persist simply because the endpoint still responds.

Practical implication: align API retirement with credential revocation and authorization removal.

Why secrets and tokens make hidden APIs harder to kill

The article’s strongest technical point is that hidden APIs are sustained by credentials, not just code. If API access is managed through secrets or JWTs, then the lifecycle of those secrets determines whether the endpoint remains exploitable after it is forgotten. That means rotation, revocation, and usage monitoring are not separate hygiene tasks. They are the mechanism that determines whether an API can still authenticate after it should have been dead. Without that lifecycle view, discovery tells you where the API exists, but not whether it can still be abused.

Practical implication: treat API secrets as revocable identity objects with their own lifecycle.

Threat narrative

Attacker objective: The attacker aims to use an unmanaged API path to reach sensitive data or internal systems without passing through normal governance controls.

1. Entry occurs through an unmanaged or abandoned API that still accepts authentication or remains exposed to external callers.
2. Credential access follows when API secrets, JWTs, or inherited authentication paths continue to work after the API has fallen out of oversight.
3. Escalation happens when the hidden endpoint still reaches sensitive data or internal systems that were never revalidated after deployment or deprecation.
4. Impact is unauthorized access, data exposure, or a breach that only becomes visible after the API has already been exploited.

Breaches seen in the wild

• T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.
• McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow and zombie APIs are an identity governance failure, not just a discovery problem. Discovery tells teams what exists, but governance determines whether the endpoint still deserves trust. If an API can still authenticate, the real issue is that ownership, offboarding, and access review have not kept pace with the architecture. The practitioner conclusion is simple: unmanaged interfaces must be governed as identity-bearing assets, not just technical leftovers.

API access secrets create a lifecycle boundary that many programmes still miss. The article repeatedly points to secrets and JWTs as the mechanism that keeps hidden APIs alive. That makes secrets management a lifecycle discipline for machine access, not a vault-only hygiene exercise. The practitioner conclusion is that revocation, rotation, and usage telemetry must be tied to endpoint retirement, or dormant access will remain usable.

Identity blast radius is the right concept for hidden APIs. A shadow API may be unknown, but a zombie API is often known and still dangerous because its permissions have not been withdrawn. That means the security question is not just whether the endpoint is visible, but how far it can reach if its credentials are abused. The practitioner conclusion is to measure the blast radius of every API credential as part of governance.

Lifecycle offboarding must extend to machine interfaces that no one owns anymore. Zombie APIs persist because approved assets are easier to forget than to remove. Once the business context changes, the endpoint can still remain technically functional while accountability disappears. The practitioner conclusion is that API decommissioning needs the same operational discipline as human offboarding and service account retirement.

NHI governance and API security converge at the same control point: trust in authentication material. Whether the credential is an API key or a JWT, the risk is identical when the material outlives the access need. That makes this topic directly relevant to OWASP-NHI, NIST-CSF, and zero-trust access governance. The practitioner conclusion is to govern API identity as part of the broader non-human identity estate.

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.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
• Read next: API Key Management Guide

What this signals

Identity blast radius for APIs: the practical unit of governance is not the endpoint alone, but the combination of endpoint, credential, and reachable data. When any one of those is left outside lifecycle control, hidden APIs become durable trust paths that evade standard IAM workflows.

API security and NHI governance now overlap in the same operational question: who can still authenticate after the business thinks the interface is gone. That is why decommissioning, revocation, and inventory have to move together instead of being managed as separate functions.

The scale of the problem is no longer hypothetical, with cyberattacks targeting APIs up 137% in 2023 compared to the year before according to the 2024 State of Secrets Management Survey. Teams should assume that any unowned API with live secrets is already part of the attack surface.

For practitioners

• Map all externally reachable APIs to an owner and lifecycle state Require every API to have a named owner, a deprecation state, and a retirement date so shadow and zombie endpoints do not fall outside governance.
• Bind API secrets to endpoint retirement When an API is deprecated, revoke its keys, tokens, and JWT signing trust at the same time, rather than leaving credentials active after the interface is abandoned.
• Inventory APIs with continuous monitoring and anomaly detection Use continuous monitoring to flag endpoints that are not in the approved inventory or that show unexpected usage patterns after deprecation.
• Reduce privileges on every active API Apply least privilege so each API only reaches the data and services it actually needs, limiting blast radius if a credential is abused.
• Audit forgotten interfaces before they become backdoors Include retired, abandoned, and vendor-integrated APIs in periodic reviews, because old trust paths often remain reachable long after teams assume they are gone.

Key takeaways

• Shadow and zombie APIs persist because lifecycle control, not just discovery, is missing from many identity and API security programmes.
• API-targeting attacks rose by 137% in 2023, showing that hidden interfaces are not a theoretical risk.
• The control that matters most is revocation and offboarding of API credentials when an endpoint is retired.

Key terms

• 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.
• Zombie API: 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.
• API Credential Lifecycle: The API credential lifecycle is the full journey of a secret used to authenticate software to an API, from creation to retirement. It covers issuance, storage, rotation, use, monitoring, revocation, and deletion. Strong lifecycle control reduces exposure from leakage, stale access, and unauthorized reuse across systems and environments.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.