Handling Unsupported or Legacy Clients in Cato Device Security Policies

Zero Trust does not fail because of missing controls.
It fails when organizations cannot enforce controls consistently across real-world environments.

Every enterprise faces the same reality: a mix of modern, fully supported endpoints and legacy or partially supported clients that cannot be upgraded overnight. The challenge is not whether these devices exist—it is how security teams manage them without breaking access, productivity, or Zero Trust intent.

Cato SASE addresses this challenge explicitly by giving administrators controlled, policy-driven options for handling unsupported or legacy clients—without creating blind trust or operational chaos.

This blog explains how Cato handles unsupported clients, why this matters for Zero Trust maturity, and how to design policies that balance risk, continuity, and enforcement.

Why Unsupported Clients Are a Real Zero Trust Challenge

Zero Trust assumes continuous verification of:

• Identity
• Device posture
• Context

However, posture verification depends on client capability. If a device cannot technically perform a specific posture check, security teams must choose between:

• Blocking access entirely
• Allowing access blindly
• Designing a controlled exception

Cato does not force a single answer. Instead, it enables explicit, auditable decision-making inside the policy engine.

What “Unsupported Client” Means in Cato SASE

In Cato SASE, a client is considered unsupported only in the context of a specific device check, not globally.

Examples:

• A legacy Cato Client version that does not support a new Device Check
• An operating system that cannot perform a specific posture validation
• A device type that lacks required telemetry

Importantly:

• The client may still authenticate correctly
• Other security controls may still apply
• Only the specific posture check is affected

This distinction is critical for designing precise policies instead of blanket exceptions.

The Two Policy Options: Skip Check vs Apply Check

Cato provides two explicit behaviors when a device does not support a required posture check. These behaviors are configured per Device Check, not globally.

Skip Check: Controlled Continuity

When Skip check is enabled:

• Unsupported clients bypass that specific posture check
• The firewall rule still applies its action (Allow or Block)
• Enforcement remains predictable and auditable

When this is used

• Transitional environments
• Temporary coexistence with legacy systems
• Phased rollout of stricter posture enforcement

Security implication

• Risk is acknowledged, not ignored
• Access is still governed by identity, location, platform, and other controls

This option allows Zero Trust programs to progress without operational disruption.

Apply Check: Strict Zero Trust Enforcement

When Apply check is disabled:

• Unsupported clients fail to match the posture condition
• The firewall rule is skipped
• Access is determined by subsequent rules (often an implicit deny)

When this is used

• High-risk environments
• Sensitive applications or data
• Mature Zero Trust enforcement stages

Security implication

• No silent exceptions
• Unsupported clients are intentionally excluded

This model enforces posture compliance as a non-negotiable requirement.

Why This Design Matters for Zero Trust Maturity

Zero Trust is not binary. It evolves.

Cato’s approach enables organizations to:

• Start with continuity-focused enforcement
• Gradually increase posture strictness
• Avoid “all-or-nothing” security decisions

Instead of weakening Zero Trust, this model makes it deployable in real enterprises.

Policy Design Best Practices in Cato SASE

To use these controls effectively:

Use Allow Rules for Compliant Devices

• Define Device Posture Profiles with minimum requirements
• Apply them to Allow rules
• Let non-compliant or unsupported clients fall through naturally

Minimize Skip-Check Scope

• Limit Skip Check to clearly defined rules
• Avoid broad policies that silently allow unknown risk

Segment by Risk, Not Convenience

• High-value resources → strict Apply Check
• General access → transitional Skip Check where justified

Review Unsupported Client Events Regularly

• Unsupported clients should be visible
• Exceptions should be intentional, time-bound, and reviewed
   

Operational Visibility and Governance

Cato ensures that unsupported client behavior is not hidden:

• Enforcement decisions are logged
• Posture-related failures generate events
• Access behavior remains auditable

This allows security teams to:

• Track legacy exposure
• Measure Zero Trust progress
• Justify enforcement decisions during audits

Business Outcome: Security Without Stalling the Enterprise

Cato’s handling of unsupported clients enables:

• Gradual Zero Trust adoption
• Reduced business disruption
• Predictable access behavior
• Stronger long-term security posture

This is how Zero Trust succeeds in production—not through rigidity, but through intentional control.

Balance security, compliance, and operational continuity with the right Cato SASE design → Reserve your 30-minute Zero Trust consultation with our experts now.

 

Frequently Asked Questions 

How does Cato SASE handle unsupported or legacy clients in device security policies?

Cato SASE allows administrators to explicitly define how unsupported clients behave using Skip Check or Apply Check options within Device Posture Profiles, ensuring controlled and auditable enforcement.
 

What is the difference between Skip Check and Apply Check in Cato SASE?

Skip Check allows unsupported clients to bypass a specific posture check while still enforcing the firewall rule action, whereas Apply Check causes unsupported clients to fail the posture condition and skip the rule entirely.

Does Skip Check weaken Zero Trust in Cato SASE?

No. Skip Check in Cato SASE enables transitional enforcement while still applying identity, location, and firewall controls. It is a deliberate risk-management choice, not implicit trust.

When should Apply Check be used in Cato device security policies?

Apply Check should be used in Cato SASE environments protecting sensitive resources, where device compliance is mandatory and unsupported clients must not gain access.

How does Cato SASE help organizations migrate away from legacy clients?

Cato SASE provides visibility into unsupported client usage and allows phased enforcement, enabling organizations to tighten posture requirements over time without sudden disruptions.

Is unsupported client behavior visible for audits in Cato SASE?

Yes. Cato SASE logs posture-related enforcement behavior and events, allowing security teams to audit exceptions and demonstrate controlled Zero Trust enforcement.