Insights Perspective Zero Trust in Banking Is a Policy Change Wearing an Architecture Costume

PERSPECTIVE

Zero Trust in Banking Is a Policy Change Wearing an Architecture Costume

August 31, 2026

Zero trust security is usually presented as an architecture: verify every request, trust no network location by default, enforce least-privilege access continuously rather than once at login. All of that is accurate, and all of it is also the easy part for a bank to buy and deploy. The hard part is what zero trust actually demands organizationally, and that is where most banking zero trust initiatives stall.

What the architecture actually requires underneath it

Enforcing least-privilege access continuously requires an accurate, current answer to a question most large banks cannot actually answer cleanly: exactly what access does each role and each individual actually need, right now, to do their job. Decades of accumulated, never-revoked access grants make that question much harder to answer than the zero trust architecture diagrams suggest.

This means the real first phase of most banking zero trust programs is not deploying new security tooling, it is an access audit and cleanup effort that is organizationally uncomfortable, politically sensitive, and far less exciting than the architecture the security team actually wants to talk about.

Why this gets skipped or rushed

The access audit work is slow, unglamorous, and touches nearly every department, which makes it an easy phase to underscope under deadline pressure. Banks that rush past it end up deploying zero trust tooling on top of the same messy, over-permissioned access reality that existed before, which technically satisfies a zero trust checklist without meaningfully reducing the actual risk the architecture is supposed to address.

What this means for how these programs should be run

A zero trust program that is honest about its own scope treats the access audit and policy cleanup as the majority of the actual work, with the technical architecture as the enforcement layer on top of a foundation that has to be correct first. Banks that sequence it the other way around, architecture first, access cleanup as an ongoing side project, tend to end up with expensive tooling enforcing policies nobody has actually verified are correct.

Contents
Share this perspective

Discuss this perspective

Talk to us about how this applies to your organisation.

Related Perspectives