How often should we validate our zero trust architecture with red teaming?

At minimum once a year, and again after any significant change such as a new identity provider, a segmentation overhaul, or a cloud migration. Financial services firms under DORA or FINMA expectations typically run semi-annual assessments aligned to TIBER-EU. Zero trust configurations drift fast, so a validation from twelve months ago rarely reflects your current exposure.

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

A penetration test checks individual systems for technical vulnerabilities and answers one question: can an attacker get in? A zero trust assessment tests whether your architecture can contain, detect and respond once someone is already inside. It evaluates identity, network, device, application and data controls as one integrated system under coordinated attack, not as isolated components.

Can we validate zero trust internally instead of hiring an external red team?

Internal testing helps with continuous validation, but it cannot replace an independent assessment. Your own team knows the exceptions, the workarounds and the service accounts that bypass controls, which builds in blind spots. External operators approach the architecture the way an attacker does, with no insider assumptions. NIST SP 800-207 and the CISA maturity model both call for independent validation at higher maturity levels.

Field Notes / Zero Trust

Zero trust does not mean zero risk: prove your architecture holds before an attacker does

Most zero trust deployments have never been tested against a real adversary. In a recent validation of a Swiss financial institution, we walked through 4 of 6 controls in 48 hours. Here is how to find your gaps first.

Author: Red Team Partners
Read: 10 MIN READ
Filed: 17 Mar 2026

The finding

Zero trust red teaming shows you whether the architecture you paid for actually stops a determined attacker, before a real one tests it for you. Most deployments never get that proof. They ship the identity-aware proxy, tick the compliance box, and assume the design holds. Under coordinated pressure it usually does not.

In a recent validation of a Swiss financial institution, we walked through 4 of 6 zero trust controls inside 48 hours. The client had spent CHF 2.3M on the architecture. None of the gaps were exotic. They were reasonable configuration decisions that chained into one clean attack path. A red team assessment finds that path first, names the blast radius, and hands you a fix list your board and your regulator can read.

01 The assumption gap

Zero trust is the most funded, least validated security strategy in the enterprise. Organisations pour millions into identity-aware proxies, microsegmentation and continuous verification, then never test whether any of it stops an attacker who ignores the rules.

Gartner projects that only 10% of large enterprises will run a mature, measurable zero trust programme by 2026, up from under 1% in 2023 Gartner 2023 . So roughly 90% of firms claiming zero trust are running partial builds with gaps they have never pressure-tested. The label has become a purchasing decision rather than a security posture.

The principle is sound. NIST SP 800-207 states it cleanly: never trust, always verify NIST SP 800-207 . Every user, device and flow is authenticated before access. The problem sits in the implementation. Every deployment we assess was designed by defenders thinking like defenders. Policy engines follow expected workflows. Segmentation maps follow org charts. Identity checks verify the credentials you issue. An attacker follows none of that. That distance between how your staff behave and how an intruder behaves is where the money leaks out.

02 Promise vs. what we find

Each control works in isolation during the vendor demo. Put six of them under one coordinated attacker and they fail in combination. Here is the gap between the brochure and the report, drawn from what our operators walk through on real engagements.

Control	Vendor promise	What red teams walk through
Identity verification	Only verified users gain access	Token theft, session hijacking and MFA-fatigue attacks bypass identity checks in more than 60% of engagements
Microsegmentation	Lateral movement is impossible	Broad policies and service-account exceptions open traversal paths in most deployments
Least-privilege access	Users reach only what they need	Privilege creep, stale permissions and shared service accounts grant far more than the policy intends
Continuous monitoring	Anomalies are caught instantly	Rules tuned for known patterns miss novel chains; alert fatigue buries the real signal
Device trust	Only compliant devices connect	BYOD exceptions and MDM bypasses undermine posture checks
Encrypted-traffic inspection	All traffic is inspected	Certificate pinning and inspection gaps at scale leave large blind spots

03 A CHF 2.3M architecture, bypassed

