What zero trust means, without the marketing.

For a long time, access was arranged around a boundary. A device inside the office network, or joined to it through a VPN, could reach much of what was on that network; a device outside could reach nothing. The boundary did the deciding.

That arrangement has a weakness that does not depend on any product: whoever gets inside inherits the boundary's trust. A stolen password and a VPN client can reach whatever the network lets that device reach. A contractor let in to fix a particular system can often reach others. A compromised laptop becomes a foothold on the network, not just on the application it was meant to use.

Applications have moved, too. Many now run in clouds and data centres the office network never contained, and people work from networks nobody in the organisation controls. A boundary drawn around the office no longer surrounds what it was meant to protect.

• Being on the network is not a reason to trust. An address inside the office earns nothing by itself. Each access is decided on who is asking, from what device, and for which application.
• Grant applications, not networks. Give each person the applications their work needs and leave the rest out of reach. A stolen credential then opens what that person could open, not the whole network.
• Look at the device, and be honest about what you know. Whether a laptop is encrypted, patched and managed can count in a decision. But a device describes itself, so its report is evidence, not proof.
• Expect something to go wrong, and keep evidence. Record what was allowed and what was refused, in a form that can be checked later, so that an incident can be traced.

Zero trust is not a box you buy, and buying a product does not finish it. It does not stop phishing, patch servers or back up data, and it does not make a device's report about itself true. It describes how access should be decided; the controls that carry it out each have limits, and a buyer should ask about every one.

Each private application is denied unless an access rule allows it, and being in the application's group is not enough on its own. A connector beside the application dials out to the broker and opens no inbound port: the application has no inbound port; the broker's own entry points do.

For a web application, the broker, Pramaan's server, checks the person's sign-in, their groups and your access rules, then relays the request over that app's connector. The device can count too: an access rule can name posture labels, such as unmanaged, and step up or deny a request from a device that carries such a label, or require a minimum score.

A copied access token is a common way around a sign-in. Pramaan binds a token to a key on the person's enrolled device only when the client proves its key as the token is issued, and a copy is refused where the broker checks its key, once binding is switched on.

When someone leaves, deactivating them ends their sessions, their renewal tokens and every access token issued to them, and live sessions of the browser SSH terminal and connections that desktop tools forward are cancelled, not merely refused next time.

When the web edge refuses a request, because of the person's groups or your access rules, the refusal is written as an audit event, and audit events go into a transparency log whose integrity you can check without asking us.

The glossary defines the terms on this page. Zero-trust network access describes Pramaan's connector and direct-connection paths in detail, and the VPN comparison puts the same questions to a VPN.