What is zero-trust architecture for financial services?

Zero-trust architecture for financial services is a security model in which no user, workload, device or AI agent is trusted because of where it sits on the network. Every request is verified against policy, granted the least privilege it needs, and recorded with enough provenance for an auditor to replay the decision. The bank stops asking where a request came from and starts asking who is making the request and on what terms.

The model is codified in NIST SP 800-207, and the UK National Cyber Security Centre publishes its own zero trust architecture design principles. In a bank, zero trust is an engineering property of the platform: identity, segmentation, policy and observability designed together, so that a compromise in one place stays in one place and every access decision leaves evidence.

This guide is written for engineering leaders and senior engineers in regulated financial services. It covers the definition, the regulatory case, how the architecture runs inside a bank, a six-step implementation framework, what changes when AI agents act inside the estate, and where programmes stall.

Why does zero trust matter for banks now?

Zero trust matters now because the perimeter no longer describes where a bank's risk lives, and because regulators ask for evidence at a granularity only per-request controls produce. Customers transact from their own devices, fintech partners call the bank's APIs from public cloud, workloads span several providers, and AI agents are starting to take actions of their own.

Zero trust is built for the way breaches actually reach a bank. They start with a stolen credential or an over-privileged service account, then move sideways through an estate that trusted its own interior. IBM and the Ponemon Institute put the global average cost of a data breach at USD 4.99 million, a 12% increase on the previous year, with a 56% increase in AI-driven attacks (IBM Cost of a Data Breach Report, 2026).

Zero trust addresses that interior. It narrows what any single identity can reach, so a compromise has a small blast radius, and it records every decision, so the investigation starts from evidence rather than reconstruction.

What does NIST SP 800-207 require?

NIST SP 800-207 defines zero-trust architecture as a set of principles and logical components that remove implicit trust based on network location. Access is granted per session, per resource, through a policy decision that considers identity, device state and context, and is enforced as close to the resource as possible.

The standard names three logical components:

• Policy engine. Decides whether a subject may access a resource, drawing on identity, device posture, threat intelligence and the bank's policy.
• Policy administrator. Establishes or shuts down the communication path between subject and resource based on the engine's decision.
• Policy enforcement point. Sits in front of the resource, enables, monitors and terminates the connection.

Together the engine and administrator form the policy decision point. In a bank the pattern applies to three kinds of identity at once: people, workloads calling other workloads, and AI agents calling tools. Every caller earns its access the same way. A service in the same Kubernetes namespace as the ledger still presents a short-lived workload identity and passes a policy check before every call.

What are the pillars of zero trust, and how do they map to a bank?

The five pillars most teams work from come from the CISA Zero Trust Maturity Model: identity, devices, networks, applications and workloads, and data, with visibility and analytics, automation and orchestration, and governance running across all five. Each pillar has a direct banking counterpart.

Three principles sit underneath the pillars. Verify explicitly, on every request. Grant least privilege, for the shortest time that works. Assume breach, so containment and detection shape the design from the start.

Why do UK and EU regulators expect zero-trust controls?

Regulators rarely say "zero trust", but the controls they require are zero-trust controls. They expect a bank to know who can reach each important service, to contain disruption within defined tolerances, and to evidence third-party access. Perimeter models struggle to show any of that per request.

• DORA. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied to in-scope EU financial entities since 17 January 2025. It requires ICT risk management, continuous monitoring and management of ICT third-party risk.
• PRA SS1/21. The PRA's operational resilience supervisory statement asks banks to set impact tolerances for important business services and to stay within them through severe but plausible disruption.
• PRA SS2/21. The PRA's outsourcing and third-party risk statement sets expectations for controlling and evidencing access by third parties.

What an auditor asks for is evidence of each access decision. A zero-trust estate answers with a query against the policy decision log, where a perimeter estate offers a folder of quarterly access-review attestations.

How does zero trust work inside a bank's estate?

Inside a working estate, every request passes a policy decision point and a policy enforcement point, and every decision is logged with provenance. A person approving a payment triggers a chain of service calls, and each call in that chain is authenticated and authorised on its own terms rather than inheriting the approver's session.

Four layers carry the design:

• Identity fabric. A single identity provider issues short-lived, automatically rotated credentials to people, workloads and agents, joined to joiner, mover and leaver processes.
• Micro-segmentation. The unit of isolation is the workload or data store, enforced through service mesh and network policy in cloud and software-defined networking on premises.
• Data-layer control. Attribute-based access decides on requester, data classification, purpose and context, and every read and write is recorded.
• Observability. Authentication, authorisation and data-access events feed security analytics, and the same events become the audit record.

