API inventory drift is the mismatch between recorded APIs and live execution, so the inventory becomes inaccurate even when some visibility remains. Unknown APIs are endpoints that teams do not see at all. Drift often comes first, then produces unknown APIs or unmanaged APIs as the gap between documentation and production behavior widens over time.
Why API Inventory Drift and Unknown APIs Are Not the Same Problem
API inventory drift is an accuracy problem: the catalogue exists, but it no longer matches what is actually running. Unknown APIs are a visibility problem: the organisation does not know the endpoint exists, so there is no reliable record to review, govern, or retire. The distinction matters because drift can usually be detected with reconciliation, while unknown APIs require discovery and control expansion before governance is even possible.
For security teams, this difference changes the first question they ask. With drift, the issue is whether documentation, routing, or ownership has fallen behind release behaviour. With unknown APIs, the issue is whether an unmanaged interface has bypassed the normal intake, auth, and logging paths. That gap can hide exposed functionality, weak authentication, or orphaned credentials. NHI Mgmt Group research shows only 5.7% of organisations have full visibility into their service accounts, which is a useful reminder that incomplete inventory is often the starting condition, not the exception.
In practice, teams usually discover drift first and unknown APIs only after traffic, incidents, or audit findings force a search that the inventory should already have supported.
How the Difference Shows Up in Discovery, Ownership, and Control
Drift and unknown APIs can look similar operationally because both create mismatches between expected and real attack surface, but they fail in different ways. Drift usually means the organisation once had awareness: an endpoint was recorded, approved, or owned, then changed without the record being updated. Unknown APIs usually mean the endpoint was never captured by the normal governance path, or it escaped into production through shadow deployments, forgotten test infrastructure, or third-party integrations.
That distinction affects how you respond. Drift is best handled by reconciliation between API gateways, service catalogues, code repositories, and runtime telemetry. Unknown APIs require broader discovery across network logs, asset scans, application tracing, and identity logs to surface endpoints that are not in the register at all. The control objective is different: drift asks whether the inventory is stale; unknown APIs ask whether the inventory is incomplete.
One practical rule is to treat drift as a leading indicator of governance decay. If teams stop maintaining ownership, schema, and authentication records, the chance of unmanaged endpoints rises. That is especially relevant where machine-to-machine traffic is common, because service credentials and bearer tokens can keep working long after the team that created them has lost sight of the endpoint they protect. The OWASP Non-Human Identity Top 10 is a useful companion reference for understanding how untracked machine access and credential sprawl can amplify this problem, and NHIMG’s guidance on non-human identities explains why lifecycle visibility is inseparable from control.
- Drift means the record is wrong, but the API is still partly known.
- Unknown means the API is outside normal awareness and may also be outside normal governance.
- Both can expose stale authentication, undocumented data flows, and orphaned ownership.
These controls tend to break down when teams manage APIs through separate delivery pipelines, because the live estate changes faster than the inventory can be reconciled.
Common Edge Cases Where the Boundary Blurs
Tighter classification often increases operational effort, requiring organisations to balance fast delivery against the overhead of continuous discovery. In real environments, the boundary between drift and unknown APIs is not always clean. A deprecated endpoint may remain callable in production, which makes it look unknown to one team and known to another. A shadow API may be visible in logs but absent from the authoritative catalogue, so it sits between drift and full unknown status until ownership is confirmed.
Best practice is evolving, but current guidance suggests treating any endpoint that lacks an owner, policy, or review trail as higher risk than a simple documentation error. That is because the real security question is not just whether the API exists, but whether anyone can explain who approved it, what data it handles, and how it is authenticated. If you cannot answer those questions quickly, the endpoint should be handled as unmanaged even if it appears in some tooling.
This is also where lifecycle issues matter. Drift often accumulates from normal change, while unknown APIs often persist because nothing in the process forces them into retirement. NHI Mgmt Group research on API key offboarding is relevant here: only 20% of organisations have formal processes for offboarding and revoking API keys, which is one reason endpoints and their credentials can remain live long after the owning team has moved on.
Practitioner takeaway: Use drift to measure inventory quality and unknown APIs to measure governance failure. If an endpoint cannot be tied to an owner, authentication model, and reviewable change history, treat it as unmanaged until proven otherwise.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Discovery | Covers keeping machine and API identities discoverable and accounted for. |
| NHI-03 — Secrets and Credential Management | Unknown or drifted APIs often persist through live credentials and tokens. | |
| Recommendation — Inventory all APIs and machine identities, then reconcile runtime exposure against the register. Rotate and revoke credentials tied to unmanaged or stale API endpoints. | ||
| CIS Controls v8 | 5.1 — Account Inventory and Control | Drift and unknown APIs both reflect gaps in maintaining authoritative asset inventories. |
| 6.3 — Access Rights Management | Unmanaged APIs frequently retain access paths that should be removed or reviewed. | |
| Recommendation — Maintain an authoritative inventory of API-exposed assets and remove unapproved entries. Review and remove access rights for APIs that lack clear ownership or business need. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical Devices and Systems Inventory | API drift is an inventory integrity problem that fits asset-management governance. |
| Recommendation — Reconcile discovered API services against the authoritative asset inventory on a fixed cadence. | ||
| MITRE ATT&CK | T1595.002 — Active Scanning: Vulnerability Scanning | Unknown APIs are often found through discovery and scanning of exposed services. |
| Recommendation — Use discovery and scanning telemetry to surface exposed APIs outside the approved catalogue. | ||
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between GraphQL and REST for enterprise API governance?
- What is the difference between API governance and API management?
- What is the difference between rate limiting and throttling in API governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
