Zero Trust Architecture: Definition and Use in Compliance

What is Zero Trust Architecture?

Zero Trust Architecture (ZTA) is a security model that operates on a single principle: no user, device, or system gets trusted by default, regardless of where the request originates. Traditional enterprise security drew a hard perimeter around the corporate network. Once inside, users moved freely. ZTA discards that assumption entirely.

The shift matters because the perimeter has dissolved. Employees work remotely. Applications run in the cloud. Third-party vendors connect directly into core banking systems. In that environment, a compromised credential inside the network is as dangerous as an external attack, sometimes more so. The 2016 Bangladesh Bank breach, where attackers moved laterally through SWIFT infrastructure after gaining internal network access, is the clearest example of what happens when internal traffic is implicitly trusted.

ZTA replaces implicit trust with continuous verification. Every access request is authenticated. Every device is assessed for health and compliance posture. Every session is scoped to the minimum privilege required. Identity becomes the new perimeter.

NIST Special Publication 800-207, published in August 2020, defines seven formal tenets of ZTA. These include treating all data sources and computing services as resources, encrypting all communications regardless of network location, granting access on a per-session basis, and continuously monitoring the security posture of all connected assets. That publication is the closest thing to a canonical technical standard the industry has, and it's the reference document most examiners cite when asking about zero trust maturity.

For compliance and security teams, ZTA connects directly to the requirements around operational resilience. The UK PRA and FCA have made clear that firms must identify, manage, and recover from disruptions to critical business services. A zero trust model limits the blast radius of any breach, which directly supports those resilience requirements and can serve as concrete evidence of compliance posture during supervisory reviews.

How is Zero Trust Architecture used in practice?

Implementing ZTA in a financial institution typically starts with identity. Before anything else, the organization needs a reliable way to verify who is making an access request. That means multi-factor authentication across all systems, a centralized identity provider, and device certificates that confirm the machine is managed and current on patches.

From there, most banks move to micro-segmentation. Instead of a flat network where a compromised machine can scan and reach adjacent systems freely, micro-segmentation splits the network into isolated zones. The fraud investigation workbench sits in one zone. The transaction monitoring platform sits in another. Moving from one to the other requires a separate authentication event, not just an open path.

Session-level controls come next. A compliance analyst reviewing a Suspicious Activity Report (SAR) has access to that case file and the associated customer records, not to every case in the queue or every account in the database. That scoping reduces insider threat risk and limits what a compromised session can expose.

Continuous monitoring ties everything together. ZTA is not a one-time authentication event. Session behavior is logged and compared against expected patterns throughout the access window. If a user who normally reviews ten cases per hour suddenly starts bulk-exporting records, the system flags or terminates the session. This behavioral monitoring applies the same logic as behavioral analytics in fraud detection, applied instead to internal access control.

Most banks operate in a hybrid state today: partial ZTA over legacy infrastructure and full ZTA for new cloud workloads. That's acceptable, as long as trust boundaries are explicitly defined and documented. Examiners will ask where the policy enforcement points are and whether they're logging correctly.

Zero Trust Architecture in regulatory context

No single regulation mandates ZTA by name across all financial institutions, but the direction from multiple regulators points clearly toward zero trust principles.

The US federal government's Executive Order 14028 (May 2021) required civilian agencies to adopt ZTA, and the CISA Zero Trust Maturity Model provides a structured roadmap with five pillars: identity, devices, networks, applications and workloads, and data. While this applies directly to federal agencies, it has set baseline expectations that financial regulators have absorbed. OCC and Federal Reserve technology risk examination guidance now routinely references least-privilege access and continuous monitoring, both ZTA outcomes.

In the UK, the FCA and PRA's joint operational resilience policy (PS21/3, March 2021) requires firms to identify their critical business services and set impact tolerances for disruption. ZTA supports this by limiting the lateral movement available to any attacker who compromises a single component. The EBA Guidelines on ICT and Security Risk Management (EBA/GL/2019/04) require financial institutions to apply access management controls on a least-privilege basis and monitor privileged access continuously. Both requirements describe ZTA in all but name.

From an AML perspective, ZTA also supports the controls expected around customer due diligence and enhanced due diligence workflows. If sensitive customer data is accessed under zero trust controls, with every event logged and attributed, the bank can demonstrate to examiners that CDD records haven't been altered and that access was restricted to authorized personnel.

ISO 27001 certification, which many financial institutions pursue, includes access control requirements in Annex A.9 that map closely to ZTA principles. Banks implementing ZTA can use their policy enforcement configurations as direct evidence of compliance with those controls.

Common challenges and how to address them

The most common objection to ZTA is latency. Every access request goes through an authentication and authorization check. In high-throughput environments, like a payment processing system handling thousands of transactions per second, that overhead matters. The typical overhead is 5 to 15 milliseconds per request, depending on implementation. For most compliance and investigative workloads, that's irrelevant. For real-time payment authorization, the architecture needs to be designed with policy engines that cache authorization decisions at the edge rather than re-evaluating from scratch on every transaction.

Legacy systems are harder. Most core banking platforms weren't designed with continuous per-session verification in mind. Retrofitting ZTA onto 30-year-old infrastructure requires a proxy layer that intercepts and authenticates requests on behalf of the legacy application. It works, but it adds complexity and a new dependency that itself needs to be secured and monitored.

Organizational resistance is real too. ZTA reduces the access that privileged users have accumulated over years. IT administrators who previously had broad network visibility find themselves working within tighter boundaries. We've seen banks run into friction when analysts who've browsed freely across systems for a decade suddenly face access controls on data they could previously query without restriction.

The answer is a phased rollout. Start with the most sensitive systems: know your customer (KYC) platforms, AML investigation tools, and data vaults holding personally identifiable information (PII). Demonstrate that performance holds and workflows remain functional. Then expand to lower-sensitivity zones. Trying to re-architect the entire network at once is how ZTA projects stall for two years and get abandoned.

One additional challenge: policy drift. Zero trust policies are written at a point in time, but roles change, applications are added, and legacy exceptions accumulate. Without a regular policy review cycle, a ZTA environment can drift toward implicit trust over time, which defeats the purpose entirely.

Related terms and concepts

ZTA connects to a cluster of security, compliance, and risk management concepts that come up in regulatory examinations and control testing.

Audit trail and chain of custody requirements are directly supported by ZTA's continuous logging. Every access event is recorded with a timestamp, user identity, device identifier, and the resource accessed. That log is the foundation of any forensic investigation following a breach and the primary evidence in a regulatory examination that access controls were functioning as designed.

Third-party risk management (TPRM) overlaps with ZTA in how banks govern vendor access. Under a traditional perimeter model, a vendor connecting to a bank system lands inside the network and can move from there. Under ZTA, that vendor connection is treated with the same skepticism as any external request: scoped to the exact resources needed and monitored throughout the session.

Model risk management (MRM) intersects ZTA where AI systems access production data. As banks deploy AI agents for fraud detection and compliance automation, controlling what those systems can read, write, and execute becomes a ZTA problem. An agent that autonomously queries transaction databases needs the same access controls as a human analyst, including session logging that examiners can review.

Data residency constraints interact with ZTA design in multi-jurisdiction deployments. When a bank operates across geographies with data localization requirements, the zero trust policy engine must know where data lives and enforce access rules that respect those geographic boundaries. Getting this wrong creates GDPR or data sovereignty violations on top of the security exposure.

Finally, operational resilience ties back here directly. ZTA is one of the most concrete technical implementations a firm can point to when regulators ask how the institution limits the impact of a breach on its ability to deliver critical business services within its impact tolerances.