What Is Cato Private Access?

Cato Private Access provides user-to-application access through a brokered architecture. Users do not directly connect to the network that hosts the application. Instead, access is established only to applications that are explicitly defined and exposed through App Connectors.

Private Access supports user-initiated access only. Applications do not initiate connections toward users, and server-initiated or bidirectional communication patterns are not supported. This design enforces strict isolation between users and application environments and eliminates the need to expose internal networks or advertise routes.

Scenarios that require server-initiated or bidirectional communication fall outside the scope of Private Access and are supported by the full Cato networking architecture of IPsec and Socket sites.

For more information, see Zero Trust Access to Private Applications with the Cato SASE Cloud.

The Private Access service is licensed by users per region group. For more information, please contact your Cato representative or official reseller.

Private Applications represent the internal apps you publish through Cato.

For each application, you publish internal resources securely by defining how users access the application and which Connector Group provides authorized connectivity. Applications are abstracted from internal IP addressing, and users access the published domain rather than the internal network.

You deploy App Connectors in the same environment as the protected application (data center, cloud VPC, or LAN) to securely connect that environment to the Cato Cloud. Each connector establishes an outbound-only DTLS tunnel and forwards only sessions that were explicitly authorized by policy. Because connectors do not accept inbound connections and do not require routing changes, you can introduce Private Access without redesigning the application network. You can deploy multiple connectors to increase resiliency and scale.

App Connector Groups logically group connectors to provide high availability, load distribution, and operational separation. Private applications are attached to a Connector Group rather than to a specific connector. This means that if a specific connector experiences an issue, the application can automatically use another available connector in the group.

You use the Private Access Policy to control who can access which private applications and under what conditions. The policy lets you grant application-level access based on user identity and context while maintaining a default-deny posture. Authorization is evaluated at the PoP before any session is established to the application environment, ensuring that only explicitly permitted connections are brokered to the application.

Securely expose internal applications without modifying routing, advertising subnets, or changing WAN architecture.

Private Access requires no inbound firewall rules, uses outbound-only tunnels from the application environment, does not require IP readdressing, and does not require site on-ramping. This makes it ideal for fast onboarding of private applications while preserving the existing network design.

In M&A scenarios, overlapping IP ranges often delay integration.

Private Access publishes applications without requiring IP readdressing, abstracts internal addressing using CGNAT and DNS mapping, and allows user access without routing-domain integration. This supports rapid, non-disruptive onboarding of acquired environments.

If bidirectional or server-initiated connectivity is required later, you can onboard the environment as a full Cato site.