How the Merak zero trust network works

Marketing has worn the phrase “zero trust” down to an attitude. It is not an attitude. It is a set of very specific engineering decisions: who opens the connection, what represents an identity, where the private key lives, at which layer authorisation happens, and what occurs when something fails.

This article takes a zero trust network access (ZTNA) network of the kind Merak builds and pulls it apart into eight mechanisms, one diagram each. If you know roughly how TCP opens a connection and roughly what a certificate is, you have enough to read it. Every term is listed again at the end with a link to its specification.

What problem this is solving

Traditional network security is a perimeter model: put the assets behind a wall, put one door in the wall (a VPN gateway or a firewall), and check people at the door. Whoever passes gets an internal IP address, and from then on what they can reach is decided by subnets and firewall rules — not by who they are.

The weakness is not that the door is flimsy. It is that there is no second decision behind it. Steal one set of working credentials and movement inside the network is close to unimpeded — the technique catalogued as lateral movement, and the stage that turns a single compromised laptop into a breach.

The whole claim of zero trust fits in one sentence: a position on the network is not a reason to trust anything. Making that real starts with separating “can reach” from “is authorised” in the architecture itself.

1. Split deciding from carrying

The first structural decision is plane separation, borrowing the control plane and forwarding plane split from network hardware.

• The control plane handles enrolment, policy, certificate issuance and the authorisation decision for every connection. It decides — and it never touches application data.
• The data plane is a set of interconnected edge nodes forming a mesh that carries the traffic. It moves bytes, and makes no authorisation decisions of its own; it enforces what the control plane synchronised to it.

Two consequences follow directly. First, the vendor is not on the data path — the control plane sees who asked to reach what and when, and nothing of the contents. In cross-border transfer reviews and regulated industries, that distinction usually matters more than any throughput number. Second, there is no central gateway in the data plane, and therefore no single point of failure whose loss disconnects everyone.

All three link types run mutual TLS. Ordinary web TLS authenticates only the server; the client stays anonymous. Mutual TLS requires a certificate from both ends, so the connection itself carries both identities. No hop is plaintext and no hop is anonymous.

2. An identity is a certificate, not a username

In a network like this, every principal — person, device, service, workload — has an identity that is an X.509 certificate.

If PKI is new to you, this is the model to hold: a certificate is a statement that “this public key belongs to this subject”, signed by a trusted issuer with the issuer’s own private key. Check the signature and you know the statement has not been altered. But a certificate is public information. Holding one proves nothing; proving an identity means proving you hold the matching private key.

Which makes the design goal of the enrolment flow singular: the private key must never leave the endpoint, from generation onward.

Step 4 is where it turns. The endpoint generates an asymmetric key pair locally, writes the private key to local storage, and wraps the public key in a certificate signing request (CSR, RFC 2986). The control plane verifies it and signs a certificate chain back.

So: recording the entire enrolment exchange still does not reconstruct the identity — all an observer captured was a public key. That is a categorically different security model from shipping a password or an API key over the wire, where a single weak point in transport or storage hands the credential over intact.

The one-time token in step 1 is typically a short-lived JWT (RFC 7519), usable once, whose only job is to tell the endpoint where to connect and let the control plane recognise this particular enrolment. It is spent the moment it becomes a certificate.

Worth knowing: even if your primary sign-in is OpenID Connect or a password, the client still has to obtain a short-lived certificate before it can reach an edge node — the data plane insists on mutual TLS end to end, and without a certificate there is no connection to make. How a human authenticates and what carries the connection’s identity are two separate things.

3. Why encrypt twice

Seeing both “mutual TLS everywhere” and “end-to-end encryption” usually prompts the same question: isn’t one of those redundant?

No. They protect different things, and they nest.

• The transport layer is per hop. Client to node A is one segment; node A to node B is another, with its own keys. It answers “who is on the other end of this hop, and can anyone else hear it”.
• The application data layer is end to end. The payload is sealed at the source with authenticated encryption (AEAD, RFC 5116), and only the two endpoints hold that key. In practice that means an algorithm such as ChaCha20-Poly1305 (RFC 8439) that provides confidentiality and integrity together — “authenticated” meaning that a single flipped bit makes decryption fail outright rather than produce garbage.

The consequence is blunt: a relay node forwards ciphertext it cannot open. For the confidentiality of the payload, the data plane is an untrusted component; take a whole node and you still hold ciphertext.

Where the end-to-end boundary actually sits depends on how the application connects. Embed the encryption boundary in the application itself and it runs application to application. When a legacy system cannot be modified and a local proxy takes over instead, the boundary runs proxy to proxy — still covering the entire network path, with the short local hop from proxy to application outside it. That is a trade-off worth stating explicitly during a rollout rather than discovering later.

