How do I block a single user in Zscaler Private Access?

Create a ZPA access policy rule with the action Block (deny), scoped to that user, for example with a SAML attribute condition on their email, and make sure it sits above every allow rule. If you create it through the API, check its position afterwards: new rules are added at the bottom.

Does a Zscaler block stop an attacker who already has a session?

Not on its own. Disable the account and revoke its sessions in your identity provider first, so no new tokens can be issued. Zscaler policy then stops access through ZPA and ZIA. Do both: identity revocation and Zscaler policy cover different paths.

Should I lock down or isolate a suspicious user in Zscaler?

Lock down when compromise is confirmed: deny private apps and block web access. Isolate when you're investigating and the user needs to keep working: route their web browsing through Cloud Browser Isolation so nothing executes on the device, while you watch.

How to contain a compromised user in Zscaler (ZPA and ZIA)

By Ashu Arun Sethi, Zscaler-certified (Zscaler ACE), HuCortex · Updated 17 October 2026

Revoke the account in your identity provider first. Then, in Zscaler, add a ZPA access policy rule that blocks the user and sits at position 1, add a ZIA URL filtering rule that blocks all categories for that user, and activate ZIA. If you're still investigating, route the user through Cloud Browser Isolation instead of blocking outright.

Contain it layer by layer

Layer	What to do	Stops
Identity provider	Disable the account, revoke sessions and refresh tokens, reset credentials and MFA	New logins and token refresh everywhere, not only through Zscaler
ZPA	Access policy rule, action Block, scoped to the user, at position 1	Access to private applications
ZIA	URL filtering rule blocking all categories for that user, then activate	Web and SaaS access through Zscaler
Device	Isolate the endpoint in your EDR; review the device in Zscaler Client Connector	Activity that doesn't depend on the user's identity

Step 1: Revoke the identity

Zscaler enforces policy on traffic; your identity provider decides who can authenticate. An attacker with a stolen session can keep using it until it's revoked, so disable the account and revoke its sessions first (Microsoft Entra ID, Okta and others all support this). The Zscaler steps below cover the access paths that identity revocation alone doesn't close straight away.

Step 2: Block private application access in ZPA

Create an access policy rule with the action Block.
Scope it to the user. A SAML attribute condition on their email is precise and doesn't depend on group membership, which an attacker may already have changed.
Move it to position 1. ZPA evaluates access rules in order and the first match wins, so a block below an allow rule does nothing.

Step 3: Block web access in ZIA

Find the user in ZIA (users must be synced or provisioned in ZIA to be targeted individually).
Create a URL filtering rule at the top of the policy with the action Block, all URL categories, and the user as the only criterion.
Activate the configuration. ZIA changes are staged until activation; an unactivated block protects nothing.

Isolate instead of block, while you investigate

If compromise isn't confirmed, or the user needs to keep working, route their browsing through Cloud Browser Isolation instead: ZPA isolation policy for private web apps, and a ZIA ISOLATE rule for the internet. Pages render in a remote browser and only pixels reach the device. Isolation applies to browsers only, so add a BLOCK rule directly below the ZIA isolate rule for that user to stop non-browser traffic.

Reversing a lockdown

Delete the ZPA block rule, delete the ZIA rule and activate, then re-enable the account in your identity provider with fresh credentials. Name your containment rules predictably (for example with the user's email in the rule name) so you can find them again under pressure.

How Zmate does this from Slack

/zmate lockdown user@company.com shows exactly what will change, then, once a Zmate admin confirms with a 6-digit MFA code, cuts that user off from private apps and the internet in one step. Only that user is affected: everyone else keeps working. /zmate unlock reverses it, and /zmate isolate is the softer option. Identity revocation stays with your identity provider.

See Zmate's incident response commands

FAQ

How do I block a single user in Zscaler Private Access?: Create a ZPA access policy rule with the action Block (deny), scoped to that user, for example with a SAML attribute condition on their email, and make sure it sits above every allow rule. If you create it through the API, check its position afterwards: new rules are added at the bottom.
Does a Zscaler block stop an attacker who already has a session?: Not on its own. Disable the account and revoke its sessions in your identity provider first, so no new tokens can be issued. Zscaler policy then stops access through ZPA and ZIA. Do both: identity revocation and Zscaler policy cover different paths.
Should I lock down or isolate a suspicious user in Zscaler?: Lock down when compromise is confirmed: deny private apps and block web access. Isolate when you're investigating and the user needs to keep working: route their web browsing through Cloud Browser Isolation so nothing executes on the device, while you watch.