LayerV vs Zscaler Private Access (ZPA)
Private Resource Access, Built for Sharing
Zscaler Private Access brokers access to application segments through outbound App Connectors, and access policies decide which users reach which segments. LayerV is narrower: publish one app or API, then give one person or agent an access link with its own expiry and use limit. Revoking that link ends their access without a policy change.
Facts checked October 10, 2026 against each vendor’s documentation.
ZPA is built for users your identity provider can sign in, including contractors you add there, reaching many private applications under central policy. LayerV is built for the share that falls outside it: one app, one recipient, one task, often a contractor, a customer, or an AI agent who is not in your identity provider.
Share one app from the command line
qurl publish http://127.0.0.1:3000
qurl share <CRID>Architectural Difference
ZPA uses outbound App Connectors, application segments, and access policies. It supports Client Connector, browser access for supported web apps, and access policy rules for workloads behind Cloud Connector or Branch Connector. Both approaches can keep origins private.
With LayerV, publish a private HTTP resource and issue access links from the CLI, SDKs, or API. Browser recipients open the link without installing a LayerV client or creating an account. Each link targets the resource it was issued for, with expiry and use limits set for the task, and can be revoked on its own.
A Cryptographic Resource ID (CRID) gives the resource a cryptographic identity independent of its network address. Who can open the resource is a separate choice, made when it is published. A private resource opens only for its publisher’s devices and for the people and devices the publisher allowed, so the CRID of a private resource is safe to send to anyone. A public resource can be opened by anyone who has its CRID. A qURL carries a separate, signed grant for that resource; a compatible opener verifies it before requesting access. LayerV checks authorization before opening the protected origin connection.
LayerV makes the grant of access a link that can travel with the work: a customer preview, a contractor request, or an agent task. A link grants access to whoever holds it and does not tell your app who that is, so retain your app’s sign-in where verified user identity is needed.
Feature Comparison
| Feature | LayerV | Zscaler Private Access (ZPA) |
|---|---|---|
| Origin connection | Outbound connector; no inbound port | Outbound App Connectors; no inbound open ports required |
| What a grant reaches | One published resource per access link | Application segments named in an access policy |
| Recipient setup | A browser, with no LayerV account or client | Client Connector, or Browser Access for supported web apps; both sign in through an identity provider your tenant trusts |
| Lifetime and single use | Set on each link: expiry and use limit | Set by access and timeout policies for web apps; Privileged Remote Access approvals give one user a time window for RDP, SSH, or VNC |
| Revoking one recipient | Revoke that link through the API; other links keep working | Change the access policy or the user’s IdP attributes, which take effect at their next sign-in; for Privileged Remote Access, delete their approval |
| Machine access | Issue and open links with the CLI, SDK, API, or MCP tools | Access policy rules that match Cloud Connector or Branch Connector groups |
| Setup before the first share | Publish the resource with the CLI or a connector | An identity provider set up for ZPA, App Connectors, application segments, and access policies; Browser Access also needs a certificate and CNAME, or Zscaler-managed ones |
Which one to use
Choose LayerV to
Make private app access part of the work itself. Publish once, create a fresh link for the task, and send it to the person or agent who needs it. LayerV combines browser access, developer APIs, and link lifecycle controls without requiring each browser recipient to enroll in a new network.
When Zscaler is the better choice
Choose ZPA when the people who need access are your own users, already in your identity provider, and need standing access to many private applications under one policy. If you already run Zscaler, LayerV can sit beside it for the shares that policy is too heavy for: one app, one outside recipient, one task. ZPA also has paths for outsiders: Browser Access through your IdP, time-limited Privileged Remote Access approvals for RDP, SSH, and VNC, and B2B Federation with partners who run ZPA.
Frequently Asked Questions
What does the LayerV free tier include?
The free tier includes 10 active protected resources, unlimited qURLs per resource, and 10 GiB/month of data transfer (request + response). Contact the team about larger deployments and support requirements.
How do external collaborators use LayerV?
Send an access link to the published web app. The recipient opens it in a browser without a LayerV account or client installation. If the app requires sign-in, the recipient uses that existing login.
Can agents use the same published resource?
Yes. Your service can issue links using the SDK or API, and MCP tools support their documented URL-based workflow. Software opens received links using the supported programmatic flow.
Can LayerV fit alongside an existing Zscaler deployment?
LayerV can serve selected resource-sharing workflows while other applications keep their existing access controls. Start with a resource and a recipient group, then verify routing and application authentication for that path.