June 2026 · 15 min read · Architecture & Strategy

Zero Trust Architecture Security Testing: A Practitioner's Guide

Zero Trust is the most over-marketed security concept of the last decade. Vendors slap the label on everything from VPNs to endpoint agents, and organizations declare Zero Trust "complete" after deploying a ZTNA product. Meanwhile, attackers are finding the gaps between the marketing and the implementation.

This guide is about testing whether Zero Trust actually works — not as a vendor compliance exercise, but as a security assessment that looks for the lateral movement paths, implicit trust relationships, and enforcement gaps that survive even well-intentioned ZT implementations.

What Zero Trust Actually Means (for Testing Purposes)

Zero Trust is built on three core tenets from NIST SP 800-207:

• No implicit trust based on network location — being on the corporate LAN grants no inherent access
• Least-privilege access enforced per request — every access decision is evaluated dynamically
• Continuous verification — authentication and authorization are not one-time events

From a testing perspective, this gives you a clear attack surface model: look for places where network location still implies trust, where authorization is evaluated once at login rather than per-request, and where session state is maintained without continuous verification.

Common Implementation Failures

Before diving into techniques, it helps to know what you're looking for. Most Zero Trust implementations fail in predictable ways:

1. Network-Based Implicit Trust Surviving on Legacy Systems

The new ZTNA proxy covers cloud-hosted applications. The on-premise ERP system, still accessed via VPN subnet, has firewall rules that grant access based on IP ranges. The attacker who pivots to any host in that range bypasses the entire ZT control plane.

2. Service Account Exemptions

Service accounts, build pipelines, and scheduled jobs are frequently exempted from MFA and device posture requirements because they're "non-human." These exemptions often have overly broad scopes and become the preferred lateral movement path after initial compromise.

3. Overly Permissive Conditional Access Policies

Identity providers like Entra ID and Okta support granular conditional access, but policies are often written with too many "trusted locations" or device exclusions added over time to fix legitimate user friction. The accumulation of exceptions hollows out the policy.

4. Authorization Evaluated Only at Session Creation

The ZTNA proxy checks device posture and identity at the time of connection. Four hours later, the device has become non-compliant (failed a security update), but the existing session is not re-evaluated. The attacker who compromises that device mid-session inherits the session's permissions.

5. East-West Traffic Blind Spots

Zero Trust controls typically focus on north-south traffic (user to application). Service-to-service communication inside the environment is often trusted implicitly — mTLS is required in policy documents but implemented inconsistently, or not enforced at the application layer.

Phase 1: Identity and Authentication Testing

MFA Bypass Testing

MFA is the foundation of Zero Trust identity. Common bypass paths:

• Real-time phishing (adversary-in-the-middle) — Tools like Evilginx proxy authentication sessions, capturing session tokens after the user completes MFA. The attacker replays the session token, bypassing MFA entirely.
• MFA fatigue attacks — Push notification MFA is vulnerable to repeated authentication requests. Some users approve the notification to stop the noise.
• Legacy protocol authentication — If the IdP allows authentication via SMTP AUTH, IMAP, or other legacy protocols that predate MFA support, attackers can authenticate with credentials alone. Check Exchange Online, Google Workspace, and cloud storage for legacy protocol availability.
• Device trust shortcuts — Some configurations allow "trusted device" to bypass MFA. Test whether device registration can be abused to register attacker-controlled devices.

# Check for legacy authentication in Entra ID sign-in logs
# Look for: ClientAppUsed = "IMAP4", "POP3", "SMTP", "OtherClients"
# PowerShell: requires GlobalReader or SecurityReader role
Get-MgAuditLogSignIn -Filter "clientAppUsed ne 'Browser' and clientAppUsed ne 'Mobile Apps and Desktop clients'" |
    Select-Object UserPrincipalName, ClientAppUsed, AppDisplayName, Status

# Check conditional access policy coverage
Get-MgIdentityConditionalAccessPolicy | Where-Object {$_.State -eq "enabled"} |
    Select-Object DisplayName, @{N="Conditions";E={$_.Conditions | ConvertTo-Json -Depth 3}}

Token Lifetime and Session Testing

