The perimeter is dead. For financial services organisations still defending their digital assets with a castle-and-moat model — trusting everything inside the network boundary and treating the outside world as hostile — the threat environment has fundamentally changed. Cloud adoption, remote working, third-party API integrations and the proliferation of mobile endpoints have dissolved the network perimeter entirely. Attackers who breach the boundary now find a largely trusting internal environment ripe for lateral movement.
Zero Trust architecture is the strategic response to this reality. Rather than trusting any entity by default — user, device or service — because it sits inside a notional perimeter, Zero Trust requires continuous verification at every access request. The principle is simple: never trust, always verify.
This article explains what Zero Trust means for financial services organisations specifically, how it aligns with UK regulatory expectations, and what a practical implementation roadmap looks like.
Why Financial Services Is a Priority Target
Financial services organisations hold three things that attackers prize above almost all else: money, data and trust. A compromised investment bank or insurance platform offers immediate financial returns through fraud, ransom payments or market manipulation, as well as longer-term value through the theft of customer personally identifiable information and commercially sensitive data.
The attack surface has expanded dramatically. Open Banking regulations mandating third-party API access, cloud-hosted core banking and insurance platforms, and hybrid working arrangements have created a web of connectivity that legacy perimeter controls were never designed to secure.
At the same time, the regulatory environment has intensified. The FCA's Operational Resilience rules, DORA (the EU Digital Operational Resilience Act, which affects UK firms with EU operations or counterparts), PRA supervisory statements on cyber resilience, and the NCSC's Cyber Essentials Plus certification scheme all create concrete obligations that organisations must demonstrate compliance with. A mature Zero Trust architecture is not just a security improvement — it is increasingly a regulatory necessity.
The Core Principles of Zero Trust
Zero Trust is an architectural philosophy rather than a single product. It rests on several interlocking principles.
Verify Explicitly
Every access request — from a user, a device, a service or a workload — must be authenticated and authorised before access is granted. This requires multi-factor authentication as a baseline, combined with contextual signals such as device health status, location, time of day and behavioural anomalies. Static credentials alone are insufficient.
Use Least Privilege Access
Entities should be granted the minimum level of access required to perform their function, for the minimum necessary duration. Privileged access must be explicitly justified, time-limited and subject to enhanced monitoring. This significantly reduces the blast radius of a compromised account.
Assume Breach
Organisations should design systems on the assumption that a breach has already occurred or will occur. This means segmenting networks so that a compromised endpoint cannot access the entire estate, encrypting data in transit and at rest, and instrumenting systems to detect and respond to lateral movement.
Micro-Segmentation
Rather than treating the internal network as flat and trusted, Zero Trust environments are divided into micro-segments with granular access controls between them. A payment processing service communicates only with the specific downstream services it requires; an HR portal has no route to the trading platform. This containment strategy is the practical expression of "assume breach" at the network layer.
Aligning Zero Trust with UK Regulatory Expectations
UK financial services regulators have not mandated a specific security architecture, but their expectations map closely onto Zero Trust principles.
FCA Operational Resilience. The FCA's PS21/3 policy statement requires firms to identify important business services, set impact tolerances for disruption, and demonstrate that they can remain within those tolerances through severe but plausible scenarios. Zero Trust architecture directly supports resilience by limiting the propagation of failures and attacks across service boundaries.
NCSC Cyber Essentials Plus. The NCSC's Cyber Essentials Plus certification requires organisations to demonstrate controls including network firewalls, secure configuration, access control, malware protection and patch management. Zero Trust architecture provides a coherent framework within which all of these controls operate cohesively rather than in isolation.
Bank of England / PRA Supervisory Statement SS2/21. The PRA's supervisory statement on operational resilience includes expectations on scenario testing and identification of third-party dependencies. Zero Trust's continuous monitoring and logging capabilities provide the evidential basis needed for supervisory discussions.
DORA. For firms in scope of DORA, ICT risk management requirements including network segmentation, monitoring and incident reporting align directly with Zero Trust architecture.
A Practical Implementation Roadmap
Zero Trust transformation does not happen overnight. A phased approach, anchored in business risk priorities, is far more effective than a wholesale architectural replacement.
Phase 1: Identity and Access Foundation (Months 1–4)
The identity layer is the most critical component of Zero Trust. No access decision can be made without knowing who or what is making the request.
In this phase, organisations should implement or mature their Identity and Access Management (IAM) platform, deploy conditional access policies based on device compliance, enforce MFA across all user-facing applications without exception, and begin auditing privileged access to identify accounts with excessive permissions.
Critically, this phase should include a full inventory of service accounts and machine identities. In many financial services organisations, these non-human identities far outnumber human users and represent a significant and frequently overlooked attack surface.
Phase 2: Device Trust and Endpoint Security (Months 3–7)
Zero Trust requires that devices, not just users, are verified before access is granted. In this phase, organisations should implement endpoint detection and response (EDR) tooling, integrate device compliance status into access decisions, and establish a mobile device management (MDM) platform covering all corporate and BYOD endpoints.
Device certificates issued by an enterprise PKI provide a stronger device identity signal than device attributes alone. Organisations should evaluate certificate-based device authentication as part of this phase.
Phase 3: Network Micro-Segmentation (Months 6–12)
Network segmentation is typically the most technically complex phase of Zero Trust implementation. It requires a thorough understanding of existing network flows — which services communicate with which, over which protocols and ports — before controls can be applied without disrupting operations.
We recommend starting with the highest-sensitivity network segments (payment processing, privileged access workstations, core banking) and applying Software Defined Perimeter (SDP) or Software Defined Networking (SDN) controls iteratively, validating that legitimate traffic is unaffected at each step before proceeding.
Phase 4: Data Classification and Protection (Months 10–18)
Data protection must follow the data itself rather than relying on network controls to protect it in aggregate. This phase involves implementing data classification across the organisation's information assets, applying persistent protection (encryption and rights management) to high-sensitivity assets, and integrating data loss prevention (DLP) tooling with the identity and access management layer.
Phase 5: Continuous Monitoring and Response (Ongoing from Month 6)
Zero Trust is not a static state — it requires continuous monitoring to be effective. Security Information and Event Management (SIEM) platforms should be configured to correlate identity, device, network and application telemetry into a unified view of access activity. Anomaly detection models, increasingly AI-augmented, surface suspicious patterns for analyst review.
Incident response playbooks must be updated to reflect the Zero Trust architecture, with clear escalation paths and contained response actions that limit the scope of remediation activity.
Common Pitfalls to Avoid
Treating Zero Trust as a product purchase. Vendors market solutions as "Zero Trust" products, but Zero Trust is an architecture that requires integration across identity, device, network and application layers. No single product delivers it.
Neglecting legacy application compatibility. Some legacy financial applications, particularly older core banking or insurance platforms, cannot participate in modern authentication flows. A pragmatic architecture must account for these systems through compensating controls such as application proxies and dedicated network segments with enhanced monitoring.
Underestimating the cultural change. Zero Trust impacts how employees access systems — additional authentication steps, conditional access policies that block non-compliant devices, session time limits. Without effective communication and change management, user friction generates pressure to weaken controls.
Insufficient logging. The "assume breach" principle requires the ability to investigate and contain incidents. This is only possible with comprehensive, tamper-evident logging of identity, access and network events. Log completeness and retention should be defined and validated before other controls are relied upon.
How MITC Supports Zero Trust Programmes
MITC's Network Security team brings deep experience in Zero Trust architecture design and implementation for UK financial services clients. Our engagements typically begin with a Zero Trust Maturity Assessment aligned to the NCSC Zero Trust Architecture Design Principles, which produces a gap analysis and a prioritised remediation roadmap.
From there, we support implementation through each of the phases described above, drawing on our partnerships with leading identity, EDR and network security vendors. Where appropriate, we coordinate with the FCA, PRA and NCSC to ensure that regulatory stakeholder expectations are addressed through the architecture design.
To discuss your organisation's network security posture, contact info@mayfairitconsultancy.com or call +44 (0) 800 002 5642.