Zero Trust Doesn't Mean Zero Risk: Why You Need Red Teaming to Validate Your Zero Trust Architecture

Zero trust is the most overfunded, under-validated security strategy in enterprise IT. Organisations are pouring millions into identity-aware proxies, microsegmentation, and continuous verification, then never testing whether any of it actually stops a determined attacker. They deploy the architecture, check the compliance box, and sleep well at night. They shouldn't.

Gartner projects that only 10% of large enterprises will have a mature, measurable zero trust programme by 2026, up from less than 1% in 2023. That means 90% of organisations claiming "zero trust" are running partial implementations with critical gaps they have never pressure-tested. The label has become a purchasing strategy, not a security posture.

The Zero Trust Assumption Gap

Zero trust, as defined by NIST SP 800-207, rests on a clean principle: never trust, always verify. Every user, device, and network flow must be authenticated and authorised before access is granted. No implicit trust zones. No perimeter-equals-safety thinking.

The problem is not the principle. The problem is the implementation.

Every zero trust deployment we have assessed has the same structural weakness: it was designed by defenders thinking like defenders. Policy engines get configured based on expected workflows. Microsegmentation maps follow org charts and application dependencies. Identity verification checks the credentials the organisation issues. None of this accounts for an attacker who does not follow your workflows, does not respect your segments, and does not use your credentials the way you intended.

This is the assumption gap. Your zero trust architecture is built on a model of how legitimate users behave. Attackers operate outside that model entirely.

What Zero Trust Promises vs. What Red Teams Find

Zero Trust Control	Vendor Promise	What Red Teams Actually Find
Identity Verification	Only verified users gain access	Token theft, session hijacking, and MFA fatigue attacks bypass identity checks in 60%+ of engagements
Microsegmentation	Lateral movement is impossible	Misconfigurations, overly broad policies, and service account exceptions create traversal paths in most deployments
Least-Privilege Access	Users only access what they need	Privilege creep, stale permissions, and shared service accounts grant far more access than policies intend
Continuous Monitoring	Anomalous behaviour is detected instantly	Detection rules tuned for known patterns miss novel attack chains; alert fatigue causes real threats to be ignored
Device Trust	Only compliant devices connect	BYOD exceptions, MDM bypasses, and compromised managed devices undermine device posture checks
Encrypted Traffic Inspection	All traffic is inspected for threats	Certificate pinning, inspection gaps at scale, and performance trade-offs leave significant blind spots

The pattern is consistent: each control works in isolation during vendor demos. Under coordinated adversarial pressure, they fail in combination.

A CHF 2.3M Architecture, 48 Hours to Bypass

In a recent zero trust validation for a Swiss financial institution, we bypassed 4 of 6 zero trust controls within the first 48 hours. The client had invested CHF 2.3M in their zero trust architecture. The gaps we found would have cost them CHF 15M+ in a real breach.

Here is what happened.

The organisation had deployed a textbook zero trust stack: identity-aware proxy for all application access, microsegmentation across their data centre and cloud environments, endpoint detection and response on every managed device, and a SIEM ingesting logs from every control plane. On paper, it looked solid. In practice, we found:

• Service account with domain admin privileges excluded from conditional access policies because "it broke automation." This single exception gave us unrestricted lateral movement.
• Microsegmentation rules that allowed east-west traffic on ports used by legitimate monitoring tools. We tunnelled through these allowed paths.
• Session tokens with 24-hour lifetimes and no binding to device posture. One stolen token from a phishing simulation gave us persistent access that survived credential rotation.
• SIEM detection rules that triggered on known attack signatures but missed our custom tooling entirely. We operated undetected for the full 48-hour window.

None of these were exotic vulnerabilities. They were configuration decisions made by competent engineers under real-world constraints. Automation needs exceptions. Monitoring tools need open ports. Sessions need reasonable lifetimes. Every one of these trade-offs was defensible in isolation. Together, they created an attack path that made the CHF 2.3M investment largely irrelevant.

Why Zero Trust Architectures Need Adversarial Validation

Zero trust red teaming is the practice of subjecting a zero trust architecture to realistic adversarial attack scenarios to identify gaps between intended security posture and actual resilience. Unlike standard penetration testing, which typically targets individual systems or applications, zero trust red teaming evaluates how the entire architecture performs as an integrated defence system under coordinated attack. This includes testing identity controls, network segmentation, access policies, detection capabilities, and incident response in combination, not in isolation. The methodology draws from frameworks like NIST SP 800-207 and the CISA Zero Trust Maturity Model to structure attack scenarios against each architectural pillar. Organisations that conduct zero trust red teaming gain empirical evidence of whether their architecture delivers the protection it was designed to provide, including specific metrics on detection time, containment effectiveness, and policy bypass rates that drive measurable security improvements.

