What is user isolation?
User isolation is the rapid containment of a compromised or suspicious user or device, by cutting off access to the internet and to internal applications. The goal is to limit damage before it spreads: no further data exfiltration, no lateral movement to other systems. In a Zscaler context, that means closing internet access through ZIA and access to internal applications through ZPA at the same time. Isolation is a containment step within incident handling, and it is deliberately reversible, so access can be restored once the situation is clear. Speed matters here, because every minute increases the potential damage.
User isolation in detail
Isolation is a containment measure, not an end state. In incident handling, it follows a suspicion and comes before the actual investigation: close off access first, then investigate calmly. It only works if both paths are closed. If internet access stays open, malware can keep downloading further payloads or exfiltrating data; if access to internal applications stays open, the path to sensitive systems is not blocked.
Isolation differs from an account lockout in the identity provider in what it actually does. Deactivating an account blocks new logins, but does not always immediately affect existing sessions. User isolation, by contrast, specifically closes the active access paths and takes effect immediately. The two complement each other: account lockout against new logins, isolation against traffic already in progress. The way back still matters, because isolation that cannot be lifted cleanly tends to get applied too late, out of caution.
Why user isolation matters in Zscaler operations
In a security incident, time to containment is what counts. The faster a compromised user is cut off from the network, the smaller the blast radius stays: fewer infected systems, less data exfiltrated, less effort spent on recovery. That is exactly why the ability to isolate a user immediately, across both paths, is a core building block of incident response and a recurring topic in emergency drills.
Under NIS2 evidence obligations, incident handling is one of the required capabilities. Isolation that takes effect quickly and is cleanly logged at the same time delivers both: the ability to act when it matters, and traceability afterwards. Making that work needs clear roles, a defined trigger and a documented way back, instead of improvised one-off actions under pressure. That turns a hectic emergency measure into a rehearsed, reliable step.
Common sources of error
- Only one path closed: if only internet access or only app access is cut, the other flank stays open.
- No way back: without a defined process for lifting it, isolation gets applied too late, out of fear of collateral damage.
- No log entry: containment without an entry in the audit trail cannot be traced cleanly afterwards.
- Isolation confused with account deletion: containment is reversible, permanent deletion is something else entirely.
User isolation in practice: what CentaurNexus contributes
With Emergency User Isolation, CentaurNexus cuts off a compromised user's internet and app access in one step, across ZIA and ZPA together, so no flank stays open. The action is reversible and lands in the append-only audit trail, optionally with four-eyes sign-off. Endpoint Sensor Status adds visibility into CrowdStrike sensor coverage per endpoint, so a device is not just cut off but also kept in view. The following article shows how the helpdesk does this without broad admin rights: Zscaler support without admin rights.
Related terms
Frequently asked questions about user isolation
User isolation is the rapid containment of a compromised or suspicious user or device. It cuts off access to the internet and to internal applications, to limit damage such as lateral movement or data exfiltration. It is a containment step within incident handling, and deliberately reversible, so access can be restored once the situation is resolved.
Isolation only works if both paths are closed: internet access through ZIA and access to internal applications through ZPA. If only one path is cut, the other remains as an open flank. That is why cutting off both channels belongs together, ideally in a single step.
No. Locking the account in the identity provider disables login, but often does not immediately affect existing sessions. User isolation specifically closes the active access paths through Zscaler, and so takes effect immediately on traffic already in progress. The two measures complement each other in incident handling.
Yes, and that matters. Isolation serves containment, not punishment: if a suspicion turns out to be unfounded, access must be restorable quickly. A clearly defined way back is therefore just as much part of the process as the rapid shutdown when something looks suspicious.
That should be limited to clearly named roles, so that no one hesitates when it matters and no one acts beyond their mandate. A defined trigger, sign-off under the four-eyes principle where needed, and an entry in the audit trail have all proven their worth. That keeps the measure fast and traceable at the same time.
- NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide (Containment) - csrc.nist.gov
- BSI IT-Grundschutz, module DER.2.1 (handling security incidents) - bsi.bund.de
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners.