What is the difference between quarantine and revocation for non-human identities?

Quarantine blocks access while keeping the identity object and underlying infrastructure intact, so it is reversible and less disruptive. Revocation removes the permission path entirely, which is safer only when the dependency impact is known and the identity is no longer operationally required.

How quarantine and revocation differ in practice

Quarantine is a containment move. It blocks or narrows access while preserving the non-human identity object, its ownership data, and usually the underlying infrastructure or integration path. That makes it reversible and useful when you need time to investigate, test dependencies, or decide whether the identity still has a legitimate operational role.

Revocation is a removal move. It tears down the permission path so the identity can no longer authenticate or reach the target system through that route. It is the stronger control when the dependency is understood and the identity should no longer be able to act, but it is less forgiving if the identity still supports live production processes.

The practical distinction is not just severity, it is reversibility. Quarantine answers, “Can we safely pause this identity without breaking the environment?” Revocation answers, “Have we confirmed this access is no longer required, so we can remove it entirely?”

When quarantine is the safer first step

Quarantine is usually the better first response when the impact of removal is uncertain, when multiple services depend on the same identity, or when you need to preserve evidence before making a final access decision. It gives teams a controlled way to stop active use while keeping enough context to diagnose ownership, dependency chains, and downstream failure risk.

That matters especially for shared or poorly documented non-human identities, where immediate revocation can create avoidable outages. A quarantined identity can often be held in a restricted state while engineers verify whether it is still used for scheduled jobs, service-to-service calls, CI/CD, integrations, or certificate renewal.

Service Account Security Guide is useful here because quarantine is often the practical bridge between discovery and full deprovisioning for service accounts and similar machine identities.

Quarantine is also the right choice when the team suspects abuse but has not yet confirmed whether the identity is still needed. In that case, the goal is to reduce blast radius first, then make a deliberate removal decision once the dependency map is clear.

When revocation is the safer end state

Revocation is the preferred outcome when the identity has been retired, replaced, or proven unnecessary. It removes standing access rather than just suppressing it, which is the right posture for identities that should no longer be able to authenticate, obtain tokens, or reach production resources.

This is especially important when the identity can still be abused through cached trust, stale credentials, or forgotten integration paths. Revocation closes the door rather than leaving a controlled opening, so it is the stronger option once operational need has ended.

Joiner-Mover-Leaver (JML) Guide and Guide to NHI Rotation Challenges both reinforce the same operational point: removal becomes safest when ownership, dependency mapping, and rotation or replacement paths are already known.

For certificate-backed identities, CA/Browser Forum is relevant because revocation only works cleanly when certificate lifecycle and revocation handling are part of the operating model, not an afterthought.

Risk and Threat Considerations

Quarantine reduces exposure quickly, but it can also hide unresolved dependency risk if teams treat it as a final answer. Revocation removes access more decisively, but if the identity is still in use, the result can be an outage, failed automation, or broken service-to-service trust.

Failure mechanism: A quarantined identity may still exist in configuration, orchestration, or ownership records, which means the underlying dependency can remain invisible until the next job, token exchange, or certificate renewal fails. A revoked identity can also break adjacent systems if the dependency was never documented.

Impact: The main risk on the quarantine side is lingering exposure, because the identity remains recoverable if controls are weak or the quarantine state is bypassed. The main risk on the revocation side is operational disruption, because a legitimate process may lose the access path it still requires.

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 surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Improper Offboarding	Quarantine vs revocation is an offboarding decision for non-human identities.
	NHI-07 — Long-Lived Secrets	Revocation and quarantine both affect whether secrets remain usable after access should stop.
	NHI-05 — Overprivileged NHI	Quarantine and revocation are privilege-reduction choices for machine identities.
Recommendation — Use quarantine to contain access while you confirm dependencies, then revoke unused NHI access completely. Replace indefinite credentials with short-lived access and revoke standing secrets when the identity is retired. Reduce privilege first through quarantine, then remove excess access paths once dependency impact is verified.
NIST SP 800-53 Rev 5	AC-2 — Account Management	Account lifecycle control governs suspension, disabling, and termination of non-human identities.
	IA-5 — Authenticator Management	Quarantine and revocation both depend on controlling the lifecycle of credentials and authenticators.
	IA-9 — Service Identification and Authentication	Non-human identities often authenticate as services or workloads, making lifecycle control material.
Recommendation — Define clear suspension and termination conditions for machine accounts and enforce them consistently. Track, rotate, and invalidate authenticators so disabled identities cannot keep authenticating. Bind service authenticator status to lifecycle state so revoked access cannot be reused.
ISO/IEC 27001:2022	A.5.18 — Access rights	Access-right lifecycle governs suspension, review, and removal decisions for identities.
	A.8.2 — Privileged access rights	Non-human identities often hold elevated permissions that must be withdrawn when no longer needed.
	A.8.5 — Secure authentication	Revocation depends on preventing disabled identities from continuing to authenticate.
Recommendation — Review, suspend, and remove access rights according to verified operational need. Restrict and withdraw privileged access as soon as the identity no longer has a justified business role. Invalidate authentication material promptly when access must end.

Practitioner Guidance

Decision rule: Start with quarantine when you do not yet know the blast radius, owner, or downstream consumers. Move to revocation only after you have confirmed that the identity is no longer required, or after you have a replacement path ready and tested.

What to verify: Before revoking, confirm the identity’s owner, last use, dependent systems, and whether it authenticates directly or through a chain such as a token, certificate, or delegated integration. Before leaving something quarantined for long, verify that the state is still enforced and that the object cannot be silently reactivated.

Practitioner takeaway: Quarantine is a control for uncertainty, revocation is a control for closure, and the right sequence is to preserve reversibility until you can prove the identity is truly no longer operationally required.