Compliance frameworks are starting to demand this. The CISA Zero Trust Maturity Model defines five pillars (Identity, Devices, Networks, Applications and Workloads, Data) across four maturity levels. Reaching "Advanced" or "Optimal" maturity on any pillar requires demonstrated validation, not just deployment. NIST SP 800-207 Section 7 explicitly addresses threats to zero trust architecture, including insider threats, stolen credentials, and denial-of-service against policy enforcement points. If your zero trust deployment has not been tested against these specific threats, you are not aligned with the framework you claim to follow.

The Five Failure Modes We See Repeatedly

1. Exception Creep

Every zero trust deployment starts strict. Then the helpdesk tickets start rolling in. Legacy applications that cannot handle modern authentication get exceptions. Executive devices that "need" broader access get policy overrides. Service accounts get excluded from MFA because they run batch jobs at 3am. Within 12 months, most deployments have enough exceptions to drive a truck through.

2. Identity as a Single Point of Failure

Zero trust architectures concentrate enormous trust in the identity provider. If your IdP is compromised, every access decision downstream is compromised. We see organisations that have hardened their network segmentation beautifully but left their Azure AD / Entra ID configuration with default settings, synced to an on-premises Active Directory with known vulnerabilities.

3. East-West Blind Spots

Microsegmentation vendors sell the dream of complete internal traffic control. Reality: most organisations achieve segmentation for north-south traffic and between major zones, then run out of budget or patience before segmenting east-west traffic within those zones. Attackers who breach a single zone find a flat network inside it.

4. Detection Tuned for Compliance, Not Attackers

SIEM rules that satisfy audit requirements and SIEM rules that catch real attackers are two different things. Most detection engineering is driven by compliance checklists, not by threat intelligence or red team findings. The result: impressive dashboards, missed intrusions.

5. Incident Response That Assumes the Architecture Works

IR playbooks built for a zero trust environment often assume the controls will contain the threat. "The attacker can't move laterally because of microsegmentation." What happens when they can? If your IR plan does not account for zero trust control failure, you are planning for the scenario where you do not need an IR plan.

Zero Trust Assessment: A Structured Approach

A zero trust assessment evaluates the effectiveness of an organisation's zero trust architecture through structured adversarial testing against all five CISA Zero Trust Maturity Model pillars: Identity, Devices, Networks, Applications and Workloads, and Data. The assessment maps deployed controls to NIST SP 800-207 tenets, identifies implementation gaps between policy intent and enforcement reality, tests for policy bypass and exception abuse, and validates detection and response capabilities under realistic attack conditions. Each pillar is tested both independently and as part of coordinated multi-pillar attack chains, because real attackers chain weaknesses across identity, network, and application layers simultaneously. The output is a prioritised findings report that distinguishes between architectural weaknesses requiring strategic design changes and configuration gaps that can be remediated within days. This gives security leaders the evidence they need to justify additional investment, reallocate existing budget to the areas of highest risk, and demonstrate validated zero trust maturity to regulators and auditors.

Our zero trust red teaming methodology follows a structured approach across the CISA pillars:

1. Identity Pillar -- Test MFA bypass, token theft, session hijacking, conditional access policy exceptions, and IdP configuration weaknesses.
2. Device Pillar -- Evaluate device trust enforcement, MDM bypass techniques, BYOD policy gaps, and endpoint compliance verification.
3. Network Pillar -- Validate microsegmentation rules, test east-west movement paths, probe for allowed-port tunnelling, and assess DNS/HTTPS inspection coverage.
4. Application Pillar -- Assess application-layer access controls, API authorisation models, service mesh configurations, and AI system access patterns.
5. Data Pillar -- Test data classification enforcement, DLP bypass techniques, encryption-at-rest validation, and data exfiltration paths.

Each pillar is tested independently and then in combination, because attackers chain weaknesses across pillars to achieve objectives that no single-pillar test would reveal.

Zero Trust Penetration Testing vs. Traditional Penetration Testing

