How to Publish a Private App with Cato ZTNA (Agentless, No VPN)

To give someone access to an internal application without a VPN or an agent, publish it through Cato's browser-based access. Enable the Applications Portal under Access > Browser Access Control > Settings, add the application on the Applications tab with its internal host address, port and protocol, then create a Browser Access rule naming who can reach it. The user opens your portal URL in Chrome, Edge or Safari, signs in with SSO, and clicks the app. Nothing is installed, and the application is never exposed to the internet.

For the newer Private Access model, you deploy an App Connector inside the application's network and publish the app under Access > Private Apps instead. Which path you use depends on where the application lives — the next section settles that in under a minute.

Which agentless path should you use?

Cato has two ways to publish a private application for browser access, and picking the wrong one wastes a day.

That last row matters and is easy to miss: Cato's documentation states you must contact them to enable and use the Private Apps feature. If you planned your afternoon around it and it is not on your account yet, you will not find the menu. Check before you schedule the work.

The rest of this guide covers both paths. Start with the Applications Portal if your application already sits behind a Cato site — it is faster and needs no new infrastructure.

What do you need before you start?

• An internal application reachable from the Cato network, with its host address, port and protocol (HTTP or HTTPS) confirmed

• Admin access to the Cato Management Application

• Your identity provider configured under Access > Single Sign-On, if you want SSO sign-in

• For the Private Apps path: an App Connector deployed in the same network as the application, physical or in Azure

• A decision on who gets access — a group in your IdP is cleaner than a list of individuals

One thing to check now rather than later: if you intend to use source NAT, browser-based remote access does not support overlapping IPs between the SNAT range and a site's IP range. Pick a range that collides with nothing.

Why does agentless ZTNA remove the need for a VPN?

A VPN puts the user on your network and then relies on firewall rules to stop them reaching everything else. Agentless ZTNA inverts that. The user never joins the network — they reach a portal, authenticate, and Cato brokers a session to one named application. There is no route to anything else, because no route was ever created.

The architecture detail that makes this safe is worth understanding. An App Connector establishes an outbound-only DTLS tunnel to the Cato Cloud. You open no inbound firewall port, publish no public IP, and expose no application to the internet. If an attacker scans your perimeter, there is nothing new to find.

For RDP and SSH, the portal forwards the request through the Translation Engine on the Cato PoP, which connects to the host using that protocol. The user gets a working session in a browser tab with no client installed — which is why this is the standard answer for contractors, auditors and third-party support who will never accept your agent on their laptop.

Path A: How do you publish an app through the Applications Portal?

Step 1 — Enable the portal

1. Go to Access > Browser Access Control and open the Settings tab.

2. Turn on the Applications Portal slider.

3. Note the Portal URL shown on the Settings tab. It is derived from your account subdomain — letters and numbers only, with dashes allowed only if the account was created with one. This is the address your users will bookmark, so get it right now; it is not a casual thing to change later.

Step 2 — Configure authentication

1. In the Clientless SDP Users section, enable Allow login with Single Sign-On to use your IdP, or Allow login with Cato user credentials for accounts defined in the CMA. You can enable both.

2. Add your domains under Allowed Domains.

Caution: If you use SSO, the SSO domain must appear in Allowed Domains or access is blocked. This is the single most common reason a correctly built portal rejects everyone on day one.

3. Set the Cookie type to Session or Persistent and set the Duration. Session cookies expire when the browser closes or after the idle duration. For contractors and auditors, choose Session and a short duration — the whole point of agentless access is that it leaves nothing behind.

4. If you need source NAT, enter the NAT IP Range in CIDR notation. Private ranges are fine; the range applies only between the portal and the application server.

Step 3 — Add the application

1. Open the Applications tab and click New.

2. Enter the Name as users should see it in the portal.

3. Enter a Description — it appears as hover text, so write it for the user, not for you.

4. Configure the URL settings: an optional Landing Page, an optional Base Path that blocks resources outside it, and the URL prefix.

5. Upload an Icon. This sounds cosmetic and is not — a portal of unlabelled tiles generates support tickets.

6. Under internal host settings, enter the Host Address (an IP is used to connect; a host name is added to the header), the Port, the Protocol (HTTP or HTTPS), and optionally the Host Name.

7. Select Use source NAT IP range if required. It stays greyed out until the NAT IP Range is set in Settings.

8. Click Apply.

Use Base Path deliberately. It restricts which URLs can reach the application, which is how you publish one module of an internal system without exposing the rest of it.

Step 4 — Grant access

Create Browser Access rules specifying which users or groups can reach which applications. Scope to groups from your IdP rather than individuals, or you will be editing this rule every time someone joins or leaves.

Path B: How do you publish a Private App with an App Connector?

Use this when the application lives somewhere you do not want to onramp to your network — a cloud VPC, a partner data centre, an acquired company's environment.

Step 1 — Deploy the App Connector first

1. Deploy the connector in the same network as the application, physical or in Azure.

2. Assign connectors to an App Connector Group so the application does not depend on a single connector.

3. Confirm the application is routable from the connector and accepts inbound traffic from it.

4. Confirm the application's address resolves through the Internal DNS Server set for the App Connector.

Cato's documented best practice is to deploy the connector before you publish the application. Follow it — if no connector exists, the app stays Disabled and you will spend an hour debugging a toggle that is working exactly as designed.

Step 2 — Add the private app

1. Go to Access > Private Apps and click New to open the Add Private App panel.

