Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
Zero Trust is the security model codified by NIST SP 800-207: “never trust, always verify.” Instead of granting broad access once a subject is inside a network perimeter (VPN-in, then implicitly trusted), every request — from any user, device, or workload, regardless of network location — is authenticated, authorized, and evaluated against policy before access is granted, and that evaluation is repeated continuously rather than cached for the life of a session.
The model matters because the perimeter it replaces has quietly stopped existing: SaaS apps, remote work, contractor devices, and cloud workloads mean “inside the corporate network” is no longer a meaningful trust signal. Done well, Zero Trust shrinks blast radius — a compromised laptop or stolen token no longer buys an attacker the whole network. Done poorly — as a rebrand of a VPN plus MFA, or a policy engine that is never actually consulted per-request — it buys little beyond a new vocabulary for the same flat network.
Attack Prerequisites
Zero Trust is not unbreakable; assessors and real attackers defeat specific implementations. The following conditions typically have to hold:
- A segment or legacy system excluded from enforcement — a Zero Trust rollout that still has a flat, unmanaged VLAN, a legacy app that cannot speak to the policy enforcement point, or a site-to-site VPN that bypasses the proxy entirely.
- Coarse-grained policy — the Policy Decision Point authorizes at the level of “authenticated + on a managed device” rather than per-resource, so any valid session can reach far more than it needs.
- Long-lived trust decisions — a token or session that, once issued, is not re-evaluated against current device posture or risk signals for its full lifetime, so a device that goes non-compliant mid-session keeps access.
- A device or identity that passes posture checks while compromised — e.g. malware that does not trip EDR, or valid credentials phished with a session token that satisfies MFA already having occurred.
How It Works
NIST SP 800-207 defines the logical components of a Zero Trust Architecture: a Policy Engine (PE) that computes a trust decision from signals (identity, device posture, behavioral analytics, threat intelligence), a Policy Administrator (PA) that establishes or tears down the communication path based on that decision, and a Policy Enforcement Point (PEP) that sits in the data path and actually allows or blocks the connection. PE and PA together form the Policy Decision Point (PDP). Every access request — a user hitting an internal app, a workload calling an API — is expected to traverse a PEP that consults the PDP, rather than being implicitly trusted because it originated on the internal network.
In practice this is implemented as an identity-aware proxy or access broker (the BeyondCorp pattern), a service mesh with mutual TLS and per-service authorization policies (e.g. Istio/SPIFFE workload identity), or a SASE/ZTNA product that brokers every connection from client agent to application. Trust is continuously re-evaluated: device compliance state, user risk score, location, and time can all change the outcome of the next request even within an existing session — this continuous evaluation, not just strong initial authentication, is what distinguishes Zero Trust from “VPN plus MFA.”
Microsegmentation is the network-layer expression of the same idea: rather than one broad internal zone, each workload or group of workloads gets an explicit allow-list of what it may talk to, enforced by host-based firewalls, mesh sidecars, or cloud security groups, so lateral movement after an initial compromise is constrained by policy rather than by the attacker’s imagination.
Practical Example / Configuration
A common gap is a Policy Decision Point that only checks identity and ignores device posture, which is exactly the control Zero Trust is supposed to add on top of ordinary authentication. Here is a permissive Open Policy Agent (OPA) Rego policy fronting an internal app through an identity-aware proxy — it authorizes on group membership alone:
package authz
# VULNERABLE: any authenticated member of "engineering" is allowed,
# regardless of device compliance, MFA freshness, or session risk.
default allow = false
allow {
input.user.authenticated == true
input.user.groups[_] == "engineering"
}
A policy that actually implements continuous, risk-aware evaluation checks device posture and session freshness on every request, not just group membership at login time:
package authz
default allow = false
allow {
input.user.authenticated == true
input.user.groups[_] == "engineering"
input.device.managed == true
input.device.compliant == true
input.session.mfa_age_seconds < 3600
input.risk_score < 50
}
Walkthrough / Exploitation
Assessing a Zero Trust deployment typically means proving that the control plane, not just the marketing name, actually gates access. Start by mapping which paths reach an application:
# Look for a path that skips the proxy/PEP entirely:
# - direct IP/hostname access from an on-prem segment
# - a legacy site-to-site VPN or a bastion excluded from the mesh
nmap -Pn -p 22,80,443,3389 10.10.0.0/16 --open
Next, test whether posture is actually re-evaluated rather than cached in the session token. Authenticate from a compliant device, capture the session token, then replay it from a non-compliant client (missing EDR agent, jailbroken/rooted, or simply a curl request outside the managed client):
curl -H "Cookie: zt_session=<captured-token>" \
-H "User-Agent: curl/8.0" \
https://internal-app.corp.example/api/reports
# If this succeeds, device posture is checked at login only,
# not per-request -- the PDP is not actually in the data path.
Finally, test microsegmentation from a workload that should only reach one peer: attempt lateral connections to unrelated services and confirm they are denied by policy rather than merely unadvertised.
Note: “Zero Trust” is frequently used to describe a VPN concentrator with MFA bolted on — that is not the model. The defining property is per-request, continuously re-evaluated authorization at a PEP, with no implicit trust granted by network location. If removing the VPN client and connecting from an arbitrary network changes nothing about the authorization decision, the deployment qualifies; if it does, it is still a perimeter model.
Opsec: When assessing production Zero Trust controls, coordinate destructive or noisy tests (posture bypass replay, lateral movement probes) with the blue team in advance — a real ZTNA/PDP stack should generate policy-denial telemetry for every one of these attempts, and an assessment is also a chance to confirm that telemetry actually fires.
Detection and Defense
Hardening a Zero Trust rollout is mostly about closing the gaps between the model on paper and the enforcement in the data path:
- Inventory every access path to each application and confirm all of them traverse a PEP — legacy VPNs and unmanaged segments are the most common bypass.
- Re-evaluate posture and risk per request or on a short interval, not only at initial authentication; revoke access immediately on a compliance state change.
- Write resource-level, attribute-based policy rather than broad group membership, and version-control policy (policy-as-code) so changes are reviewed.
- Log every PDP decision, allow and deny, with the signals that drove it, and alert on policy-denial spikes and PEP bypass attempts.
- Microsegment workloads with mutual TLS and explicit allow-lists (service mesh or host firewall) so a single compromised host cannot reach the whole environment.
Real-World Impact
Google’s internal BeyondCorp program, published starting in 2014, is the reference implementation that popularized the model after the Aurora intrusion demonstrated the limits of perimeter trust, and NIST SP 800-207 (2020) formalized the vocabulary that vendors and US federal guidance (including the 2021 Executive Order on cybersecurity and CISA’s Zero Trust Maturity Model) now build on. In practice, organizations that implement Zero Trust as continuous, resource-level enforcement measurably reduce lateral movement in incidents; organizations that implement it as a rebrand see little change in outcomes when a credential or device is compromised.
Conclusion
Zero Trust is a control-plane discipline, not a product category: identity, device posture, and policy have to be evaluated continuously and enforced at every access path, not just at the login screen. The pitfalls are almost always gaps between that model and the actual data path — legacy exclusions, coarse policy, and cached trust decisions — which is exactly what an assessment should be built to find.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments