A Quarantine Policy is an access control measure used to isolate an identity or workload when compromise is suspected. In cloud environments, it restricts normal permissions so defenders can reduce blast radius while they investigate. The practical goal is containment, not remediation, and it usually works alongside log review and policy analysis.
Expanded Definition
A quarantine policy is a containment control that temporarily narrows access for an identity or workload when compromise is suspected. It is not a fix for the underlying issue; it is a deliberate state change that preserves enough access for investigation while limiting what the affected subject can do.
In practice, quarantine sits between normal operation and full revocation. It may block write actions, remove privilege paths, restrict network reach, or force the subject into a monitored segment. The boundary is important: quarantine is used when defenders need to slow blast radius without immediately destroying evidence or interrupting every dependent workflow. That makes it different from remediation, offboarding, or suspension after confirmed abuse.
Definitions vary across vendors and platforms, especially in cloud control planes where “quarantine” can mean anything from a tag-based policy state to a tightly scoped deny posture. The consistent security meaning is containment under uncertainty, not permanent enforcement.
Examples and Use Cases
Quarantine policies usually appear in workflows where defenders need to reduce exposure fast while they confirm what happened. The exact mechanics depend on the platform, but the operational pattern is consistent: isolate first, investigate next, restore only after trust is re-established.
- A suspected service account is moved into a restricted policy state that blocks deployment actions but still allows log collection and ownership review.
- A workload with abnormal outbound calls is isolated from sensitive data stores while analysts verify whether the behavior came from misconfiguration or compromise.
- A cloud identity that shows privilege misuse is limited to a narrow read-only posture so responders can trace activity without giving it broad execution rights.
- A third-party integration is quarantined after unusual token use, reducing the chance that a compromised external path can reach internal systems.
These uses trade speed for certainty. Quarantine can preserve evidence and reduce blast radius, but if it is too weak it becomes symbolic, and if it is too broad it can break business services that depend on the subject.
For broader NHI context, NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which helps explain why containment controls are often triggered before teams have complete inventory confidence.
Security Implications
Mismanaging quarantine policy creates a difficult failure mode: the organisation believes it has contained a suspected identity or workload, but the subject still retains enough privilege or network reach to exfiltrate data, trigger actions, or pivot elsewhere. In cloud environments, weak quarantine can also leave long-lived tokens, API keys, or cached credentials usable outside the visible policy boundary.
The opposite error is over-quarantine. If defenders isolate the wrong identity, or if the control removes access that operations still need, incident handling can lose visibility and delay root-cause analysis. That can increase dwell time because responders no longer see the behaviour they needed to inspect.
When quarantine is effective, it narrows blast radius and buys time. When it is poorly designed, it creates a false sense of safety, and the real exposure remains hidden behind an access state that looks controlled but is not materially restrictive.
A common practitioner signal is a quarantine action that changes labels or UI state without a measurable change in effective permissions, network paths, or token usability. That is usually containment theatre, not containment.
Domain and Governance Relevance
Quarantine policy matters in NHI and workload governance because machine identities often have persistent access, broad automation privileges, and dependencies that humans do not notice until an incident begins. For that reason, quarantine is part of operational control over machine trust, not just an incident response convenience.
In NHI-heavy environments, the key governance question is whether quarantine can be applied quickly enough to reduce blast radius without breaking the evidence chain that tells defenders what the workload or identity actually did. That requires clear ownership, pre-approved containment paths, and a policy model that can distinguish between suspected compromise, misconfiguration, and planned maintenance.
Quarantine also fits the lifecycle reality of NHIs: visibility gaps, excess privilege, and stale credentials make it unsafe to rely only on immediate revocation. A well-designed quarantine policy gives responders a controlled intermediate state while they decide whether the identity should be restored, rotated, or fully retired.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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 |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Quarantine policy reduces or limits access paths for a suspected compromised identity. |
| 8 — Audit Log Management | Quarantine is usually paired with log review to preserve investigation visibility. | |
| Recommendation — Restrict suspect access paths immediately and verify the reduced privilege state is enforced. Preserve and review logs before restoring or revoking the quarantined subject. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | Quarantine is an access-control state used to contain suspected compromise. |
| DE.CM — Continuous Monitoring | Quarantine depends on monitoring to confirm suspicious activity and containment effect. | |
| Recommendation — Apply access restrictions that materially shrink the subject’s reachable actions and data. Monitor the quarantined subject to validate whether containment is working. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Attackers abuse or alter accounts and access states to preserve control after compromise. |
| Recommendation — Hunt for unauthorized privilege changes or access-state manipulation around the quarantined identity. | ||
Related resources from NHI Mgmt Group
- How should security teams validate whether an AWS compromised-key quarantine policy actually blocks attacker follow-on activity?
- Who should own validation of quarantine policy coverage across IAM, Lambda, S3, and EC2 controls?
- Cloud Quarantine Policy
- When does policy-based access control reduce risk for NHI environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