Zero Trust requires continuous verification, but OAuth tokens and SAML assertions have finite lifetimes. Test:

• Access token lifetime (should be short, typically 1 hour or less)
• Refresh token lifetime and whether revocation propagates to all clients
• Whether device compliance re-evaluation is triggered during long sessions
• Token caching behavior — do applications cache tokens beyond their stated lifetime?

# Decode and inspect a JWT access token
# (token captured from browser dev tools or intercepting proxy)
import jwt, json

token = "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9..."

# Decode without verification to inspect claims
decoded = jwt.decode(token, options={"verify_signature": False})
print(json.dumps(decoded, indent=2))

# Key fields to check:
# "exp" - expiration time
# "nbf" - not before time
# "scp" or "scope" - granted scopes
# "roles" - application roles
# "amr" - authentication method references (should include "mfa")
# "acr" - authentication context class reference

Conditional Access Policy Evaluation

Map every conditional access policy and then enumerate exceptions. For each exception, ask: what is the realistic threat scenario this exception enables?

Phase 2: Network Segmentation Testing

Verifying Micro-Segmentation

Zero Trust promises that network location implies no privilege. Test this directly from multiple vantage points:

# From a compromised host (assumed breach scenario)
# Map accessible hosts and services from current network position

# TCP port scan of adjacent subnets (requires nmap)
nmap -sT -p 22,80,443,3389,5432,6379,8080,8443,9200 \
     --open 10.0.0.0/16 \
     -oN zt_lateral_scan.txt

# Attempt to reach management plane (should be blocked in ZT)
# Test: can this workstation reach the vSphere API? Kubernetes API? AWS metadata?
curl -m 5 http://169.254.169.254/latest/meta-data/  # AWS metadata
curl -m 5 https://kubernetes.default.svc/api/v1/  # K8s API server
curl -m 5 https://vcenter.internal/sdk  # vSphere

# Check for unrestricted DNS (should not be able to resolve internal management systems)
nslookup vcenter.internal
nslookup admin.internal

Testing Service-to-Service Authentication

East-west traffic is where ZT implementations most commonly fail. From a compromised service identity:

• Can you call other internal APIs without presenting a service identity credential?
• Does the service mesh enforce mTLS, or is it advisory only?
• Are service-to-service calls authorized at the application layer, or trusted based on source IP?
• Can you impersonate a higher-privileged service by spoofing its service account name or certificate CN?

# Test service-to-service authorization (from compromised service pod)
# If mTLS is enforced at the service mesh layer but not the application layer:

# This should fail (no client cert):
curl -k https://payments-service.internal/api/v1/transfer \
     -H "Content-Type: application/json" \
     -d '{"from":"acc1","to":"acc2","amount":1000}'

# But if the application trusts a service account header:
curl -k https://payments-service.internal/api/v1/transfer \
     -H "Content-Type: application/json" \
     -H "X-Service-Account: order-service" \
     -d '{"from":"acc1","to":"acc2","amount":1000}'

# Also test: can workload identity tokens be obtained from metadata service?
# AWS: Instance profile credentials via metadata
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# GCP: Workload identity via metadata
curl -H "Metadata-Flavor: Google" \
     http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

ZTNA Proxy Bypass Testing

Zero Trust Network Access proxies are the enforcement point for application access. Test the proxy itself:

• Direct access attempts — is the application accessible directly (bypassing the proxy) from any network path?
• Proxy header manipulation — does the application trust X-Forwarded-For or similar headers injected by an attacker?
• Pre-authentication surfaces — what is exposed before the ZTNA proxy authentication step? Login pages, error messages, or version information may be reachable.
• Certificate pinning and validation — does the proxy enforce strict certificate validation for backend connections, or is it vulnerable to backend impersonation?

Phase 3: Device Posture Testing

Device Compliance Bypass

Device posture checks are a key differentiator between traditional VPN and Zero Trust. But posture checks can often be spoofed:

• Device certificate theft — if device certificates are stored in the OS certificate store without hardware binding, they can be exported and used from attacker-controlled machines
• MDM enrollment bypass — some BYOD scenarios allow device enrollment with minimal validation
• Virtual machine detection circumvention — posture checks that exclude VMs can be bypassed by presenting VM indicators on a physical attacker machine
• Stale posture data — if the last posture check was 8 hours ago, the session may remain valid despite the device failing current compliance requirements

