A UK retail bank spent eighteen months and a seven-figure budget rolling out zero trust. The board signed off on the strategy. The vendor demos were flawless. Yet when our consultants ran the post-implementation review, we found legacy domain controllers still issuing Kerberos tickets to flat networks, a third of privileged accounts exempt from conditional access, and a ZTNA broker bypassed entirely for "operational reasons." The architecture diagram said zero trust. The reality was perimeter security with extra licensing costs.
This pattern repeats across UK financial services. The FCA's operational resilience rules (PS21/3, with the full compliance window closing March 2025) and the Bank of England's continued focus on third-party and cyber risk have pushed boards to fund zero trust programmes at pace. The Cyber Security and Resilience Bill, currently progressing through Parliament, will sharpen expectations further for firms designated as essential or important entities. Speed creates pressure. Pressure creates shortcuts. Shortcuts create the five pitfalls below.
This article unpacks where zero trust architecture implementation goes wrong in UK banks, building societies, payment institutions and asset managers — and what to do instead. It is written for CISOs, heads of architecture, and compliance leads who have already bought the principle and now need to deliver the outcome.
What zero trust actually means (and what it is not)
Zero trust is not a product. It is an identity-centric security model built on the assumption that no user, device, workload or network segment is inherently trustworthy. Every access request is authenticated, authorised and continuously evaluated against context: identity, device posture, location, sensitivity of the resource, and behavioural signals.
The reference architecture most UK firms align to is NIST SP 800-207, which defines the policy decision point, policy enforcement point, and the supporting trust algorithm. The NCSC's own zero trust design principles (eight of them, refreshed and maintained on the NCSC website) are the practical UK companion. Read both before you write a single procurement requirement. The NCSC principles are particularly blunt about the most common failure: treating zero trust as a network project rather than an identity project.
Zero Trust Network Access (ZTNA) is one component — typically the replacement for legacy VPN. ZTNA adoption in the UK has accelerated as hybrid working hardened into permanence, but ZTNA alone is not zero trust. It is one enforcement point in a much larger control plane. Firms that conflate the two end up with a glorified VPN replacement and a board that thinks the job is done.
Why this matters now for UK financial services
Three forces are converging. First, the FCA's operational resilience regime requires firms to identify important business services, set impact tolerances, and demonstrate they can remain within those tolerances during severe but plausible scenarios — including cyber incidents. Zero trust directly supports the containment and recovery elements of that mandate.
Second, the PRA's SS2/21 outsourcing and third-party risk management expectations push firms to apply consistent controls across in-house, cloud and supplier-hosted services. A perimeter model cannot deliver that. An identity-centric security model can.
Third, for UK firms with EU subsidiaries or EU clients, DORA (applicable to EU financial entities since 17 January 2025) and NIS2 (for EU-based essential and important entities) create extraterritorial pressure. UK-only firms are not directly in scope, but group-wide architecture standards usually follow the strictest jurisdiction. Boards want one model, not two.
Pitfall 1: Treating zero trust as a network refresh
The most expensive mistake is buying SASE, microsegmentation and ZTNA tooling before fixing identity. If your Active Directory is a sprawl of nested groups, your service accounts have decade-old passwords, and your joiner-mover-leaver process runs on a SharePoint form, no amount of network re-architecture will deliver zero trust outcomes.
Start with identity. Consolidate identity providers. Enforce phishing-resistant MFA (FIDO2 or platform authenticators) for all privileged access. Eliminate standing privilege using just-in-time elevation. Audit every service account and decommission what you cannot justify. Only then is the network conversation worth having.
What good looks like
A single authoritative identity source for human users, federated to all SaaS and IaaS. A separate, tightly governed workload identity model (managed identities in Azure, IAM roles in AWS) with no long-lived credentials in code. Conditional access policies that evaluate device compliance, risk score, and resource sensitivity on every request.
Pitfall 2: Leaving legacy applications outside the model
Every UK bank has them: the core banking platform on AIX, the actuarial system that only speaks NTLM, the reconciliation tool that needs flat network access to a fileshare. Teams quietly carve out exceptions and the exception list becomes the new perimeter.
The fix is to wrap, not exempt. Application proxies, identity-aware reverse proxies, and protocol translation gateways can front legacy systems and bring them under conditional access policies even when the application itself cannot speak modern auth. Where wrapping is genuinely impossible, isolate the application in a dedicated segment with monitored, time-bound jump access and document the residual risk on the risk register with a remediation date. No open-ended exceptions.
Pitfall 3: Ignoring device posture as a first-class signal
Identity without device context is half the model. A valid user on a jailbroken phone, an unpatched laptop, or a personal device with no EDR is not the same access decision as the same user on a managed, compliant endpoint. Yet our team repeatedly finds conditional access policies that check identity and MFA but never device compliance.
Integrate MDM and EDR telemetry into the policy decision point. Require compliant device for access to sensitive data. Use continuous evaluation so that a device falling out of compliance mid-session triggers re-authentication or session termination — not a wait until the next login.
Pitfall 4: No data classification, so no meaningful policy
Zero trust policies should scale with the sensitivity of the resource. Accessing the staff canteen menu is not the same as accessing customer PII or trade data. Without data classification, every policy defaults to the most permissive level the business will tolerate — which is rarely tight enough.
Classify data before you build policy. Four tiers is usually enough: public, internal, confidential, restricted. Tag at source where possible (Microsoft Purview, AWS Macie, Google DLP). Bind conditional access, DLP, and encryption requirements to the classification. This is the single biggest lever for getting ISO 27001 certification auditors comfortable with your access control narrative under Annex A.5 and A.8.
Pitfall 5: No measurement, no iteration
Zero trust is not a project with an end date. It is a control posture that needs continuous measurement. Firms that declare victory at go-live and disband the programme team watch the architecture decay within twelve months. Exception lists grow. Policies drift. New SaaS apps onboard outside the model.
Define metrics from day one. Percentage of applications behind the identity-aware proxy. Percentage of privileged sessions using just-in-time access. Mean time to revoke access on leaver events. Number of standing exceptions and their ageing. Report these to the executive committee quarterly. Tie them to operational resilience self-assessments.
A practical sequencing checklist
- Months 0–3: Identity consolidation, MFA uplift for privileged users, service account audit, data classification scheme agreed.
- Months 3–9: Conditional access with device compliance, ZTNA pilot for one business unit, legacy application wrapping for the top five exposed systems.
- Months 9–18: Microsegmentation in the data centre, workload identity for cloud, just-in-time privileged access, continuous evaluation enabled.
- Ongoing: Quarterly metric review, exception ageing, annual architecture re-baseline against NCSC principles.
How Pyralink helps
Pyralink Innovation Ltd, led by Founder and Managing Director Michael Adedeji (CISM, CISA, CC, MSc Data Science), supports UK financial services firms through every stage of zero trust delivery. Our consultants have implemented identity-centric architectures in regulated environments — not studied them from textbooks. We carry £5M professional indemnity insurance and work to NCSC and NIST reference standards.
Engagements typically start with a current-state assessment against the NCSC's eight zero trust principles, followed by a prioritised roadmap that sequences identity, device, data and network workstreams. Our fractional vCISO service (from £497/month) gives smaller firms board-level ownership of the programme without a permanent hire. For cloud posture and configuration drift, CloudAuditX continuously audits AWS, Azure and GCP against zero trust control baselines. For wider reading, browse our insights or run the free compliance scanner to benchmark your current posture in minutes.
Zero trust is achievable. Most failed rollouts fail for the same five reasons. Fix the identity foundation, classify the data, instrument the controls, and measure relentlessly.