Zero Trust in banking: practical architecture for regulated environments

The old security model —the castle with its moat, where everything inside is trusted— has been dying for years. With remote work, the cloud and AI agents, the perimeter no longer exists. In its place a different philosophy has taken hold: Zero Trust in banking , where nothing is trusted by default and everything is continuously verified.

What Zero Trust is and why banking needs it

Zero Trust boils down to a single phrase: never trust, always verify. Every access to every resource is validated on the basis of identity, device, context and risk, without assuming that being inside the network means being legitimate. For banking, which handles critical data and is a constant target of attacks, this approach is no longer optional.

The trigger is usually twofold: the sophistication of attacks and regulatory pressure. An attacker who manages to get in should not be able to move around freely, and Zero Trust is designed precisely to prevent that lateral movement.

Pillars of a Zero Trust architecture

Strong identity verification

Identity is the new perimeter. Multi-factor authentication, continuous validation and rigorous access management, including non-human identities, are the foundation on which everything else is built.

Microsegmentation

Dividing the network into small, controlled segments limits the damage of a breach. If an attacker compromises one segment, they do not gain access to everything. It is the technical translation of the principle of containment.

Least privilege

Each user and each service receives only the permissions that are strictly necessary, for only as long as necessary. This ties in with cybersecurity risk management: the lower the privilege, the lower the potential impact.

Zero Trust, DORA and NIS2

Implementing Zero Trust in banking makes it easier to comply with frameworks such as the DORA regulation and NIS2, which require access control, resilience and the ability to contain incidents. It is not that Zero Trust meets the regulation for you, but its architecture responds directly to many of its requirements.

Where to start implementing Zero Trust

Zero Trust is not implemented overnight, nor bought in a box. It is a journey best travelled in phases. When I work alongside a financial institution, I usually start with identity: strengthening multi-factor authentication and eliminating shared accounts, because most serious incidents begin with a stolen credential. Once we know for certain who is accessing what, it makes sense to move towards network microsegmentation and fine-grained privilege control.

The mistake I see most often is trying to segment everything on day one. It is unmanageable and breeds resistance. I prefer to first identify the most critical assets —the ones that really hurt if they fall— and build the first zero-trust perimeters around them. From there, the model extends naturally to the rest of the organisation without paralysing operations.

How to prove that Zero Trust works

A zero-trust architecture is only worth what its tests demonstrate. Designing it is not enough: you have to attack it to check that it holds up. This is where the advanced penetration testing required by financial regulation comes in, which I explore in my article on DORA’s threat-led penetration testing. A well-executed TLPT exercise tests precisely whether microsegmentation and continuous verification stand up to a real attacker.

When those tests find a lateral path that should not exist, it is not a failure: it is exactly what they are for. Better to discover the flaw in a controlled exercise than in a real attack. That mindset —actively hunting for weak points— is inseparable from the Zero Trust philosophy.

My conclusion is that in banking, zero trust has stopped being a fad and become a regulatory and operational necessity. Digital banking no longer has a clear perimeter to defend, so the only sensible strategy is to assume the attacker may already be inside and to verify every step. It is not distrust for its own sake: it is prudence designed into the architecture.

A common confusion I come across is thinking that Zero Trust is a product you buy and install. It is not: it is a design principle applied layer by layer. Start by identifying what you want to protect —critical data and services— and build around it strong identity controls, network segmentation and continuous verification of every access. In banking, where legacy systems coexist with modern platforms, this gradual approach is the only realistic way to make progress without paralysing operations.

The other big misunderstanding is believing that Zero Trust degrades the user experience. Done well, the opposite happens: adaptive authentication asks for more assurances only when the risk justifies it, and the rest of the time access flows normally. That proportionality between security and usability is, for me, the sign that the model has been implemented with judgement and not as just another bureaucratic obstacle.

Conclusion: trust earned, not assumed

Zero Trust in banking is not a product you buy but a strategy implemented in layers and with patience. My recommendation is to start with identity and progress incrementally. In a sector where a failure is measured in millions and in lost trust, assuming trust by default is a luxury no one can afford.

Frequently asked questions about Zero Trust in banking