Full Zero Trust
Stages 1 and 2 build a strong outer boundary. Stage 3 eliminates the boundary concept entirely — identity is verified continuously at every service, every request, every second. No implicit trust anywhere.
The Core Principle
Stages 1 and 2 create a perimeter and add identity to connections. Zero trust goes further — it assumes the perimeter has already been breached, and verifies every single request independently, regardless of where it originated.
Design as if every network segment is already compromised. No location — internal or external — is implicitly trusted. Verify always.
Authentication is not a one-time gate at connection. Every request carries identity, and every service validates it — at every hop, every time.
Every workload is granted the minimum permissions needed for its function — scoped by identity, time, and context. No standing access.
Every running process — container, function, pod — has a cryptographic identity automatically issued at startup and rotated continuously.
The question is no longer "is this traffic coming from inside the network?" It is "can this specific workload, right now, prove it is authorised to make this specific request?"
entityOS Security Framework — Stage 3
SPIFFE & SPIRE
SPIFFE is the open standard for workload identity. SPIRE is its CNCF-graduated reference implementation. Together they automate the full certificate lifecycle for every running workload — no human involvement required.
spiffe://domain/service/paymentsWhen a container starts, the SPIRE Agent on its node contacts the SPIRE Server. The server attests the node using cloud provider metadata (AWS Instance Identity Document, GCP attestation, etc.).
# SPIRE Server — node attestor config
NodeAttestor "aws_iid" {
plugin_data {
access_key_id = "..."
secret_access_key = "..."
}
}
# Proves: this node is a legitimate AWS EC2 instanceThe SPIRE Agent then attests the workload itself — matching it against registration entries using kernel-level signals: process PID, Kubernetes pod labels, Docker container IDs, or Unix socket UIDs.
# SPIRE — workload registration entry
spire-server entry create \
-spiffeID spiffe://entityos.io/payments \
-parentID spiffe://entityos.io/node/prod-1 \
-selector k8s:ns:payments \
-selector k8s:sa:payments-sa \
-ttl 3600Once attested, the workload receives a SPIFFE Verifiable Identity Document — a short-lived X.509 cert with its SPIFFE ID in the SAN. The agent rotates it automatically before expiry. The workload never manages its own cert.
# Go — fetch SVID via Workload API
client, _ := workloadapi.New(ctx,
workloadapi.WithAddr("unix:///tmp/spire-agent/public/api.sock"))
svid, _ := client.FetchX509SVID(ctx)
# svid.ID = spiffe://entityos.io/payments
# svid.Certificates[0].NotAfter = +1h
# Rotated automatically — no human touchFull Stack Components
Zero trust is not a single product — it is an architecture assembled from several components, each providing a distinct layer of the identity and authorisation stack.
Issues SPIFFE SVIDs to every workload. The identity authority for the entire service mesh.
Istio, Linkerd, or Envoy enforces mTLS between every service using SPIFFE SVIDs automatically.
OPA or OPAL evaluates fine-grained authorisation — what a verified identity is permitted to do.
Every request carries verified identity. Logs, traces, and metrics are tied to real workload identities — not anonymous IPs.
Full Stack Matrix
How the complete Stage 1 + Stage 2 + Stage 3 stack handles the full range of enterprise security scenarios.
| Scenario | Stage 1 (IP) | Stage 2 (mTLS) | Stage 3 (ZT) |
|---|---|---|---|
| Public internet attacker | ✓ Blocked | ✓ No cert | ✓ No SVID |
| Lateral movement (internal) | ✗ Inside range | ✓ No cert | ✓ No SVID + policy |
| Compromised service | ✗ No protection | ✓ Revoke cert | ✓ SVID expires in hours |
| Ephemeral containers / pods | ✗ Dynamic IPs | ⚠ Manual cert issue | ✓ SVID issued at start |
| Multi-cloud workloads | ✗ CIDR sprawl | ⚠ Complex PKI | ✓ SPIFFE ID is portable |
| Thousand-service mesh | ✗ Unmanageable | ⚠ Cert mgmt at scale | ✓ Zero-touch rotation |
| Over-privileged service | ✗ No control | ✗ No control | ✓ Least-privilege policy |
| Stolen credential reuse | ✗ No protection | ⚠ If cert leaked | ✓ SVID expired in hours |
| Audit and compliance | ⚠ IP logs only | ✓ Cert identity in logs | ✓ Full workload identity trail |
Implementation
spiffe://entityos.io).
Foundation
aws_iid for EC2, k8s_psat for Kubernetes, or gcp_iit for GCE. Agents attest nodes before issuing any workload SVIDs.
Agents
Best Practices
The most common failure mode is treating zero trust as a checkbox. These rules keep it a genuine security posture, not an architectural diagram on a slide.
Deploy in permissive mode first. Log all traffic with SPIFFE identity. Measure real access patterns before writing any deny policies. Premature enforcement breaks things and erodes trust in the programme.
SPIRE registration entries define your identity catalogue. Store them in Git, review changes in PRs, deploy via CI/CD. An unreviewed entry is an unreviewed access grant.
A 1-hour SVID limits the window for credential misuse to 60 minutes. A 24-hour SVID is 24× more dangerous. Push for the shortest TTL your automation can reliably renew. Test rotation under load before going live.
Do not share SPIFFE IDs across services or environments. spiffe://entityos.io/prod/payments must be separate from spiffe://entityos.io/staging/payments. Shared identities defeat least-privilege policy.
Every allow and deny decision by your policy engine should be logged with: the caller's SPIFFE ID, the target, the action, the policy that matched, and the timestamp. This is your audit trail. Without it, compliance is theatre.
Under pressure to "just get it working", teams add wildcard selectors or disable attestation checks. This completely defeats workload identity. If attestation is blocking a deployment, fix the attestation — don't bypass it.
Zero trust does not replace network controls and mTLS — it extends them. Without IP boundaries and cert-based auth already working, zero trust has no foundation to build on.
No single vendor product delivers zero trust. It is an architecture that requires SPIRE (identity), a service mesh (enforcement), a policy engine (authorisation), and observability working together.
Starting with allow: * and planning to tighten later means it never gets tightened. Define real policies from day one, even if they are coarse-grained.
If you have never simulated a compromised workload and verified the blast radius is bounded, you don't know if your zero trust posture works. Test it. Schedule it quarterly.
The Complete Stack
Each stage builds on the last. Together they form a layered defence where an attacker must defeat multiple independent controls — network, cryptographic identity, and continuous authorisation policy.
Network boundary control. Deny all, allow known CIDRs. Fast to deploy, immediately effective.
Cryptographic identity for every connection. Both sides prove who they are before data flows.
Automated workload identity, continuous authorisation, and observability at every hop.
Zero trust means no implicit trust anywhere — not from inside the network, not from a service that connected successfully before. Every request is verified against workload identity and authorisation policy. Combined with Stages 1 and 2, an attacker must defeat three independent controls simultaneously: network boundary, cryptographic certificate, and authorisation policy.