Yes. A dormant integration often means the original user left, the use case ended, or the grant was never reassessed, yet the token or delegated access still works. That is the same lifecycle failure pattern seen in leaver handling for non-human identities, so revocation needs to be part of offboarding.
Why a dormant GenAI integration should be treated like leaver risk
A dormant integration is not a harmless leftover. If the original user has left, the use case has ended, or nobody has re-approved the grant, the token or delegated access can still operate exactly as before. That is the same lifecycle failure pattern as an unrevoked leaver account, so the control expectation should be offboarding, not passive retention.
What makes the risk lifecycle-related rather than just “unused”?
“Dormant” is often a governance label, not a security state. An integration can look inactive while still holding valid credentials, broad scopes, or a standing delegation that can reach production data, internal APIs, or administrative actions. The security question is whether the access path still exists and still matters, not whether the integration was recently used.
For that reason, the right comparison is to stale access, not to archived software. If the integration was created for a person, project, or vendor relationship that has changed, the access should be reviewed as part of the same lifecycle logic used for departures, role changes, and deprovisioning. That is why our Joiner-Mover-Leaver (JML) Guide treats token and agent revocation as part of the leaver process, not an optional cleanup task.
What should be checked before you leave a dormant integration in place?
First, confirm ownership. If nobody can name the business owner, the technical owner, and the approving use case, the integration already has an accountability problem. Second, confirm the credential type and its reach: long-lived token, delegated OAuth grant, API key, service credential, or other secret material. Third, verify whether the integration can still call privileged functions or access sensitive data even if nobody is actively watching it.
That ownership check matters because the lifecycle failure is usually invisible until the next audit or incident. In practice, the safest assumption is that dormant access is still exploitable until proven otherwise. Our NHI Lifecycle Management Guide and IAM and IGA Basics both frame inactivity, ownership, and recertification as lifecycle controls, not documentation exercises.
If the integration is tied to a departed user or an ended project, the default decision should be revoke, then recreate only if the use case still exists and the new owner can justify the grant. If the integration is still needed, move it onto an owned, named service identity with a bounded scope, review cadence, and expiration or rotation plan. Our SCIM and Automated Provisioning Guide is useful where that lifecycle needs to be enforced automatically rather than handled manually.
Risk and Threat Considerations
Dormant GenAI integrations create an attractive blind spot because they can survive staff changes, project closures, and security reviews. If the underlying token or delegated grant still works, an attacker who finds it may gain an access path that no longer has an active business owner, which makes detection and containment slower.
Failure mechanism: The grant outlives the use case, the owner leaves, and the access path remains valid because nobody revokes or rotates it during offboarding or recertification.
Impact: An attacker, or simply an unintended internal user, can reuse the dormant integration to reach data, trigger actions, or pivot through trusted automation with no obvious operational signal.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Dormant integrations often persist because tokens and secrets are not rotated or revoked. |
| AC-2 — Account Management | Dormant integrations are an account lifecycle problem when access remains valid after use ends. | |
| AC-6 — Least Privilege | Dormant integrations often retain more access than their current use case requires. | |
| Recommendation — Revoke or rotate stale integration authenticators on a defined lifecycle. Review and disable unused integration accounts and grants promptly. Reduce dormant integration permissions to the minimum required or remove them. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | A dormant integration is often a failure to offboard its original access path. |
| NHI-07 — Long-Lived Secrets | Dormant integrations frequently persist through credentials that remain valid too long. | |
| NHI-05 — Overprivileged NHI | Dormant integrations often keep excessive access long after the original need has changed. | |
| Recommendation — Offboard unused integrations when the owner or use case ends. Replace long-lived integration secrets with short-lived, reviewable credentials. Reassess dormant integration scopes and remove unnecessary privileges. | ||
Practitioner Guidance
What to prioritise: Treat every dormant integration as an access review item, not a cleanliness item. Start with integrations that have production scope, broad API permissions, or human-issued tokens, because those are the ones most likely to combine low visibility with high impact.
What to verify: Confirm who owns the integration, whether the original approver still exists, what the token can do, and whether the grant can be expired, rotated, or disabled without breaking an active service. If the answer to any of those is unclear, the integration is not ready to remain live.
Practitioner takeaway: Dormancy does not reduce entitlement risk; it usually increases it by removing active oversight while leaving the access path intact.