You get the clearest picture of a zero trust build when it meets a real adversary. In a recent validation for a Swiss financial institution, we walked through 4 of 6 controls in the first 48 hours. The firm had invested CHF 2.3M in the architecture. The gaps we surfaced would have cost them well past CHF 15M in a live breach.

On paper the stack was textbook. Identity-aware proxy on every application, microsegmentation across data centre and cloud, endpoint detection on every managed device, and a SIEM ingesting logs from every control plane. In practice, four decisions undid it.

None of these were vulnerabilities in the usual sense. Automation needs exceptions. Monitoring tools need open ports. Sessions need workable lifetimes. Every trade-off was defensible on its own. Chained together, they made a CHF 2.3M investment close to irrelevant. The gap between us getting in and anyone noticing is usually measured in days NIST SP 800-207 §7 .

A data centre under a red warning light, standing in for a zero trust architecture failing silently under a coordinated attack. — Four defensible configuration choices, chained into one clean path. No control fired, because nothing looked broken.

04 Five failure modes

Across engagements the same five weaknesses turn up, whatever vendor logo is on the diagram. Knowing them tells you where to point your own testing before we arrive.

Exception creep is first. Every deployment starts strict, then the helpdesk tickets arrive. Legacy apps get carve-outs, executive devices get overrides, service accounts skip MFA because they run batch jobs at 03:00. Within twelve months most builds carry enough exceptions to drive a lorry through. Identity becomes the single point of failure next: zero trust concentrates enormous trust in the identity provider, so a soft Entra ID configuration synced to an on-premises Active Directory with known holes hands an attacker every downstream decision at once.

East-west blind spots are third. Most firms segment north-south traffic and the major zones, then run out of budget before segmenting inside those zones. Breach one zone and the network is flat within it. Fourth, detection gets tuned for the audit rather than the attacker, which produces impressive dashboards and missed intrusions. Fifth, incident response assumes the architecture works: the playbook says the attacker cannot move laterally because of microsegmentation, and has no answer for the day they can.

05 Prove your architecture holds

You do not need a bigger budget to close these gaps. You need someone to find the path first and shut it. A zero trust assessment tests all five pillars of the CISA maturity model, Identity, Devices, Networks, Applications and Workloads, and Data, both on their own and chained together CISA ZTMM v2.0 . Real attackers cross identity, network and application layers in one motion, so a single-pillar test never reveals the route that matters.

The output is architectural. It reaches past a list of technical bugs. You learn whether your controls fail open or fail closed, whether detection catches real technique or only known signatures, and whether response works when several controls fall at once. That evidence lets you justify spend, move budget to the highest risk, and show a regulator validated maturity rather than a deployment certificate. After the Swiss engagement, the firm cleared every gap we walked through in under two weeks, without new headcount. Enterprise-grade security, within reach.

Remediation Log

Domain-admin service account brought inside conditional access, automation reworked to fit
East-west segmentation rules tightened; monitoring ports scoped to named source hosts
Session lifetime cut and bound to device posture, so a stolen token dies on rotation
SIEM detection rebuilt from red team findings, not the audit checklist
Incident response playbook rewritten to assume zero trust controls can fail

If you have invested in zero trust, that investment deserves proof. Not a vendor health check, not a compliance audit. A genuine adversarial assessment that finds the exceptions, chains the weaknesses, and shows whether your controls hold when it matters. Want to know whether your architecture does what you paid for? Start with a free audit, then a full validation mapped to NIST SP 800-207 and the CISA pillars.

References

Sources

NIST. SP 800-207: Zero Trust Architecture. National Institute of Standards and Technology, 2020. csrc.nist.gov
CISA. Zero Trust Maturity Model v2.0. Cybersecurity and Infrastructure Security Agency, 2023. cisa.gov
Gartner. Predicts 2024: Security Infrastructure (10% mature zero trust by 2026 projection). Gartner, 2023. gartner.com