Zero trust penetration testing differs from conventional penetration testing in scope, methodology, and objectives. Traditional penetration testing typically focuses on finding vulnerabilities in specific systems, applications, or network segments. It answers the question: "Can an attacker get in?" Zero trust penetration testing asks a fundamentally different question: "Once inside, can the architecture actually contain, detect, and respond to an attacker?" This means testing the policy enforcement points, the policy decision engine, the identity verification chain, and the monitoring pipeline as an integrated system, not as isolated components. It requires testers who understand both offensive security tradecraft and zero trust architectural patterns defined in NIST SP 800-207, because the goal is not just to find technical bugs but to evaluate whether the entire defensive design holds under sustained adversarial pressure. The results reveal whether controls fail open or fail closed, whether detection catches real attack techniques or only known signatures, and whether response procedures work when multiple controls are compromised simultaneously.

The NIST SP 800-207 Threat Model Most Organisations Ignore

Section 7 of NIST SP 800-207 outlines specific threats to zero trust architectures that most implementations fail to address:

• Subversion of the Policy Decision Point (PDP) -- If an attacker compromises the PDP, all access decisions are under their control. How many organisations have red-teamed their policy engine directly?
• Denial of Service against the Policy Enforcement Point (PEP) -- If the PEP goes down, does your architecture fail open (granting all access) or fail closed (blocking all access)? Most organisations do not know because they have never tested it.
• Insider Threats -- Zero trust should limit insider damage through least privilege. In practice, insiders know the exceptions, the workarounds, and the service accounts that bypass controls.
• Stolen Credentials and Insider Misuse -- NIST explicitly warns that zero trust cannot fully mitigate compromised credentials with legitimate access. Your architecture must assume credentials will be stolen and layer additional controls accordingly.

If your zero trust validation does not test against these NIST-defined threat scenarios, it is not a validation. It is a configuration review.

Frequently Asked Questions

How often should we conduct zero trust red teaming assessments?

At minimum, annually and after any significant architectural change (new IdP integration, segmentation policy overhaul, cloud migration). For financial services organisations subject to DORA or FINMA requirements, semi-annual assessments aligned to TIBER-EU or TBEST frameworks are the standard. The threat landscape shifts fast, and zero trust configurations drift faster. An assessment from 12 months ago may not reflect your current exposure.

Can we do zero trust validation internally?

Internal testing has value for continuous validation, but it cannot replace independent external assessment. Internal teams know the architecture, the exceptions, and the workarounds, which means they carry implicit bias about what is and is not exploitable. External red teams approach the architecture the way an attacker does: with no insider knowledge and no assumptions about what should work. NIST SP 800-207 and the CISA maturity model both emphasise independent validation for higher maturity levels.

What is the difference between a zero trust assessment and a regular penetration test?

A standard penetration test evaluates individual systems for technical vulnerabilities. A zero trust assessment evaluates the entire architecture as an integrated defence system. This means testing how identity, network, device, application, and data controls work together under adversarial conditions, not just whether individual components have patched CVEs. The output is architectural, not just technical: it tells you whether your design holds, not just whether your patches are current.

Does zero trust replace the need for network security?

No. Zero trust shifts the trust model from network-centric to identity-centric, but network controls remain a critical layer. Microsegmentation, encrypted transport, and network monitoring are all zero trust components. The mistake is thinking zero trust eliminates the need for network security. It actually increases the demand for precise, policy-driven network controls that work in concert with identity and device trust.

What This Means for Your Architecture

Zero trust is the right strategic direction. The principle of "never trust, always verify" is sound. But the gap between principle and implementation is where attackers live, and that gap only becomes visible under adversarial pressure.

If you have invested in zero trust, that investment deserves validation. Not a vendor health check. Not a compliance audit. A genuine adversarial assessment that tests your architecture the way a real threat actor would test it: by finding the exceptions, chaining the weaknesses, and proving whether your controls hold when it matters.

We run zero trust red teaming engagements for organisations across Switzerland and Europe, testing against NIST SP 800-207 threat models, CISA maturity pillars, and real-world attack techniques. If you want to know whether your zero trust architecture does what you paid for, talk to our team.

References

• NIST, "SP 800-207: Zero Trust Architecture," 2020
• CISA, "Zero Trust Maturity Model v2.0," 2023
• Gartner, "Predicts 2024: Security Infrastructure," 2023 (10% mature zero trust by 2026 projection)
• NIST, "AI Risk Management Framework (AI RMF 1.0)," 2023
• European Commission, "NIS2 Directive Implementation Guidance," 2025
• RedTeam Partners Switzerland: Zero Trust Validation
• Cyber Security Switzerland: Zero Trust Architecture Encyclopedia