"Never trust, always verify." It is the one line everyone quotes about Zero Trust — and the part most people stop at.
The problem is that traditional network security assumes the network boundary is the security boundary. Once an attacker is inside the perimeter, they can move laterally to almost anything. Zero Trust Network Access (ZTNA) throws that assumption out: no user, device, or service gets implicit trust, whether they are sitting in the office or connecting from a coffee shop.
If you build or operate services that handle sensitive data, this model is increasingly what your security team is asking for. Here is what it actually means in practice.
The shift: from perimeter to resource
Old model: castle and moat. Hard outer wall, soft interior. Get past the firewall and you are trusted.
Zero Trust model: every request is authenticated, authorized, and continuously evaluated, regardless of where it originates.
That means the unit of security moves from the network to the resource — the application, the API, the database. Access is granted per-request, per-resource, for as long as it is needed.
The components that make it work
A ZTNA implementation is built from a few interacting parts:
| Component | What it does |
|---|---|
| Policy Enforcement Point (PEP) | The gatekeeper. Intercepts every connection request and enforces the decision. |
| Policy Decision Point (PDP) | The brain. Evaluates identity, device posture, and context against policy. |
| Identity provider | Verifies who (or what) is asking — usually via SSO, MFA, or a service identity. |
| Device posture | Checks whether the requesting device is patched, encrypted, and compliant. |
| Continuous evaluation | Re-checks context during the session, not just at login. |
The PEP and PDP split is the key architectural idea: enforcement and decision-making are separate, so policy logic can be updated without touching every service.
Core principles to design around
1. Least privilege access. Users and services get the minimum access needed, for the minimum time needed. Standing access to production databases is exactly the thing ZTNA tries to eliminate.
2. Microsegmentation. Split the network into small, isolated segments. If one segment is compromised, lateral movement is blocked by enforcement points between segments.
3. Assume breach. Design as if an attacker is already inside. That changes your priorities: detection and containment matter as much as prevention.
4. Verify explicitly. Authenticate and authorize every request using all available signals — identity, device health, location, data sensitivity, and behavioural anomalies.
What this means for your services
If you are a developer, ZTNA is not just a security-team concern. Concretely:
- Service-to-service traffic needs identity too. Mutual TLS (mTLS) or signed workload identity should replace "it is on the internal network, so it is fine."
- Secrets should be short-lived. Use workload identity or token exchange instead of long-lived API keys baked into config.
- Health signals need to be exposed. Device posture checks depend on endpoints reporting patch level, disk encryption, and agent status.
- Logs must be attributable. Per-request authentication means you can answer "who accessed this and when" — but only if your services propagate identity context.
Common pitfalls
- Calling a VPN replacement "Zero Trust." Moving the perimeter to a different appliance is not the same as per-request verification.
- Forgetting service accounts. Human-centric identity leaves machine-to-machine traffic as the weak link.
- One-time verification. Checking identity at login and never again misses session hijacking and credential theft.
This explainer is adapted from the technical deep dive on hSECURITIES, which covers implementation methodology and framework selection.
Top comments (0)