Change control belongs in the same design, because an access policy nobody can trace is its own implicit trust. On a regulated platform programme we moved environment state into Git: network rules, deployment configuration, policy settings and service definitions became reviewed artefacts. A pull request became the change request, policy checks ran before approval, every privileged change needed two approvals, and the deployment controller applied only approved commits. Reviewers stopped reading prose and started reading evidence, as described in our GitOps change control field note.

For banks running an event-driven architecture, the event stream doubles as the observability layer: each authorisation decision is an event with a producer, a consumer and a timestamp.

How do you implement zero trust in a bank in six steps?

Implement zero trust one protect surface at a time: pick a high-value asset, map how it is reached, write the policy, put identity in place, enforce in shadow mode first, then observe and expand. Programmes that try to cover the whole estate in one phase stall. Programmes that prove the pattern on one surface and repeat it succeed.

1. Identify the protect surface. A customer data store, a payments authorisation service or a credit decisioning engine. Choose on business criticality and regulatory sensitivity, weighed against how feasible the work is.
2. Map the flows. Document every legitimate path to the surface: people, services, APIs, batch jobs and agents. Skipping this step is how teams break dependencies they did not know existed.
3. Design the policy. Express it as identity, action, resource and condition. Version it, review it and keep it in source control alongside the code it governs.
4. Put the identity fabric in place. Federate human identities, issue workload identities to every participating service, add device-trust evaluation. Enforcement before identity is the most common reason programmes stall.
5. Enforce in shadow mode first. Log what would be allowed or denied without blocking, fix the policy errors, then switch to enforcement.
6. Observe, audit and expand. Feed decisions into analytics, refine the policy, hand the evidence to audit, and move to the next surface.

The first surface takes longest, typically six to nine months in a regulated bank. Later surfaces move faster because the substrate built for the first one already exists. Reversibility keeps each step safe: on a hybrid-cloud core banking programme for a UK digital bank, changes rolled out behind feature flags with progressive exposure so they could be backed out cleanly, as the zero data centre case study sets out.

How does zero trust apply to AI agents in a bank?

An AI agent is another identity in a zero-trust estate. It receives its own scoped credentials, calls only the tools its policy allows, operates within budgets, and leaves a trace of every action. A bank that already runs zero trust for people and services can extend it to agents at marginal cost, which is what makes the substrate worth building before the first agent ships.

The failure pattern is familiar. A team ships an agent as a single service with a model provider's API key in its environment, a hard-coded prompt and a public endpoint. Then the production questions arrive: who is allowed to call it, which callers get which limits, and what stops a runaway loop from spending without end.

On agent-fabric, the agentic platform described in our field note on designing a zero-trust LLM platform, the answer was to apply zero trust between the platform's own services. Authentication, quotas, provider routing and agent execution run as separate services. Each caller type, whether a person in a web interface, a scheduled batch job, another agent or an enterprise partner, carries its own credentials and output budgets, with a global cap and a kill switch designed in from the start.

The named risk is excessive agency: an agent holding more functionality, permissions or autonomy than its task needs (OWASP LLM06:2025). The Cloud Security Alliance's Agentic Trust Framework applies zero-trust governance to the same problem.

How much an agent may do depends on where it sits on the autonomy spectrum:

Where do zero-trust programmes stall in large financial estates?

Zero-trust programmes stall in banks when identity lags behind enforcement, when segmentation collides with payment latency, when nobody owns the policy engine, and when audit evidence has to be rebuilt after the fact. Each of these is an engineering problem with a known fix.

• Buying a product and calling it done. Zero trust is an integration of identity, segmentation, policy and observability, which is work a bank does rather than a licence it buys.
• Enforcing before identity is solid. Enforcement against a partial identity fabric breaks services and turns engineers against the programme. Identity work leads.
• Identity sprawl across legacy cores. Mainframe and packaged cores rarely speak modern identity. Wrap them in enforcement proxies at the boundary while the core is modernised.
• Segmentation that breaks payment SLAs. A slow policy decision point becomes a latency tax on every transaction. Cache policy, pre-compute authorisation where safe, and load-test the decision path.
• Policy engines nobody owns. When security writes the policy and platform engineering runs the engine, drift follows. Give one joint team ownership of both.
• Evidence reconstructed after the fact. Before the GitOps change described above, evidence lived across a ticket queue, a cloud console and deployment logs, which made every audit slow. Evidence has to be a by-product of how change happens.

