What is the difference between an unmanaged API and a shadow API?

An unmanaged API is known to the organisation but no longer consistently governed, secured, or monitored. A shadow API is unknown or undiscovered by central teams. The distinction matters because unmanaged APIs are mainly a control failure, while shadow APIs are mainly a discovery failure. Both increase risk, but remediation starts in different places.

Why the Distinction Matters for API Security

The difference is operational, not semantic. An unmanaged API usually exists on the organisation’s radar, but its ownership, policy enforcement, logging, testing, or retirement has drifted. A shadow api sits outside central awareness altogether, which means basic inventory, governance, and monitoring are missing before security controls even begin. That distinction changes where teams start, how they measure exposure, and which failure mode is most likely to persist.

For security teams, unmanaged APIs tend to signal control decay across the API lifecycle: stale documentation, broken ownership, inconsistent authentication, or exceptions that were never closed. Shadow APIs point first to discovery gaps, such as incomplete asset inventory, untracked integrations, or environment sprawl. Both can expose data or expand attack paths, but unmanaged APIs often fail because teams assume governance is still in place, while shadow APIs fail because no one knows they exist.

At scale, the practical difference is that unmanaged APIs can often be brought back under policy once they are identified, while shadow APIs require discovery work before any meaningful remediation can happen. In practice, many teams discover both conditions only after a third party, test environment, or old deployment path has already created an unexpected exposure.

How It Works in Practice

Unmanaged APIs usually emerge when an API was once approved, documented, and secured, but the operating reality changed. Ownership may have shifted, the business may still depend on it, or the endpoint may have outlived its original controls. The result is a known interface with unknown current hygiene. Shadow APIs, by contrast, are typically created through modern delivery patterns: rapid releases, duplicated services, parallel environments, legacy endpoints, partner integrations, or code paths that bypass central registration. The security problem is not only whether the API is authenticated, but whether the organisation can reliably answer that it exists, who owns it, and what data it can reach.

For practitioners, the first useful test is whether the API appears in inventory and governance records. If it does, treat it as a control and lifecycle problem. If it does not, treat it as a discovery and asset-management problem. That distinction determines the sequence of work:

known API, weak controls: restore ownership, validate authentication and authorisation, and confirm logging and review are active
unknown API, unclear scope: discover the endpoint, map traffic and dependencies, and then apply the same control set
both known and exposed externally: assume the blast radius may already include sensitive data or privileged functions

This is where lifecycle management matters. An API can become unmanaged when decommissioning is incomplete, when a gateway policy is removed without removing the backend, or when a team copies an endpoint into another environment and never re-registers it. Shadow APIs often stay hidden because discovery is fragmented across cloud, CI/CD, container, and partner environments. The most reliable response combines inventory, traffic analysis, owner assignment, and retirement control rather than relying on documentation alone. NHIMG’s lifecycle guidance on Lifecycle Processes for Managing NHIs is useful here because the same lifecycle discipline applies to API-facing non-human access.

For broader governance context, the NIST Cybersecurity Framework 2.0 remains relevant because it separates asset visibility, protection, detection, and recovery into a structure teams can operationalise. A useful NHIMG reference is Ultimate Guide to NHIs — Key Challenges and Risks, which helps frame why incomplete ownership and weak visibility persist even when tooling exists. These controls tend to break down when APIs are duplicated across teams and environments because inventory and policy enforcement no longer share the same source of truth.

Common Variations and Edge Cases

Tighter API governance often increases delivery friction, requiring organisations to balance speed against control maturity. The hard edge case is a service that is intentionally private, temporary, or partner-only: it may be known to one team but absent from central catalogues, which makes it look shadow-like even when local owners exist. Current guidance suggests classifying those cases by visibility and control state, not by whether they were accidentally created.

Another common wrinkle is that an API can move between categories. A newly launched endpoint may begin as a shadow API, then become unmanaged once someone discovers it but never assigns ownership or policy. Likewise, a retired API may remain partially live behind a forgotten route, which is neither fully managed nor fully shadowed but still dangerous because assumptions about its status are wrong.

The practical tradeoff is that discovery-only programmes find more unknown endpoints, but they do not by themselves reduce risk unless the organisation can quickly assign ownership and enforce controls. The most important question is not which label is more severe, but whether the team can prove the API is inventoried, owned, monitored, and retired on purpose rather than by accident.

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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Unmanaged and shadow APIs often expose or rely on unmanaged machine credentials.
	NHI-02 — Inventory and Visibility	Shadow APIs are fundamentally a visibility and discovery failure for non-human access paths.
	NHI-03 — Ownership and Lifecycle	Unmanaged APIs reflect broken ownership, lifecycle, and offboarding discipline.
Recommendation — Inventory API credentials and rotate any secret tied to an unknown or uncontrolled endpoint. Build continuous discovery to find API endpoints that never entered central inventory. Assign named owners and retire APIs through a tracked lifecycle process.
NIST CSF 2.0	GV.AM-01 — Asset Inventory	API management depends on knowing what assets and interfaces exist.
	PR.AA-01 — Identity Management, Authentication and Access Control	Known APIs become risky when access control and identity checks drift out of policy.
	DE.CM-01 — Monitoring for Anomalous Activity	Both unmanaged and shadow APIs are easier to exploit when traffic is not monitored.
Recommendation — Maintain a current inventory of live APIs and reconcile it against deployed services. Enforce authentication and access rules consistently across all approved API endpoints. Monitor API traffic for unknown routes, unexpected clients, and unusual request patterns.
CIS Controls v8	01 — Inventory and Control of Enterprise Assets	Shadow APIs are undiscovered assets that should be brought into enterprise inventory.
	06 — Access Control Management	Unmanaged APIs often persist because access paths remain open after ownership weakens.
Recommendation — Discover and catalog all API endpoints before they are treated as trusted assets. Remove stale access paths and enforce least privilege on every active API route.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	Exposed APIs are common entry points when controls are weak or missing.
Recommendation — Hunt for exposed API endpoints that can be abused as public-facing application attack surface.

Practitioner Guidance

What to prioritise: Start by separating inventory gaps from governance gaps. If the API is absent from central records, prioritise discovery and traffic correlation; if it is present but weakly controlled, prioritise owner confirmation, authZ review, and telemetry validation.

Decision rule: If an API can reach production data or privileged functions, treat it as a high-risk exposure even before you confirm whether it is shadow or unmanaged. The category tells you where to begin, not whether the endpoint matters.

What good looks like: Every live API has an owner, a source of record, a monitored path, and a defined retirement state. Shadow endpoints are detected through routine discovery, and unmanaged endpoints are either brought back under policy or removed.

Practitioner takeaway: The real control objective is not perfect naming; it is proving that no API can remain both reachable and unaccountable for long.