Every major security vendor sells Zero Trust. Microsoft calls their version a "security strategy." Cloudflare calls theirs a "model." Palo Alto Networks sells you an "architecture." Fortinet has a "platform."
They're all correct. And they're all incomplete.
Zero Trust is not a product you buy, deploy, and tick off a compliance checklist. It's a set of principles — three of them — that require you to fundamentally rethink how access works in your environment. And when those principles are applied properly, they map directly to the controls your next PCI DSS, ISO 27001, or SWIFT CSP audit will evaluate.
That's what this article is: the crosswalk that no vendor will write, because it doesn't require you to buy anything.
Zero Trust is not a product you can buy. It's a set of principles you implement. When a vendor sells you a "Zero Trust" firewall or a "Zero Trust" VPN, they are marketing a tool that may support your ZT journey — not a complete implementation. Buying one tool and calling it Zero Trust is like buying a fire extinguisher and calling it a fire safety programme.
The Problem With How Zero Trust Is Sold
When John Kindervag coined "Zero Trust" at Forrester Research in 2010, his argument was straightforward: traditional network security models are broken because they require an element of trust. The moment you trust something — a device, a location, a network segment — you've created an exploitable assumption. Attackers don't announce themselves. They obtain trusted credentials and move quietly inside environments that have stopped asking questions about them.
The castle-and-moat model worked when the castle had walls. When your "castle" is a hybrid cloud environment with remote workers, third-party payment processors, SaaS applications, and a legacy core banking system built in 1994, the moat is a fiction.
The perimeter model trusts location. Zero Trust trusts nothing — and verifies everything, every time.
Zero Trust's answer is not to build a better moat. It's to stop believing the moat exists.
What Zero Trust Actually Is
Zero Trust is built on three principles. These three principles are not negotiable, not product-specific, and not optional if you want to genuinely claim the model.
Every access request must be authenticated and authorised — regardless of where it originates. Inside the network, outside the network, from a known device, from a trusted user. Every request. Every time.
Every user, service, and device gets only the minimum access required to do their specific job. Not "access to everything they might need someday." The exact permissions for the exact task — and nothing more.
Design your security posture as if attackers are already inside. Segment everything. Log everything. Build detection assuming that perimeter defences have failed — because at some point, they will.
Every Zero Trust implementation — regardless of vendor, tooling, or architecture — is an expression of these three principles applied to five pillars: identity, devices, networks, applications, and data. The CISA Zero Trust Maturity Model formalises this. NIST Special Publication 800-207 defines the architecture components. Neither document tells you which product to buy, because the principles are product-agnostic.
Zero Trust vs. Perimeter Security: What Actually Changed
The shift from perimeter to Zero Trust is not about technology. It's about where trust is placed.
In a perimeter model, trust is placed at the boundary. Once you're inside — authenticated via VPN, connected from an office network, operating from a known IP range — you're implicitly trusted. The network location grants access. This is the model that the Bangladesh Bank's SWIFT terminal operated under when attackers obtained credentials and moved freely across the SWIFT interface to submit fraudulent transfer instructions.
In a Zero Trust model, trust is placed nowhere. Every access request is evaluated on its own merits: who is requesting it, from what device, with what health posture, to what resource, with what level of sensitivity, at what time, from what location. The answer can change per-session, per-request, or per-transaction. A user who passes authentication at 9AM from their corporate laptop may be required to re-verify when they attempt to access the payment system at 2AM from an unmanaged device.
The technical term for this is "dynamic, contextual access policy." The practical term is: nothing is trusted until it earns it, every time.
Quick Check — Can You Spot Real Zero Trust?
3 questions. Based on real implementation scenarios.
A bank has deployed MFA for all remote access connections via VPN. Once inside the VPN, users can access any internal system without further authentication. Is this Zero Trust?
A financial institution has deployed a "Zero Trust Network Access" product from a major vendor. The vendor's documentation confirms the product is "Zero Trust certified." Has the institution implemented Zero Trust?
A bank's security team has implemented microsegmentation across the payment processing environment, with separate zones for card data, application servers, and management systems. Each zone requires explicit authentication to access. Is this Zero Trust?
Zero Trust and PCI DSS v4.0.1
PCI DSS v4.0.1 didn't name Zero Trust. But it was written with Zero Trust thinking.
PCI DSS v4.0.1 didn't add "Zero Trust requirements" as a named section. What it did was embed Zero Trust thinking into existing requirements — stronger authentication standards, continuous monitoring obligations, and explicit requirements to verify the identity of all system components. If you're meeting PCI DSS v4 properly, you are already operating several Zero Trust controls without necessarily naming them.
Verify Explicitly → Requirements 7 and 8. Requirement 7 requires that access to system components is restricted based on business need — least privilege, implemented. Requirement 8 requires MFA for all non-console administrative access and all user access into the Cardholder Data Environment. These are not just authentication controls. They are the identity verification pillar of Zero Trust, expressed as compliance requirements.
Assume Breach → Requirements 1 and 10. Requirement 1 (network security controls) mandates network segmentation that limits the scope of the CDE — which is microsegmentation by another name. Requirement 10 (log and monitor all access) mandates audit logging and log review that presupposes something will go wrong and you'll need the evidence to investigate it. That is the "assume breach" principle in operational form.
Least Privilege → Requirement 3. Requirement 3 restricts storage of sensitive authentication data after authorisation. You cannot retain what you do not need. This is data minimisation — the data pillar of Zero Trust applied to cardholder data specifically.
The implications for your next assessment: if you are meeting PCI DSS v4 requirements properly, you are already operating Zero Trust controls. The gap analysis question is whether those controls are consistent, continuous, and covering all five Zero Trust pillars — or whether you're meeting the letter of specific requirements in isolation.
Zero Trust and ISO 27001
ISO 27001:2022 restructured its Annex A controls in a way that aligns more cleanly with Zero Trust thinking than the 2013 edition did.
The identity pillar lands primarily in:
- A.5.15 — Access control — the policy foundation for least privilege
- A.5.16 — Identity management — managing who gets what identity
- A.5.18 — Access rights — provisioning and de-provisioning based on need
- A.8.5 — Secure authentication — the technical implementation of verification
The network and device pillars land in:
- A.8.20 — Networks security — controls governing network access
- A.8.22 — Segregation of networks — microsegmentation in ISO terms
- A.8.1 — User endpoint devices — device health and management policy
The assume breach pillar lands in:
- A.8.15 — Logging — the audit trail that makes breach investigation possible
- A.8.16 — Monitoring activities — the active surveillance of the environment
- A.5.26 — Response to information security incidents — the response capability
ISO 27001 does not mandate how you implement these controls. A mature Zero Trust architecture is one well-reasoned way to satisfy all of them simultaneously.
Zero Trust and SWIFT CSCF v2025
SWIFT's Customer Security Programme controls are the most explicitly Zero Trust-aligned of the three frameworks — even though SWIFT does not use the term.
Control 1.1 (SWIFT Environment Protection) is microsegmentation. The requirement to create and maintain a secure zone for the SWIFT infrastructure — isolated from the general office environment, with all access tightly controlled — is the network pillar of Zero Trust applied to the most sensitive part of a bank's infrastructure.
Control 1.2 (Operator Session Security) is session verification. Every operator session on SWIFT systems must be individually authenticated and individually authorised. There is no "logged in once, trusted for the day."
Control 2.9 (Transaction Business Controls) is behavioural monitoring — detecting anomalies in transaction patterns that indicate compromise. This is the "assume breach" principle applied to the specific threat of fraudulent SWIFT transactions, the exact attack vector used in the Bangladesh Bank heist.
Control 6.1 (Logical Access Controls) is least privilege applied to the SWIFT environment: users get only the access they need, for only the systems they use, with access reviewed regularly and removed when no longer required.
For banks running SWIFT infrastructure, these controls represent Zero Trust implementation requirements — not by name, but by architecture. Meeting CSCF v2025 without a Zero Trust mindset is technically possible, but it produces compliance artefacts rather than genuine security posture.
The Full Framework Crosswalk
| ZT Principle | ZT Component | PCI DSS v4.0.1 | ISO 27001:2022 | SWIFT CSCF v2025 |
|---|---|---|---|---|
| Verify Explicitly | Identity | Req 8.3 — MFA for all non-console access into CDE | A.5.16 — Identity management | 1.2 — Operator session security |
| Verify Explicitly | Identity | Req 8.4 — MFA for all access into CDE | A.8.5 — Secure authentication | 6.1 — Logical access controls |
| Verify Explicitly | Device | Req 6.3 — Identify and manage all system components | A.8.1 — User endpoint devices | 2.5 — External transmission data protection |
| Verify Explicitly | Application | Req 6.2 — Bespoke and custom software security | A.8.26 — Application security requirements | 6.2 — Software integrity |
| Least Privilege | Identity | Req 7.2 — Access control systems and processes | A.5.15 — Access control policy | 1.1 — SWIFT environment protection |
| Least Privilege | Identity | Req 7.3 — Manage all user IDs and related access | A.5.18 — Access rights | 6.1 — Logical access controls |
| Least Privilege | Data | Req 3.3 — Sensitive authentication data not retained | A.5.12 — Classification of information | 2.6 — Confidentiality and integrity of sessions |
| Least Privilege | Network | Req 1.3 — Network access controls | A.8.20 — Networks security | 2.4 — Back office data flow security |
| Assume Breach | Network | Req 1.2 — Network security controls | A.8.22 — Segregation of networks | 1.1 — SWIFT environment protection |
| Assume Breach | Data | Req 10.2 — Audit logs to facilitate detection | A.8.15 — Logging | 4.1 — Cyber incident response |
| Assume Breach | Application | Req 11.5 — Intrusion detection / prevention | A.8.16 — Monitoring activities | 2.7 — Vulnerability scanning |
| Assume Breach | Identity | Req 10.7 — Detect and report on failures | A.5.26 — Response to IS incidents | 4.1 — Cyber incident response |
The Legacy System Reality
The single most common objection to Zero Trust in banking assessments is legacy infrastructure. "Our core banking system can't support modern identity protocols." This is real — and it's a genuine implementation challenge, not an excuse to skip the work. The answer is compensating controls and phased implementation, not deferral.
The conversation that happens in every banking security review that touches Zero Trust: someone raises the legacy system problem. The core banking platform, the payment switch, the mainframe batch processing system that cannot be modified, updated, or integrated with modern identity protocols.
This is real. It is not an excuse to defer Zero Trust thinking. It is a constraint that requires a specific response: the micro-perimeter.
NIST 800-207 describes this approach directly. When a system cannot be brought into a Zero Trust architecture natively, you wrap it in controls that apply Zero Trust principles at its boundary. Strict network segmentation creates the micro-perimeter. PAM controls who can reach it and from where. Comprehensive logging records everything that happens at the boundary. Session recording captures what privileged users do inside it.
The legacy system itself may not be Zero Trust-capable. The controls surrounding it can still enforce Zero Trust principles.
Where Does Your Environment Sit?
Zero Trust is not binary. It is a maturity spectrum.
Perimeter-based. VPN. Implicit trust inside the network. Flat network — lateral movement unchecked. No enforcement at the resource level.
MFA deployed on some systems. Basic network segmentation. Identity management started but inconsistent. No full RBAC enforcement.
MFA everywhere. RBAC implemented. Microsegmentation in progress. Continuous monitoring established but not fully integrated.
Dynamic, risk-based access policies. Automated threat response. All traffic logged and analysed. Privileged access time-limited.
Continuous verification across all pillars. Automated policy enforcement. No implicit trust anywhere. Supply chain integrity verified.
Most financial institutions operating mature environments sit at Stage 3–4. Reaching Stage 5 is a multi-year journey.
Scenario: Vendor Claim or Zero Trust Principle?
No right or wrong — but your answer reveals how you're being sold to.
A vendor's sales deck says their product provides "complete Zero Trust coverage" and includes microsegmentation, ZTNA, and a cloud access security broker (CASB). Your CISO wants to buy it and declare Zero Trust implemented. What do you say?
During a PCI DSS v4 gap assessment, your team flags that Requirement 8.4 (MFA for all access into the CDE) is met, but all authenticated users can then access any system within the CDE without further verification. The team lead says "MFA is our Zero Trust control for Requirement 8.4." Is this accurate?
What Zero Trust Demands From You
Understanding Zero Trust as a principle set rather than a product has a practical consequence: you can evaluate any vendor claim, any control, and any compliance requirement against three questions.
Does this verify explicitly — does it require proof of identity, device health, and authorisation before granting access?
Does this enforce least privilege — does it grant only the minimum access required, for only the time required?
Does this assume breach — does it operate as if compromise has already occurred, logging everything, segmenting everything, and building the capability to detect and respond?
If a control answers yes to all three, it advances your Zero Trust posture. If it answers yes to one, it's a partial control. If it answers yes to none but is labelled "Zero Trust" on the vendor's packaging, you have been sold a concept, not an implementation.
That is the test. Apply it to every purchase decision, every architectural review, and every audit finding about access control.
Keep Going
The term was coined by John Kindervag, then an analyst at Forrester Research, in a 2010 paper arguing that traditional network security models were fundamentally broken because they required an element of trust that attackers could exploit. Google's internal implementation — known as BeyondCorp — brought Zero Trust from theory to widely-publicised practice around 2014, and NIST formalised the architecture definition in Special Publication 800-207 in 2020.
No. Zero Trust Network Access (ZTNA) is one technology component that enables Zero Trust principles — specifically, it replaces VPN-based remote access with application-level, identity-verified access. It is one tool in a Zero Trust architecture. The full CISA Zero Trust Maturity Model has five pillars: identity, devices, networks, applications, and data. ZTNA addresses the network and application pillars partially. It is not a complete Zero Trust implementation on its own.
PCI DSS v4.0.1 did not introduce a "Zero Trust requirement" by name, but it embedded Zero Trust thinking throughout the standard. Requirement 7 (restrict access to system components by business need to know) is least privilege. Requirement 8 (identify users and authenticate access) is verify explicitly. Requirements 1 and 10 (network security and logging) are assume breach. If you are meeting PCI DSS v4 properly, you are implementing Zero Trust controls — you may just not be calling them that.
Yes, but it requires a phased approach and honest gap analysis. Legacy core banking systems that cannot support modern identity protocols need compensating controls — additional monitoring at the boundary, strict network segmentation around the legacy zone, and PAM for all accounts with access to the legacy environment. The goal is to apply Zero Trust principles to the interaction with the legacy system, even when you cannot modify the legacy system itself. This is the approach NIST 800-207 describes as "micro-perimeters" around legacy assets.
Honestly — years, not months. A realistic phased programme for a mid-size bank or financial institution runs 24–36 months to reach what CISA calls the "Advanced" stage. The first phase (identity foundation — MFA everywhere, RBAC defined, privileged access management) typically takes 6–12 months alone, and that's with executive sponsorship and adequate budget. Banks that claim to have "implemented Zero Trust" in 90 days have bought a product. They haven't built a programme.