What changes for payments?

Payments add two constraints to zero trust: strict latency budgets and long chains of services handling each message. The design goal is per-hop verification that stays inside the payment SLA, with the audit trail produced as a side effect.

Every service in an ISO 20022 message flow authenticates to the next with a short-lived workload identity, so no hop inherits trust from the one before. Screening sits in the payment path, which makes its latency a zero-trust design concern. At a major UK bank, the screening platform we rebuilt moved provider calls from a sequential chain to parallel calls on an event-driven architecture, so one slow provider no longer stalled the pipeline. Commercial customer onboarding went from 10 days to under 12 hours. The same pattern is covered in our guide to event-driven architecture for payments screening.

Segmentation for payments is designed around the SLA from the start: policy decisions are cached at the enforcement point, segments follow the message flow, and enforcement runs in shadow mode against production traffic before it can block a payment.

What does confidential computing add?

Confidential computing protects data while it is being processed, inside hardware-based trusted execution environments whose state can be attested (Confidential Computing Consortium). Zero trust protects the path to the data. Confidential computing protects the data during processing, which matters when payment or customer data runs on shared cloud infrastructure.

For a bank, attestation becomes a policy input: a workload may receive a decryption key only after it proves it is running the expected code in a genuine enclave. That closes the gap between "this identity may access the data" and "this runtime can be trusted with it", and it gives AI agents processing sensitive data a verifiable execution boundary.

Where should a bank start?

Start with the protect surface that scores highest on business criticality and regulatory sensitivity while remaining technically feasible. For most banks that is a customer-facing API platform, a payments authorisation service or a recently built greenfield platform. The core ledger comes later, once the pattern is proven.

Build the muscle on a contained surface, then take it to the harder problems.

Frequently asked questions

What are the five pillars of a zero trust architecture?

The CISA Zero Trust Maturity Model defines five: identity, devices, networks, applications and workloads, and data, with visibility, automation and governance running across all of them. The useful test in a bank is to score each pillar for workloads rather than for people, because human identity is usually years ahead of service and agent identity. Whichever pillar scores lowest on that reading sets the real maturity, and it is almost always identity.

What is the NIST zero trust architecture?

NIST SP 800-207 is NIST's guidance defining zero-trust architecture. It removes trust based on network location and places a policy engine, a policy administrator and a policy enforcement point between every subject and resource. It carries no mandate in the UK, so banks typically read it alongside the NCSC's zero trust design principles and map both onto their own regulatory obligations.

What are the downsides of a zero trust architecture?

The costs are upfront effort and operational load. Mapping flows and building an identity fabric takes months, a poorly engineered policy decision point adds latency to every transaction, and the volume of logged events needs analytics capacity. These are engineering costs that fall as each new protect surface reuses the substrate.

What can go wrong with confidential computing in a bank?

The common failure is treating attestation as a one-time check. A workload attested at start-up but never re-attested lets a later compromise inherit the trust the enclave was granted. The second is key management: an enclave that can obtain a decryption key without proving its code identity offers no more protection than the host it runs on. Both are policy problems rather than hardware ones, which is why attestation belongs as an input to the policy engine.

How do you implement zero trust across a regulated banking estate?

Implement it one protect surface at a time, and treat shadow mode as a gate rather than a formality, because it is where policy errors surface cheaply. The first surface typically takes six to nine months. When it runs longer, the cause is usually an incomplete identity fabric rather than the policy itself, which is why identity work leads and enforcement follows.

How does zero trust apply to AI agents?

Treat every agent as an identity with its own scoped credentials, tool permissions and budgets. The part teams miss is the trace: log the agent's intent alongside the tool call, because a record of calls made without the reasoning behind them cannot answer an auditor asking why an action was taken. This contains the excessive-agency risk OWASP names for LLM-based agents.

Which zero-trust approaches suit payments?

Per-hop workload identity carries the ISO 20022 message chain, with policy decisions cached at the enforcement point so verification stays inside the payment SLA. Run enforcement in shadow mode against live traffic before it can block a payment. The decision log then doubles as the payment audit trail, which is what removes the separate evidence-gathering exercise at audit time.

Further reading

• AI-native engineering: how Bugni engineers governed platforms where AI participates in delivery.
• Designing a zero-trust LLM platform: agent-fabric: the design tenets behind running agents under zero trust.
• Observability as a compliance tool for banking: turning telemetry into audit evidence.
• Event-driven architecture for payments screening: the screening pattern referenced above.
• Case studies: delivery across screening, credit decisioning and core banking.