The Architecture in One Diagram
Before decomposing the components, the diagram below maps the complete Zero Trust architecture as it applies to a banking environment. Four functional layers. Four segmentation zones. One feedback loop. Every vendor product you will encounter sits somewhere inside this structure.
Zero Trust architecture in a banking environment — identity and policy plane, microsegmentation zones, and continuous monitoring plane. Based on NIST SP 800-207.
The Three Planes: Identity, Policy, and Data
Every Zero Trust architecture operates across three functional planes. Understanding the separation is what distinguishes a genuine ZT architecture from a product marketing claim.
The Identity and Policy Plane is the decision layer. It answers one question: should this subject, on this device, in this context, at this moment, be permitted to access this resource? The policy engine receives signals — identity assertion, device health, session context, threat intelligence — and makes a binary decision. The policy enforcement point executes that decision at the resource boundary. This plane must function before any data access occurs. It cannot be bypassed.
The Data Plane is where actual work happens — where the user runs the application, where the application queries the database, where the transaction processes. In a perimeter model, the data plane was implicitly trusted once a subject was inside the network. In Zero Trust, the data plane has no implicit trust. Access to each resource requires a fresh decision from the policy engine. A user with legitimate access to the payment application has no implied access to the transaction database — even if both systems sit in the same data centre.
The Monitoring Plane is what makes "assume breach" operational rather than aspirational. It collects signals from the data plane — who accessed what, when, from where, how — and feeds those signals back to the policy engine as dynamic risk scores. A user whose behaviour deviates from their established baseline generates a risk signal. The policy engine receives that signal. Access is adjusted in real time. Without the monitoring plane, the policy engine is making decisions with incomplete information. The feedback loop is the architecture.
The most common architecture mistake: buying a ZTNA product (which handles the policy enforcement point) without building the policy engine or the monitoring plane. A gate with no gatekeeper and no security camera is not Zero Trust. It's a gate.
NIST 800-207 Logical Components
NIST's architecture definition identifies seven logical components. Every vendor's "Zero Trust solution" implements some subset of these — rarely all of them. The gap between what a product covers and what the architecture requires is where most ZT programmes stall.
| Component | Plain-Language Function |
|---|---|
| Policy Engine (PE) | The brain. Makes the access decision based on policy and signals. Every access request runs through the PE before being permitted or denied. |
| Policy Administrator (PA) | Executes the PE's decision — creates or tears down sessions. Communicates the decision to the PEP. The PA is the operational bridge between decision and enforcement. |
| Policy Enforcement Point (PEP) | The gate. Enforces the access decision at the resource boundary. The PEP is the component most ZTNA products actually implement. |
| Identity Provider | Manages who the user is — authentication, MFA, SSO. The IdP feeds the PE with identity assertions. Without a robust IdP, the PE has no reliable signal. |
| Device Trust | Assesses device health and compliance before granting access. A valid credential on an unmanaged or compromised device should not receive the same access decision as the same credential on a compliant corporate device. |
| SIEM / Threat Intelligence Feed | Feeds risk signals into the Policy Engine dynamically. This closes the monitoring-to-policy feedback loop. Without SIEM integration, the PE cannot make risk-adjusted decisions. |
| Data Access Policy | Defines what data each subject can access, in what context. The policy library that the PE evaluates against. Must be maintained as a living document, not a one-time configuration. |
Source: NIST Special Publication 800-207 — Zero Trust Architecture (2020). No live link — reference directly at csrc.nist.gov.
Disabling monitoring during a maintenance window — the same mistake described in the CIA Triad article — is architecturally significant in a Zero Trust model. The monitoring plane feeds the policy engine. If monitoring is suspended, the policy engine is flying blind. Even a brief monitoring gap during a high-privilege operation should be documented, compensated for, and reviewed post-window.
The Banking Network: Segmentation Zones
A banking network is not a generic enterprise network. It operates under multiple overlapping regulatory frameworks, each of which defines specific boundaries and access requirements. The segmentation zones in the diagram above are not arbitrary. Each zone corresponds to a specific regulatory scope, a specific sensitivity level, and a specific set of controls.
The zones do not trust each other. A service in the SWIFT zone that requires data from the core banking zone must authenticate and authorise that specific access — it does not inherit trust from being in an adjacent zone. This is the operational definition of microsegmentation.
SWIFT / Payment Zone
- 1.1 — SWIFT Environment Protection (zone boundary)
- 1.2 — Operator Session Confidentiality & Integrity
- 2.9 — Transaction Business Controls (monitoring)
- 6.1 — Operator Access Control (PAM mandatory)
PAM mandatory. All sessions recorded. All traffic logged. Real-time transaction monitoring.
Who can access: Named privileged accounts only. No shared credentials.
PCI DSS Cardholder Data Environment
- Req 1.2 — Network security controls (boundary enforcement)
- Req 7.2 — Access control system configuration
- Req 8.4 — MFA mandatory for all access into CDE
- Req 10.2 — Audit log implementation
MFA mandatory. Network boundary enforced — no direct internet. All access via authorised pathways only.
Who can access: CDE-scoped roles only. Access requires documented business justification.
Core Banking / Legacy Systems
Cannot modify legacy system natively. Wrap in Zero Trust controls externally — the micro-perimeter approach defined in NIST 800-207.
- Network segmentation at perimeter
- Jump server / bastion host for all access
- Full session recording via PAM
- SIEM monitoring for all activity
Who can access: Named application accounts and DBAs only, via PAM.
General IT / Cloud
- Device health check before access (MDM/EDR)
- MFA enforced for all services
- Conditional access policies active
- SaaS access governed by IdP SSO
All employees access this zone — but access is per explicit ZT policy, not implicit network membership.
Who can access: All employees — subject to device and identity verification.
How Traffic Flows: Normal vs. Compromised
The architecture diagram shows the structural components. The flow below shows how traffic moves through them — and how Zero Trust stops a compromised credential from becoming a full compromise.
See How Traffic Flows
In a perimeter model, a compromised credential = access to everything. In Zero Trust, a compromised credential = access to one resource, with every subsequent move requiring re-verification.
Where PCI DSS Lands in the Architecture
PCI DSS defines the CDE as a network boundary — a segmentation zone with explicit, enforced, monitored controls. The requirements map directly to the Zero Trust architecture components:
- Requirement 1 (Network Security Controls) = Policy Enforcement Point at the CDE boundary. Every ingress and egress flow must be defined, authorised, and enforced. This is not a firewall rule. It is a microsegmentation policy administered by the PEP.
- Requirement 7 (Least Privilege Access) = Data Access Policy in the policy engine. Access to CDE systems must be justified by business need, documented, and enforced — not assumed from group membership.
- Requirement 8 (Identity and Authentication) = Identity Provider enforcing MFA. Every user, every service account, every system account must authenticate with MFA before reaching the PEP at the CDE boundary.
- Requirement 10 (Logging and Monitoring) = The monitoring plane as applied to the CDE. All access, all activity, all anomalies must flow to SIEM and be retained for 12 months with 3 months immediately available.
The CDE segmentation requirement in PCI DSS is not a compliance formality. It is a microsegmentation zone boundary with explicit, enforced, monitored controls — which is precisely what the Zero Trust architecture mandates. If you are building a PCI DSS-compliant CDE, you are building a Zero Trust zone whether or not you use the terminology.
Your PCI DSS scope is not just a list of systems. It is a segmentation zone with explicit, enforced, monitored boundaries.
Where SWIFT CSCF Lands in the Architecture
The SWIFT infrastructure zone is the highest sensitivity zone in any banking network. SWIFT Customer Security Controls Framework (CSCF) v2025 defines the controls that govern this zone. The architecture mapping is direct:
- Control 1.1 (SWIFT Environment Protection) = Zone boundary definition and enforcement. The SWIFT environment must be physically and logically separated from the rest of the infrastructure. This is a microsegmentation zone with a defined boundary enforced at the PEP.
- Control 1.2 (Privileged Account Control) = Identity plane with session verification. All operator access to the SWIFT environment requires PAM, session recording, and verification at each step — not implicit trust from network location.
- Control 2.9 (Transaction Business Controls) = Monitoring plane applied to transactions. Real-time transaction monitoring is required — which means SIEM feeds specifically covering SWIFT transaction activity, anomaly detection for volumes and patterns, and an active response capability. This is assume-breach applied to financial transactions.
- Control 6.1 (Operator Access Control) = Data Access Policy governing the SWIFT zone. Named operators only. Least privilege enforced. All access justified by business need and documented. No standing access to the SWIFT interface operator console.
SWIFT assessors reviewing CSP compliance are, in effect, verifying that the Zero Trust architecture is correctly implemented for the SWIFT zone. The terminology differs. The architecture requirement does not.
The Legacy System Problem: Micro-Perimeters
Core banking systems — mainframes, legacy transaction processors, systems that predate modern authentication protocols — cannot natively participate in a Zero Trust architecture. They cannot speak to a policy engine. They cannot consume dynamic access tokens. They cannot verify device health.
The NIST 800-207 answer to this is the micro-perimeter: wrap the legacy system in a Zero Trust control layer externally, even if the system itself cannot be modified. The system remains a risk. The micro-perimeter limits that risk to the smallest possible blast radius and ensures that any compromise is detectable.
Practical controls for legacy system micro-perimeters:
- Network segmentation: Place the legacy system in an isolated network segment. No traffic in or out except explicitly authorised flows. Enforce at the PEP/firewall boundary.
- Jump server / bastion host: All access to the legacy system routes through a managed jump server. No direct access. The jump server enforces MFA and session recording.
- Session recording via PAM: Privileged Access Management covers all sessions on the legacy system. All keystrokes, all commands, all screen activity recorded and retained.
- SIEM monitoring: Legacy system logs forwarded to SIEM in real time. Anomaly detection applied. Alert thresholds set for unusual access patterns, off-hours activity, bulk data queries.
- Application accounts: Legacy system application accounts inventoried, least-privilege applied at the account level, no shared credentials, regular access review.
The legacy system remains a risk. The micro-perimeter limits that risk to the smallest possible blast radius and ensures that any compromise is detectable.
Implementation Phases
Zero Trust is not a product deployment. It is an architectural transformation. Organisations that treat it as a procurement decision consistently fail. The phases below reflect the sequence that works: identity first, then network, then application, then continuous optimisation.
- Deploy MFA across all systems and all users — no exceptions
- Implement RBAC across all systems — access by role, justified by business need
- Deploy Privileged Access Management (PAM) for all privileged accounts
- Audit and remediate over-privileged service accounts — eliminate standing access
- Establish Identity Provider as single source of identity truth — all systems federated
- Deploy device health check, MDM, and EDR — integrate device posture with access decisions
- Implement network microsegmentation — define zones and enforce boundaries at the PEP
- Replace or wrap legacy VPN access with ZTNA — eliminate implicit network trust
- Define and enforce data classification policies — where data lives, who can access it
- Map all authorised network flows — every legitimate path documented and enforced
- Implement application-level authentication — separate from network access grants
- Deploy DLP for sensitive data — enforce data movement policies technically
- Integrate SIEM with access control — monitoring plane feeding policy engine
- Implement just-in-time (JIT) access for all privileged operations
- Apply ZT principles to third-party and API access — no implicit partner trust
- Deploy UEBA — automated anomaly detection feeding the policy engine as risk signals
- Automate access policy response to risk signals — dynamic access adjustment
- Implement continuous monitoring and control testing — not annual reviews
- Apply Zero Trust principles to supply chain and third-party software access
- Annual ZT maturity assessment against CISA Zero Trust Maturity Model (ZTMM)
Common Architecture Mistakes
Mistake 1: Zone segmentation without policy enforcement. Drawing network zones on a diagram is not microsegmentation. Microsegmentation requires a Policy Enforcement Point at the boundary of each zone — actively inspecting, authenticating, and authorising every session. Organisations that define zones in a network diagram but implement them with firewall rules that trust internal-to-internal traffic have not achieved segmentation. They have achieved the appearance of segmentation.
Mistake 2: MFA without device health check. Requiring MFA is necessary but not sufficient. A valid MFA response on a compromised, unmanaged, or non-compliant device should not generate the same access decision as MFA on a fully managed, health-checked corporate device. The Identity Provider handles authentication. Device trust is a separate signal to the Policy Engine. Conflating them is the most common gap in early-stage ZT programmes.
Mistake 3: Buying the Policy Enforcement Point without building the Policy Engine. ZTNA products enforce decisions. They do not make decisions. The product implements the PEP. The organisation must build or deploy the Policy Engine — the component that evaluates identity, device, context, and risk and produces the access decision. Without a functioning Policy Engine, the PEP will enforce whatever default policy was configured at installation, which is typically more permissive than intended.
Mistake 4: Monitoring without response capability. SIEM without a response function is expensive logging. The monitoring plane feeds the Policy Engine with risk signals. Those signals must trigger a response — automated where possible, human-escalated where necessary. An organisation that can detect an anomaly in 30 seconds but requires a 4-hour change management process to adjust access is not operating a Zero Trust architecture. Detection and response must be designed together, not procured separately.
Start with the Principles
The architecture makes more sense once the three principles are clear. If you came here first — the fundamentals page maps Zero Trust to PCI DSS, ISO 27001, and SWIFT CSCF without a single vendor recommendation.
← Read Zero Trust Principles