Zero trust is not a product. It is an architecture decision.

Every vendor selling a firewall, an endpoint tool, or a SIEM product calls it "zero trust" now. The term has been so thoroughly weaponised by marketing departments that it has become nearly meaningless. Which is a shame, because the actual architectural principle behind zero trust is one of the most important ideas in enterprise security of the last decade.

This article is not a product review. It is an attempt to explain what zero trust actually requires — at an architectural level — and why implementing it correctly is hard enough that most organisations claiming to have done it have not.

What zero trust actually means

The original formulation, from the Forrester research of the early 2010s and Google's BeyondCorp paper from 2014, is this: assume breach. Design your system as if the attacker is already inside your network. Perimeter security — the idea that everything inside the firewall is trusted — is insufficient because the perimeter is always eventually breached.

Zero trust replaces perimeter trust with three principles applied universally:

• Verify explicitly. Every connection — user to service, service to service, system to data — must be authenticated and authorised, every time. Not just at login. Every request.
• Use least-privilege access. Every identity (human or machine) gets exactly the permissions it needs for exactly the task it's performing. Nothing more. Privileges expire.
• Assume breach. Design for the scenario where something is already compromised. Log everything. Segment everything. Minimise blast radius.

That's it. That is zero trust. Everything else is an implementation decision.

Where most implementations fail

The most common failure mode is what we call perimeter replacement: organisations buy a zero trust network access (ZTNA) product, route their user traffic through it, declare victory, and move on. What they've done is replaced one perimeter (the firewall) with another (the ZTNA gateway). The service-to-service traffic inside the cluster still trusts everything. The database connections still use static credentials. The CI/CD pipeline still has root on the cluster.

None of that is zero trust. That is a VPN with better marketing.

There are four layers where zero trust must be implemented before a system can honestly claim the property:

Layer 1: Identity — human and machine

Human identity is the easy part — most organisations have an IdP (Keycloak, Okta, Azure AD) that handles SSO and MFA. The hard part is machine identity. In a typical Kubernetes cluster, services authenticate to each other using one of three mechanisms, in order of how common they are: static API keys in environment variables, shared service account tokens, or nothing at all (the network is trusted).

All three of these are wrong. The correct answer is SPIFFE (Secure Production Identity Framework for Everyone) — a standard for issuing cryptographically verifiable identities to workloads. Under SPIFFE, every pod, every service, every agent gets an SVID (SPIFFE Verifiable Identity Document) — a short-lived X.509 certificate that identifies it to any other service it calls. No static credentials. No shared secrets. The identity is the certificate, and the certificate expires in hours, not years.

Layer 2: Policy — what each identity can do

Authentication answers "who are you?" Policy answers "what are you allowed to do?" These are different problems, and conflating them is one of the most common architectural mistakes.

In AravaliStack, we use Open Policy Agent (OPA) for policy enforcement. Every API call — whether it originates from a human, a service, or an AI agent — passes through an OPA policy check before it executes. The policy is declared in Rego, version-controlled in Git, and reviewed in pull requests before deployment. Policy changes have exactly the same review process as code changes.

The critical property is separation: the policy engine is independent of both the identity provider and the services being protected. This means you can change policy without redeploying services, audit policy independently of application code, and enforce consistent access decisions across heterogeneous services.

Layer 3: Encryption in transit — everywhere, always

This sounds obvious in 2026. It is still not universally implemented. In most production Kubernetes clusters, pod-to-pod traffic is unencrypted. The reasoning is usually "it's inside the cluster, so it's safe." This is exactly the perimeter thinking that zero trust is meant to replace.

The correct implementation is mutual TLS (mTLS) for all service-to-service communication. Every connection is encrypted. Every connection is authenticated in both directions — the client verifies the server's identity and the server verifies the client's. In AravaliStack, this is enforced at the service mesh layer (Istio) — services cannot opt out of mTLS because the mesh enforces it at the sidecar proxy level, not at the application level.

Layer 4: Secrets — dynamic, short-lived, audited

The final layer is secrets management. A system that has verified identities, enforced policies, and encrypted all traffic still fails zero trust if its database passwords are static strings in Kubernetes Secrets (which are base64-encoded, not encrypted, by default).

Zero trust secrets management means:

• No secret lives longer than it needs to. Database credentials are generated on request and expire after the session.
• Every secret access is logged. HashiCorp Vault (which we use) creates an audit trail for every read.
• Secrets are never stored in application configuration. Applications request secrets at runtime from the secrets store.
• Compromised secrets are automatically revoked. When Vault detects anomalous access patterns, it can revoke credentials without human intervention.

What this looks like end to end

Here is the flow for a typical service call in an AravaliStack deployment — a payment processing service calling a transaction history API:

1. The payment service's SPIRE agent issues it an SVID (valid for 1 hour, rotated automatically).
2. The payment service requests a short-lived database credential from Vault (valid for 15 minutes).
3. The service call is routed through the Istio sidecar, which enforces mTLS — both services verify each other's SVIDs.
4. At the receiving service's ingress, OPA evaluates whether the payment service's identity is permitted to call the transaction history endpoint with the requested parameters.
5. The entire flow — identity issuance, policy evaluation, connection, response — is logged to the immutable audit trail.

At no point does any service trust another service because of network position. At no point does any static credential exist that, if leaked, would provide persistent access. At no point does a policy change require a deployment.

The uncomfortable conclusion

Most systems that claim to be zero trust are not. They have an SSO provider and a ZTNA product, and they have done nothing about service-to-service authentication, policy-as-code, mTLS enforcement, or dynamic secrets. These are the hard parts, and they require architectural commitment — not procurement.

Zero trust is not a product. It is the property that emerges when you implement authentication, authorisation, encryption, and secrets management correctly — across every layer, for every identity, on every request. It is genuinely hard to do. It is worth doing. And the fact that a vendor's product claims to deliver it in a checkbox does not make it so.