Zero Trust is not a particular set of products, nor a fixed list of rules. It is an approach that says where and when the decision is made about who gets access to what. The classic model made that decision at the network edge: get inside the perimeter and you count as trusted. Zero Trust requires deciding afresh on every request, granting the minimum of privileges and for a single session, taking device state and context into account.
NIST SP 800-207 splits the architecture into three roles: the decision point (policy engine and policy administrator), the enforcement point next to the resource, and the data sources they draw on. In January 2026 the NSA published its Zero Trust Implementation Guidelines — a primer, a discovery phase and two implementation phases; what they put front and centre is a cryptographically verifiable device identity, not an address and not a hostname.
That yields a working question to ask of any layer of an estate: where is the decision made, where is it enforced — and what happens in between when connectivity drops. Below are four layers of a Linux estate: what each one answers, and where its answer ends.
Layer 1. Network and access to the resource
Micro-segmentation and access brokers (ZTNA, identity-aware proxies) remove the perimeter’s central assumption. A connection to a service is granted not by the route “I am on the office network” but by a broker’s decision, informed by the user, their device and the resource requested. On Linux this layer is assembled from overlay network agents, eBPF policies between pods, and proxies in front of administrative interfaces.
What it covers: lateral movement inside the network, and access to services by the mere fact of network reachability.
Where it ends: the broker delivers the engineer to the host and stops there. What happens once the session is established — which account the person signed in as, what privileges they got — is outside its remit. Behind a flawlessly configured ZTNA perimeter you will usually find a service account whose password the whole shift knows.
Layer 2. Service to service
This is where Zero Trust has reached maturity. Mutual TLS gives both sides a verifiable identity, SPIFFE and SPIRE describe how to issue it to the services themselves, automatically and short-lived, and a service mesh applies policy to every call. A certificate lives for hours, rotation happens without a human, and revocation amounts to not issuing the next one.
What it covers: trust between processes stops resting on network addresses.
Where it ends: the model describes services, not people. An engineer connecting to a machine by hand does not fit into it — they have neither such an identity nor an agent that will mint them a certificate in a millisecond. The split between “services authenticate with cryptography” and “people authenticate with a password” runs exactly along this boundary.
Layer 3. A person signing in to a host
This layer has the most solutions — three families of them:
An SSH certificate authority. Instead of distributing public keys across hosts, a central authority signs short-lived certificates: the engineer gets one valid for a few hours, and the host verifies the signature locally. Revocation comes from expiry, with no need to walk the fleet. The weak spot: the certificate is issued by contacting the authority, so the authority has to be reachable when work begins.
Bastions and privileged access management. The session runs through an intermediary that records the screen, logs commands and checks out a password for a limited time. It gives you a recoverable picture of the work and control over who connected and when. The weak spot: there is still a password on the host itself — it now lives in a vault rather than in the engineer’s head. A local sign-in at the keyboard is invisible to the bastion entirely.
A directory. LDAP, Active Directory or FreeIPA plus SSSD give personal accounts, single-point revocation and group policy. In spirit this is a step towards Zero Trust: access is tied to a person rather than a shared account. The weak spot: sign-in depends on reaching a domain controller. If the account is not in the cache, you cannot sign in without the directory. And an account that is in the cache will keep letting its holder in after it has been disabled centrally.
The common denominator of all three: the decision is made at the centre, enforced on the device, and a network sits in between.
Layer 4. Privileges inside the operating system
Zero Trust does not end at sign-in: least privilege requires that whoever signed in gets exactly what the work needs. Linux ships the toolkit for that — groups and filesystem permissions, sudoers, mandatory access control (SELinux, AppArmor, PARSEC in Astra Linux), namespaces and capabilities, the audit subsystem.
What it covers: privileges stop being the binary “ordinary user or root”.
Where it ends: the configuration is static. It was right on the day it was set up, and a year later the devices carry whatever has accumulated — a group granted temporarily, a forgotten sudoers rule, the account of a contractor who left long ago. Zero Trust assumes continuous re-evaluation, and here re-evaluation usually means a person with a laptop and the getent command.
What it adds up to
| Zero Trust principle | What covers it on Linux | What stays open |
|---|---|---|
| A decision per request | Access broker, service mesh | A local sign-in to the OS is not covered by any decision |
| Verifiable identity | mTLS and SPIFFE for services, a directory for people | A person’s identity is verified by the centre, not by the device |
| Per-session, short-lived access | Short-lived SSH certificates, rotation in the mesh | Requires reaching the centre at the moment of issuance |
| Least privilege | sudoers, mandatory access control, capabilities | Configuration drifts, with nothing to compare it against |
| Continuous verification | Telemetry, device posture | On a disconnected device there is nobody to read the telemetry |
The right-hand column adds up to a single gap. The access decision lives at the centre, enforcement happens on the device, and the whole construction rests on the channel between them. While the channel is up, the scheme works. When it is not — and it is not, for remote nodes, industrial rigs, ATMs and equipment in distant branches — you are left choosing between two bad options: let people in from a cache and lose revocation, or refuse everyone and halt service.
The decision inside the credential
The way out of that fork is to stop sending the decision over the network at sign-in time. It is made in advance, at issuance, and written into the credential itself: who the person is, which role is open to them, on which devices it applies, and until what date. The credential is signed, lives on a hardware token the engineer carries, and is presented to the device directly.
The decision point does not disappear — it is separated in time: policy is expressed centrally at issuance, and verification runs on the device at sign-in against the signature, the validity period, the scope and the revocation list. Connectivity is needed to manage the fleet, not to open the door.
This is how Tessera Access works. The engineer inserts the token and enters a PIN, the device sends a random challenge and verifies the signature made with the private key — there is no password in the scheme at all, so there is nothing to shoulder-surf, phish or brute-force. The role, the binding to a device or group, and the validity period all live in the credential; delegation from one holder to another can only narrow the privileges, never widen them. Access ends through a short validity period and a revocation list — a specific credential is revoked, with no password changes across the fleet. Every sign-in, sign-out and role action is written to a log on the device itself, and the issuance journal is kept as a chained record, so after-the-fact edits to history are visible.
The fourth layer — privileges after sign-in — is covered by Census: role accounts, groups, sudoers and systemd limits are described by a signed declaration, and the tool shows how a device’s actual state diverges from it and brings the device back in line. Least privilege stops being a one-off setup and becomes a verifiable state — which is what continuous re-evaluation asks for.
Regulated environments
Where compliance is in play, the map above translates fairly directly. PCI DSS 4.0 requires a unique ID per person, multi-factor authentication for all access into the cardholder data environment, and a tamper-evident audit trail — the same demands as Zero Trust, phrased for an assessor; we walked through that in the article on PCI DSS on ATMs. Russia’s GOST R 57580.1 asks for the same things again in its access management process, down to keeping a reference set of granted privileges and reconciling actual privileges against it. A security tool supports the implementation of such measures; compliance is demonstrated by the organisation.
Where to start
Pick the order of layers by where trust is currently granted without verification. If your machines are permanently connected to the centre, the first two layers pay off faster: an access broker and service identity give quick results. If the estate is distributed and connectivity is intermittent, start from the bottom — with how a person signs in to a device and what privileges they find there — because on such an estate the upper layers do not always work.
Test any layer with the same question: what does this scheme do when the channel to the centre is gone. The answer “it lets people in from a cache” and the answer “it lets nobody in” mean the same thing — that the access decision still sits outside the device.
If you run a distributed Linux estate and are fitting Zero Trust to it, write to us: we will walk your setup layer by layer and show token-based sign-in on a test bench.