2. Under General, enter a Name and optional Description.

3. Under App Settings, enter the Internal App Address — the application's hostname or IP. An FQDN must be resolvable internally.

4. Add the Service / Port as a protocol and port range, for example TCP/80-88. Add one entry per service, and keep it to what the application actually needs. A wide port range here quietly undoes the least-privilege gain you came for.

Step 3 — Publish it

1. Set the Publish toggle to Enabled.

2. Enter the Published App Domain — the user-facing FQDN or domain, such as *.example.intranet.

3. Set Publish via to App Connectors Group and select the App Connector Group.

4. Leave Probing on. It uses ICMP with a configurable Interval (Sec) and Fault Threshold. Disabling it removes CMA visibility into connectivity and performance, so only turn it off for applications that genuinely do not answer ICMP.

5. Click Apply.

Step 4 — Write the Private Access Policy rule

The policy is an ordered rulebase and only the highest-priority matching rule applies. Each rule takes:

• Users / Groups — who gets access

• Criteria — optional conditions, such as requiring a valid anti-virus solution on the device

• Private Apps — which applications those users can reach

Private Access requires authenticated user identity, so your account must use an IdP. Unauthenticated users cannot reach private applications at all — there is no anonymous path to leave open by accident.

The Criteria field is where this stops being a VPN replacement and becomes something better. A contractor on an unmanaged laptop can be given one application with a posture check attached, and nothing else, for a fixed window. Posture criteria are only as good as the device data behind them, which is why this pairs with unified endpoint management on devices you own — and why unmanaged devices should be given the narrowest app list you can live with.

How do you verify it actually works?

Test as a real user, not as an admin. Open the Portal URL in a clean browser profile — Chrome, Edge and Safari are supported on Windows, macOS, iOS and Android. Sign in with a test account in the permitted group. The application should appear as a tile and open in the browser.

Test the negative case. Sign in with an account outside the group and confirm the application does not appear. An access control you have only tested positively is not tested.

Test from outside your network. The entire premise is access without a VPN. Verify from a home connection or mobile tethering, not from the office LAN where the app may be reachable anyway and you prove nothing.

Check the session. For RDP and SSH, confirm the session opens and is usable, not merely that it connects. Latency through the Translation Engine is normally fine but is worth seeing before you hand it to twenty people.

What commonly breaks, and how do you avoid it?

• The SSO domain is missing from Allowed Domains. Access is blocked for everyone. Check this first, always.

• Overlapping IP ranges. Browser-based remote access does not support overlapping IPs between the SNAT range and a site's range.

• RDS farms are not supported. Browser access supports RDP to specific hosts, not RDS farms that use a connection broker or load balancer. If your environment is a farm, this path will not work and no amount of configuration will change that.

• Internal DNS does not resolve. For Private Apps, the Internal App Address must resolve through the App Connector's Internal DNS Server, not yours.

• The app stays Disabled. No App Connector is deployed yet. Deploy it, then publish.

• Port ranges that are too wide. Every extra port is access you did not intend to grant.

• Probing disabled by habit. You lose connectivity and performance visibility in the CMA, which you will want the first time a user says the app is slow.

• Nobody told the users. An agentless portal only works if people know the URL. Send it with a screenshot before go-live, not after the first support ticket.

A note on scope: agentless browser access is the right answer for contractors, BYOD and third parties, and for a fast pilot. It is not a complete replacement for managed-device access, because a browser session cannot do everything a tunnelled client can. Most organisations end up running both — the Cato Client deployed through JumpCloud for managed laptops, and agentless portal access for everyone else. Deciding which users belong in which group is the actual design work, and it is worth doing on paper before you touch the console. It is also the point where published apps start overlapping with the rest of your access stack — identity, device posture and managed zero trust architecture decide what a published app is actually worth once it is live.

FAQs

1) Does agentless access mean the application is exposed to the internet?

No, and this is the main security argument for it. The App Connector opens an outbound-only DTLS tunnel to the Cato Cloud, so you publish no public IP and open no inbound firewall port. Users reach a Cato-hosted portal and Cato brokers the session inward. From the outside, your application has no attack surface to scan.

2) Can contractors use this without installing anything?

Yes — that is the primary use case. They open your portal URL in a standard browser, authenticate against your IdP, and see only the applications your Browser Access or Private Access rule grants them. Nothing is installed, and with Session cookies and a short duration, nothing persists after they close the browser. This is why agentless access is usually the fastest way to get third-party support or an auditor working without a procurement argument about endpoint agents. Third-party access is also where most access reviews fail an audit, so pair it with time-bound rules and the vendor-access controls covered under managed zero trust services.

3) Is this a full replacement for our VPN?

For application access, largely yes — and it is a better model, because users reach named applications rather than joining your network. But browser-based access covers HTTP/S, RDP and SSH, so thick clients and unusual protocols still need a tunnelled client. The realistic plan is to move application access to ZTNA, shrink the VPN to what genuinely needs it, and retire it in stages — which is how ZTNA deployments are normally phased rather than cut over in one weekend. If you are still running legacy remote access, the same staged logic applies as in migrating FortiGate SSL VPN to IPsec — the sequence matters more than the destination.

4) Why can some users not see the application in the portal?

Three causes, in order of likelihood: their group is not named in the Browser Access or Private Access rule; their sign-in domain is not in Allowed Domains; or a higher-priority rule in the ordered rulebase matched first and granted them a different set. Check the rule order before you rewrite anything — only the highest-priority matching rule applies.