4. Every connection asks again

A valid certificate completes authentication — who you are. It says nothing about authorisation — what you may do. Conflating the two is where a great many access control designs go wrong.

Each time someone opens a new connection to a service, four checks run in order:

What matters is the granularity and the timing. Granularity is a single service rather than a subnet; timing is every connection rather than every login. Together they are the principle of least privilege implemented at the network layer: compromise an endpoint and the attacker reaches only the services that identity was already authorised for. The unreachable boxes on the right of Figure 01 stay unreachable for them too.

A trap worth designing around: multiple policies granting the same service are usually combined as an OR union — one passing policy is enough. Attach both a policy with a posture check and a policy without one to the same identity and service, and the second silently disables the posture check. Nothing errors, because both policies are individually valid. Count the union in whenever you write policy.

5. Passing once is not enough

The fourth gate — the posture check — deserves its own section, because it is one of the few mechanisms that keeps acting after the connection is already up.

Conventional access control checks at the door, so a laptop that was compliant this morning and had something installed on it this afternoon keeps its connection until the user closes it. Continuous evaluation changes exactly that: the moment the endpoint drifts, the existing connection closes — no waiting for the next reconnect.

The common check types look roughly like this:

Multi-factor is the only one with time semantics: you can require verification within the last N seconds, and re-prompt after the device locks or wakes.

The reporting model is worth noting too. Posture reporting is change-driven — the endpoint compares its own state on a cycle and sends a report only when something changed, rather than uploading full state every few seconds. That is what makes it scale, and it also explains why drift detection lands in seconds rather than milliseconds.

6. Why the service cannot be scanned: reverse the direction

This is the least intuitive mechanism in the architecture and the most effective.

Start from a plain fact about opening a TCP connection. For a service to be reachable, it must open an inbound listening port — which is a broadcast to the entire network saying “I am here, and this port will talk to you”. Any open port shows up under a port scan: the scanner sends a SYN, and a SYN-ACK confirms something is there. Version fingerprinting, certificate probing, known-vulnerability matching and login brute force all follow. The first step of the whole attack chain is that answer.

The listener is the attack surface. So the answer a zero trust network gives is: do not have one.

The node hosting the service opens no inbound listener at all. It dials out to the data plane over TCP and, on that already-established connection, registers itself as the terminator for the service. Every authorised request for that service afterwards travels back down the existing channel from an edge node. The service side only ever dialled out, and never accepted an inbound connection from the internet.

From the scanner’s side:

Note the practical weight of the last two rows. Because only outbound needs to be permitted — usually 443, which is generally open already — the service side can deny all inbound. And because the connection is established from the inside out, it traverses NAT and CGNAT naturally. That is why a service can sit in a private range with no public address at all and still be reachable by authorised users: it never needed to be dialled into.

It is worth being precise about what this does and does not stop. It removes the possibility of being scanned and probed at all — the front of the attack chain. It does not make application bugs disappear. When an authorised identity connects, your SQL injection is still a SQL injection.

7. How traffic gets there: cost-based routing and failover

Once legitimate traffic is inside the data plane, one question remains: which way does it go?

The data plane keeps measuring per-link latency, and path selection is cost-based: measured latency, plus the operator-assigned cost of each link, plus the terminator’s own cost and precedence — lowest total wins. Conceptually it is a shortest path problem over a weighted graph whose weights move as conditions change.

When a link fails or congests, routing shifts to an alternative with almost nothing visible to the application above. The contrast with a single-gateway architecture is structural rather than incremental: when the gateway goes, everyone goes — and a mesh data plane has no “everyone”.

8. What this architecture costs you

Any document claiming an architecture has no trade-offs is not worth reading. These belong on the table during evaluation:

• A component has to be deployed on the endpoint or service side. An environment where nothing can be installed, and where no separate host can front the service either, is not a fit.
• Control plane availability is on the critical path. Authorisation decisions depend on it, so its high-availability design belongs in the architecture review rather than in an appendix.
• It does not replace application-level permissions. This machinery decides whether an identity may reach a service. Roles, row-level permissions and audit trails inside that service remain the application’s job.
• Existing network monitoring goes blind. End-to-end encryption means intermediate nodes see nothing, so monitoring and DLP that inspected traffic at a gateway need rethinking — usually by moving visibility to the endpoint or the application.
• The union semantics of policy invite mistakes. The OR-union trap above is the most common misconfiguration once policy counts grow, and it is worth a review process of its own.

Terms and further reading

The diagrams here are simplified for clarity: the full weighting of cost-based routing, posture reporting intervals and the high-availability topology of the control plane are left out, and product documentation is authoritative for actual values and behaviour. If you want to discuss a rollout for a specific environment, or need the fuller technical specification, get in touch.