ZCC Posture Profiles
Zscaler splits device posture in two: the profile that checks something on the device lives in the mobile admin area, and the access policy that depends on that check lives in ZPA. ZHERO makes the profile a real entity, says what it actually verifies, and links the two halves together.
It is for anyone who has to answer “does our access really require a managed, protected device”, and wants to answer it from evidence rather than from a naming convention.
When to use it
- Posture governance reviews: confirm the profiles gating production access check what you think they check.
- Before removing a profile: see which access policies depend on it first.
- When an access decision surprises you: from the policy’s posture condition, jump to the profile that evaluates it.
- Cleanup campaigns: find the profiles nothing references any more.
Where to find it in the UI
Posture profiles behave like every other ZHERO entity:
- Inline badge, hover card and drill-down drawer wherever a profile is referenced.
- In the Entities table, with dedicated posture columns for sorting and filtering.
- On the Mobile Admin Device Posture page, where ZHERO renders its card directly on the Posture Name column: the intelligence appears where the profiles already live.
- From a ZPA access policy’s posture condition, through the cross-link.
Posture families
Every profile is classified into a family, so its card says what it verifies rather than only what somebody named it.
| Family | What the profile verifies |
|---|---|
| domain-join | The device is domain joined, including Entra and hybrid join |
| edr | An EDR agent is present: CrowdStrike, SentinelOne, Microsoft Defender, Carbon Black |
| antivirus | A generic antivirus is detected |
| certificate | A client or server-validated certificate is present |
| device-hygiene | Firewall on, full disk encryption on |
| os-version | OS version, ZCC version, sensor settings |
| mobile-integrity | Ownership and unauthorized-modification checks on mobile |
| mdm | Management detection, such as Jamf |
| marker | A registry key, file path, process check or override: a flag, not a security control |
| unknown | Could not be classified |
Confidence, and why it is shown
The classification comes from one of two sources, and the card says which:
- From the posture type, the authoritative path: Zscaler’s own posture kind maps directly to a family.
- From the name, a fallback when the type is not available: the profile’s display name is matched against known patterns.
Read a name-derived classification as a strong hint, not a fact. An admin who names things oddly can mislead a name heuristic; the type cannot.
Markers are not enforcement
The one distinction worth internalising: a marker profile checks that a registry key, a file or a process exists. It is frequently used as an exemption mechanism, a way to let specific devices skip a requirement. A profile named “SentinelOne Override” is a marker, not EDR enforcement, and the classifier deliberately checks the marker patterns before the EDR ones so it is never miscounted as protection.
This is also why the posture enforcement analysis templates never accept a marker posture as satisfying a domain-join or EDR requirement.
The cross-link
A ZCC posture profile card links to the matching ZPA posture criterion, and from there to every access policy that uses it. The trip works in reverse too: from a policy’s posture condition back to the profile that evaluates it on the device.
That is the pair of clicks that used to be an exercise in copying identifiers between two consoles.
What to watch
- Profiles nothing references. A posture profile no policy uses verifies nothing that matters.
- Production access gated only by markers. The condition is present, the protection is not.
- A family you did not expect. A profile everyone calls “the EDR check” classified as device-hygiene is a conversation worth having before the next audit.
- Name-derived classifications on important profiles. Worth confirming against the profile’s actual type in the console.
Limits and notes
- Classification is derived, not declared by Zscaler. Some posture-type mappings were verified on a live tenant and others inferred from Zscaler’s own documentation ordering. An unrecognised type falls back to the name heuristic rather than failing, and the card always shows which path was used.
- It describes what the profile checks, not whether devices pass. Per-device posture results live in the Zscaler console.
- The cross-link needs both halves present: a ZPA plane with posture criteria, and the posture profiles themselves. On Experience Center tenants, both are there.
- This is a read surface. Posture profiles are edited in the Zscaler console.
FAQ
Why does my profile show as “marker” when it clearly detects an antivirus? Because its name contains a marker word (registry, file, override) and the classification fell back to the name heuristic. That precedence is deliberate: an override profile that counted as EDR would be worse than an EDR profile mislabelled as a marker. Check the profile’s type in the console, and consider renaming it.
How is this different from the posture enforcement templates? The templates ask a policy-level question: do your access policies require a domain-joined or EDR-protected device. This page is about the profiles themselves: what each one checks, and what depends on it. The templates are powered by these classifications.
Can I see which devices fail a given posture check? Not here. That is per-device evaluation, which lives in the Zscaler console. ZHERO covers the configuration layer: what is checked, and what the check gates.
Where do the posture columns in the Entities table come from? The same classification. They let you sort and filter profiles across the fleet, for example to list everything classified as marker.
Related pages
- ZCC Fleet Health: the rest of the ZCC picture
- Analysis Templates catalog: the posture enforcement templates
- ZPA Infrastructure Dashboard
- Entities Table: posture columns for sorting and filtering
Next steps
- Open the Mobile Admin Device Posture page and read the families ZHERO puts on the profiles
- List your profiles in the Entities table and sort by family
- Follow the cross-link from one profile to the policies that enforce it
- Run the posture enforcement templates and compare the result with what you assumed