Zero trust in banking: when the internal network stops being safe

The reference text is NIST SP 800-207, Zero Trust Architecture, published in August 2020. It describes zero trust as an evolving set of paradigms that move defenses from static network-based perimeters toward users, assets and resources, and it is explicit that an organization should not trust assets or accounts automatically on the basis of their network location or ownership. Authentication and authorization of both the subject and the device are discrete functions performed before a session to a resource is established.

What that costs a bank is the comfortable assumption that an application inside the data center is talking to a colleague. It now has to ask who is calling, from what device, in what state, for which resource, every time. The BSI positions the model in its own guidance for German organizations, which matters when you have to explain the architecture to an auditor who wants a German reference and not only an American one.

The step that distinguishes zero trust from a procurement exercise is defining what you are protecting before you buy anything to protect it with. That means naming the data, applications, assets and services that would actually hurt, which is a much smaller set than the whole estate, and then mapping how transactions reach them: which systems call which, in what order, with which credentials.

The sequence set out in DXC's five steps for financial services runs protected surface, transaction flows, architecture, policy, monitoring, in that order. The reason the order is load-bearing is that a policy written without the flow map blocks a payment run at month end, and the organization then learns that zero trust breaks things. A flow map built first turns that into a design question with a known answer.

If location no longer grants access, identity has to carry the weight, and that means an inventory of who and what can authenticate, with an owner for each entry and a review that actually removes entries. Privileged access is the sharp end: administrator credentials, emergency accounts, the service account that was created for a migration in 2014 and never switched off.

Segregation of duties belongs in the same conversation, because the control that stops one person from both creating and approving a payment is an access design and not a policy document. DORA places ICT risk management and access rights among the duties a European financial entity owes, and the EBA guidelines on ICT and security risk management set the supervisory expectation in more detail. Credentials that no human ever logs in with are their own problem, which machine identity in banking covers, and the phishing-resistant end of customer and staff login sits on passkeys in banking.

Microsegmentation means a compromised system can reach only what it was supposed to reach, which is how you stop one foothold becoming a bank-wide incident. It also meets the oldest machine in the building. A core banking platform or a mainframe that predates the concept often cannot enforce per-request authorization, and the applications around it were written assuming the network would vouch for them.

The constraints described in WWT's account of zero trust deployment challenges are legacy access paths, operational environments where change is resisted for good reasons, and the problem of not having a complete identity inventory to start from. That is the honest reason most banks are partway in: the answer for the legacy core is usually a hardened boundary around it with monitored, named access paths, while the newer estate gets the full model. Core banking in Germany covers the platform side of that question.

German institutions did not meet these expectations for the first time with DORA. BaFin's supervisory requirements for IT, the BAIT, carried the access management, authorization and IT governance expectations for years, and DORA has absorbed that ground into directly applicable European law. People searching for the relationship between the two is visible in the autocomplete data, and the practical answer for a project is that the control objectives survived the transition even where the document reference changed.

What that means for an architecture paper is that you can map a zero trust design onto named duties instead of defending it as best practice. DORA in Germany covers the regulation and how BaFin supervises it, and risk management in Frankfurt covers the wider risk function this sits inside.

Zero trust answers who may reach a resource. It says nothing about where the resource sits or which jurisdiction can compel access to it, and those two questions get confused in the same meeting more often than they should.

A bank can run an exemplary zero trust architecture in a cloud whose operator is subject to a foreign disclosure order, and the architecture will not help with that problem. Sovereign cloud in banking covers the location and control question, and data centers for finance in Frankfurt covers the physical side.

An approach where no request is trusted because of where it came from, so every request to a resource is authenticated and authorized against current information about the user and the device. In a bank it is applied by defining the systems worth protecting, mapping how transactions reach them, and then enforcing per-request decisions, with the oldest platforms usually handled by a hardened, monitored boundary instead.

DORA names duties, not architectures. It requires ICT risk management, protection measures and controlled access rights, and a zero trust design is one way to meet them that maps onto the duties cleanly. A bank that meets the same objectives differently is compliant; what it cannot do is skip the objectives.

With the protected surface: the short list of data and systems whose compromise would actually hurt. Then the transaction flow map for those systems. Technology decisions come after both, because a policy written without the flows will block legitimate work and cost the project its support.

Partly, and that is the usual state. A platform that cannot evaluate per-request authorization gets a hardened boundary with named, monitored and time-limited access paths, while the surrounding estate runs the full model. The failure mode is pretending the legacy exception does not exist, because an attacker who reaches it finds the one place where the network still vouches for everyone.