Should organisations remove unused cloud access or quarantine it first?

Why quarantine is usually the safer default

Quarantine is the safer first move when you cannot confidently prove that an access path is obsolete. Deletion can be irreversible, especially for cloud roles, service principals, API keys, and other credentials that may still support a low-frequency workload, break-glass process, or scheduled automation. Quarantine preserves the identity object while removing usable privilege.

That matters because “unused” in cloud environments is often a visibility problem, not a true absence of dependency. A role may appear dormant simply because it is only exercised during failover, month-end processing, or a rarely run integration. Quarantine lets you reduce exposure immediately without destroying evidence or forcing a guess about business impact.

For workload and cloud identities, a preserved but disabled path is also easier to govern. Teams can review ownership, last-use signals, attached permissions, trust relationships, and downstream dependencies before making a final lifecycle decision. That is materially different from trying to reconstruct intent after deletion.

When removal is appropriate instead of quarantine

Deletion is appropriate when the identity is confirmed dead, the owner is known, and the dependency analysis is complete. If the account, key, or role is tied to a retired system, replaced integration, or formally decommissioned workload, removal reduces long-term clutter and closes recovery questions.

The practical test is whether the object still represents an active security or operational relationship. If it does, quarantine first. If it is only historical baggage with no remaining business function, removal is cleaner. Cloud workload identity guidance is useful here because cloud roles, managed identities, and temporary credentials often look idle while still being legitimate parts of a live system.

Quarantine also works best when you pair it with a time-bound review. An identity should not remain in limbo indefinitely. If no owner, dependency, or exception claim emerges after investigation, the safer interim control should convert into permanent cleanup.

How to quarantine without creating hidden risk

Good quarantine strips effective access, not just logon convenience. That usually means disabling privilege, revoking active sessions or tokens where possible, removing broad trust paths, and marking the object as under review so it is not accidentally reused. A quarantined identity should be observable and recoverable, but not operational.

Because cloud permission sprawl is often the real problem, quarantine should include a rights review, not only a login lockout. Cloud PAM and CIEM guidance helps frame the difference between mere account inactivity and excessive effective privilege, which is the condition that usually creates blast-radius risk.

Operationally, quarantine is strongest when the workflow records who approved it, what was removed, what might be restored, and by when the final disposition must be decided. If restoration is ever needed, the team should be able to re-enable access through an approval path rather than recreating the identity from scratch.

Risk and Threat Considerations

Unused cloud access is attractive because it is easy to overlook and often carries standing trust. An attacker who finds a dormant role, forgotten service principal, or stale key may get a low-noise foothold that bypasses normal user monitoring and weakens containment if the object still has permissions or inheritance paths.

Failure mechanism: Deletion can break a legitimate but poorly documented workload, while leaving an unused identity active can preserve a quiet attack path. Quarantine reduces that exposure by removing access first, then forcing a review of whether the identity truly has no remaining operational purpose.

Impact: The main impact is blast-radius reduction without losing reversibility. If teams delete first, they may interrupt production or lose forensic context; if they leave access untouched, they preserve an unnecessary entry point for abuse. MITRE ATT&CK Enterprise is a useful lens for the compromise path here, especially credential access, privilege escalation, and lateral movement from neglected accounts.

Practitioner Guidance

What to verify: Before deleting any cloud access object, verify owner, last meaningful use, downstream dependencies, and whether the identity has any emergency or scheduled function. If you cannot verify those points quickly, quarantine is the better control.

Decision rule: If the identity can still reach production or can still be mapped to a live integration, disable and quarantine first; if it is formally retired and the dependency record is complete, remove it. For secrets and tokens, CIS Controls v8 supports the broader account-management and access-reduction discipline that makes this decision reliable.

What good looks like: The organisation can explain why each dormant identity exists, who owns it, what it can still touch, and what condition will trigger deletion. NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 both reinforce the need to govern access, monitor for stale relationships, and keep recovery decisions deliberate rather than improvised.

Practitioner takeaway: Quarantine is the safer default when uncertainty remains, but it should be a controlled pause, not a permanent hiding place for unresolved access.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• What should organisations do first when cloud access feels too broad?
• What breaks when organisations try to remove unused cloud permissions one identity at a time?
• Who is accountable for privileged access risk when organisations move to a cloud-first operating model?