# Check device certificate binding in Windows
# Certificates in Local Machine store (exportable without TPM binding):
certutil -store My

# Test if device cert is TPM-bound (hardware-protected):
# Open Certificate Manager > View certificate > Details >
# Key Usage should include "Key Encipherment" with CSP showing "Microsoft Platform Crypto Provider"
# If CSP shows "Microsoft RSA SChannel Cryptographic Provider", it's software-stored and exportable

# Attempt to export and use device certificate:
# (requires access to cert store as local admin)
$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Subject -like "*device*"}
$cert.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12, "password") |
    Set-Content -Path device.pfx -Encoding Byte

Phase 4: Application Authorization Testing

Even with robust identity and network controls, application-layer authorization failures can undermine Zero Trust completely.

Per-Request Authorization Verification

Zero Trust requires that authorization is evaluated per-request, not just at session creation. Test:

• Revoke a user's access at the IdP mid-session — how quickly does the application stop honoring their requests? (Should be near-immediate with short token lifetimes)
• Change a user's role from administrator to read-only — does the application re-evaluate their existing session's permissions?
• Reduce a service account's scopes — do existing sessions using that service account reflect the reduced scope?

Attribute-Based Access Control Validation

Zero Trust environments often implement ABAC (attribute-based access control), where access decisions are made based on user attributes, device attributes, and resource sensitivity. Test whether these attributes can be manipulated:

# Intercept and modify claims in a JWT
# Using a proxy (e.g., Burp Suite) with JWT Editor extension

# Original token claims:
{
  "sub": "user@company.com",
  "roles": ["reader"],
  "department": "engineering",
  "clearance_level": "standard"
}

# Modified claims (test whether signature validation is enforced):
{
  "sub": "user@company.com",
  "roles": ["admin"],
  "department": "finance",
  "clearance_level": "privileged"
}

# If the application accepts modified JWTs without signature validation:
# alg:none attack — set algorithm to "none" and remove signature
# RS256 to HS256 confusion — sign with the public key as HMAC secret

Phase 5: Monitoring and Detection Gaps

NIST's ZT model requires continuous monitoring. Test the monitoring posture by attempting to perform attack steps and observing whether they're detected:

Log Coverage Assessment

# Check what authentication events are being logged
# For Entra ID — query Microsoft Graph for sign-in logs
GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=status/errorCode eq 0
Authorization: Bearer {access_token}

# For Okta — check system log for authentication events
GET https://your-org.okta.com/api/v1/logs?filter=eventType eq "user.authentication.auth_via_mfa"
Authorization: SSWS {api_token}

# Events that MUST be logged in a ZT environment:
# - Failed MFA attempts
# - Device posture check failures
# - Conditional access policy failures
# - Token refresh with changed device posture
# - Service principal authentication
# - Privileged role activation

Lateral Movement Detectability

Perform controlled lateral movement attempts (within authorized scope) and verify they generate security alerts:

• Pass-the-ticket / pass-the-hash from a compromised workstation
• Service account credential use from an unauthorized host
• Anomalous API calls from a service identity
• Access to resources outside the service's defined blast radius

If these activities don't generate alerts within a defined time window, the ZT monitoring layer is insufficient regardless of how strong the prevention controls are.

Zero Trust Assessment Deliverables

A Zero Trust assessment should produce findings categorized by ZT pillar rather than just vulnerability severity:

Automated Scanning in Zero Trust Environments

Traditional web application scanners struggle in ZT environments because they can't present valid device posture or satisfy MFA requirements. Modern security scanning platforms need to be integrated into the identity fabric — operating with valid service identities, not just network-level access.

When configuring automated scanning in a ZT architecture:

• Register the scanner as a managed device or service principal in the IdP
• Scope the scanner's service account to the minimum access required for assessment
• Ensure scanner traffic is visible to your security monitoring (not treated as trusted internal traffic)
• Validate that the scanner can reach all application surfaces — ZTNA proxies may block scanners that don't present valid device certificates