An integration has become unmanaged when no one can name the owner, business purpose, expiry date, or revocation process. If a credential can still authenticate after the project has ended, it is an identity that outlived governance. Watch for dormant tokens, orphaned test secrets, and excessive API permissions.
Why This Matters for Security Teams
An integration stops being “just a tool connection” once it can still authenticate without an active owner, business purpose, or retirement path. At that point, it is an unmanaged identity with real access, not a harmless leftover. That matters because orphaned service accounts, API keys, OAuth apps, and test secrets often sit outside normal joiner-mover-leaver workflows and evade review until they are abused.
Security teams should treat this as an identity governance problem, not only a secrets problem. The issue is visible in the broader NHI landscape: the Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, while 71% of NHIs are not rotated within recommended time frames. Current guidance from NIST Cybersecurity Framework 2.0 reinforces that identity governance must include ongoing asset and access management, not one-time provisioning.
In practice, many security teams encounter unmanaged integrations only after a dormant token is used for unauthorised access or a forgotten app survives long after the project it supported has ended.
How It Works in Practice
The practical test is simple: can the organisation explain what the integration does, who owns it, when it should expire, and how it is revoked? If any of those answers are missing, the integration is drifting into unmanaged identity territory. Mature teams track these integrations the same way they track human identities, with lifecycle ownership, approval records, periodic access review, and revocation evidence.
In operational terms, the strongest signal is a credential that still works after the business process that created it is gone. That includes stale CI/CD secrets, abandoned OAuth grants, hard-coded API keys, and service accounts with no application owner. The NHI Lifecycle Management Guide is useful here because lifecycle control is what separates governed identity from leftover access. For implementation, the model should align to discovery, classification, ownership assignment, rotation, and offboarding. The Top 10 NHI Issues also highlights why over-privilege and missing rotation are recurring failure modes.
- Tag the integration to a named business owner and technical owner.
- Record purpose, system dependency, and planned end date.
- Check whether the credential is rotated, vaulted, or long-lived.
- Review permission scope against current usage, not original intent.
- Confirm revocation works in practice, not just on paper.
Where the signal becomes actionable is monitoring: if the integration has no recent legitimate use but still authenticates, or if a secret appears outside approved storage, it should be treated as unmanaged until proven otherwise. These controls tend to break down in fast-moving DevOps environments because credentials are copied into pipelines and code repositories faster than ownership and expiry metadata are updated.
Common Variations and Edge Cases
Tighter identity control often increases operational overhead, requiring organisations to balance faster delivery against stronger governance. That tradeoff is especially visible for machine-to-machine integrations, vendor OAuth apps, and short-lived test environments, where teams may argue that formal ownership is too slow for the pace of change.
Best practice is evolving, but current guidance suggests classifying integrations by risk rather than treating all of them the same. A production payment integration with broad permissions deserves stronger review than a temporary sandbox token, even if both are technically “non-human identities.” The challenge is that temporary often becomes permanent when nobody is assigned to clean up the integration later.
Two edge cases deserve special attention. First, shared credentials across multiple systems make ownership ambiguous, which is usually a sign that the integration is already unmanaged. Second, third-party OAuth grants can look legitimate while hiding broad downstream access; the Regulatory and Audit Perspectives section of the Ultimate Guide to NHIs is a useful reference when audit evidence is needed. In regulated environments, unmanaged integrations are often discovered during access recertification or incident response, not during routine asset management.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses stale, unrotated non-human credentials that keep integrations alive. |
| NIST CSF 2.0 | PR.AC-1 | Covers identity and credential management for systems and services. |
| NIST AI RMF | GOVERN | Supports accountability and oversight for autonomous or tool-using integrations. |
Map each integration to an owner and enforce access lifecycle controls from provisioning through revocation.
