CrowdStrike detects a risk on an endpoint. Zscaler decides whether this device is allowed to access Internet services or private applications. Technically, both platforms can exchange context. Operationally, this is just the beginning of the real work.
After all, a device signal is not yet a finished business decision. A threshold that is too low can keep risky equipment working. A value that is too strict can lock legitimate users out of critical applications. And an automatic response without owner, exception path and return criterion creates more chaos than protection in the event of an incident.
Good integration therefore combines three levels: Signal, Policy and Operations.
Which signals can actually be used
The Zscaler-CrowdStrike integration supports multiple use cases. This includes device-specific posture checks, threat intelligence sharing, sandbox and endpoint context, telemetry for detection, and coordinated responses.
Device health is particularly relevant for adaptive access decisions. Zscaler documents that a CrowdStrike ZTA score can be used in device posture profiles. A defined minimum value then helps determine whether a posture test is passed.
This sounds simple, but it raises important questions:
- For which applications is the score relevant?
- Which sensor and client versions are required?
- What happens if the signal is missing or delayed?
- Does the same threshold apply to all user groups?
- What action follows a fall below?
- How does a cleaned device return to normal?
From score to professional risk class
A single global threshold rarely does justice to heterogeneous environments. Developer access to a source code repository, an administrative application, and a public intranet have different protection needs.
Therefore, the architecture should divide applications and user groups into risk classes. For each class, the following is determined:
- which CrowdStrike signals are required,
- which minimum values apply,
- whether a missing signal is blocked or restricted,
- what alternative work opportunities exist,
- who is allowed to approve an exception,
- when a reassessment will take place.
In this way, a technical value becomes a comprehensible access policy.
Four possible reactions – not just blocking
An integration does not have to answer every deviation with a complete lock. Depending on the risk, graduated reactions make sense.
Watch: The signal is logged and correlated without changing the access. This level is suitable for baselines and tests.
Restrict: The device only has access to defined services, such as remediation, help desk, or software distribution.
In addition, check: Stronger authentication, manual approval or additional context is required.
Block or isolate: High risk removes access to protected applications or puts the device in a controlled state.
The appropriate reaction does not only depend on the device score. Identity, active security events, application criticality, and existing mitigation measures are all part of the decision.
The exception path is part of the security architecture
No signal is infallible. Sensor problems, network glitches, version differences or a delayed status can lead to wrong decisions. Without a planned exceptional route, informal bypasses are created.
A clean exception process contains:
- clear applicant and professional owner,
- documented reason,
- limited scope,
- Expiration time,
- compensatory controls,
- a new technical examination,
- full audit trail.
Exceptions should not end up as a permanent user list. They are time-limited risk treatments.
The runbook for the moment of lockdown
If a user suddenly loses access, the help desk, SOC, and platform team need to see the same story.
The runbook should at least answer:
- What signal did the decision trigger?
- What score or incident context was available?
- Which Zscaler policy reacted?
- Which applications are affected?
- Is the device already included in CrowdStrike or under investigation?
- Who is allowed to lift the restriction?
- Which proof ends the process?
Without this chain, a security event becomes an ordinary "access is not possible" ticket. The help desk then searches in the wrong place, while the SOC does not know the user context.
First observe, then arm
The introduction should start with telemetry and simulation. Which devices would not reach a planned threshold? Which user groups would be affected? Which versions or locations do not provide a stable signal?
A controlled pilot includes:
- technical requirements and licenses,
- small, representative user group,
- defined applications,
- initial observation mode,
- jointly tested reactions,
- Helpdesk and SOC runbooks,
- measurable success criteria.
Only when signal quality, responsibilities and the return process are functioning should the policy be enforced more broadly.
The integration value lies in the joint operating model
Zscaler and CrowdStrike provide technical integration capabilities. However, the business value does not automatically come from activating an API.
It occurs when the security architecture, endpoint team, access management, SOC, and help desk use the same risk classes, responses, and evidence. Then isolated telemetry becomes a controlled decision: risky devices lose targeted access, cleaned devices return in a traceable way, and legitimate users are not slowed down by undocumented automation.