A digital bank adopts zero trust. What actually changes in the architecture, and what is commonly mistaken for zero trust?
Show the full answer Hide the answer
What actually changes
Network location stops being a basis for trust. Every request is authenticated and authorised on its own merits regardless of where it originated, which has concrete consequences:
- Workload identity replaces network identity. A service proves what it is cryptographically — mutual TLS with short-lived certificates — rather than by being inside a trusted subnet.
- Authorisation on every hop, not only at the perimeter. Service A calling service B must be permitted to call that specific operation, and that policy must be enforced somewhere other than in A's own code.
- The user's identity propagates through the call chain, so a downstream service can authorise on the actual principal rather than on the calling service's blanket permissions.
- Access is short-lived and re-evaluated, rather than granted once at session start.
- Device posture and context become inputs for human access — a decision about a payout from an unmanaged device is different from the same request from a managed one.
What is commonly mistaken for zero trust
- Mutual TLS everywhere with no authorisation policy. Encrypted channels between services that will still do whatever they are asked. The identity is the point and the encryption is the mechanism, and stopping at the mechanism buys confidentiality against a threat model that already assumed network access.
- A VPN replacement, which is a remote-access improvement rather than an architectural change.
- Microsegmentation alone, which is finer-grained network trust rather than an absence of network trust.
- Buying a product. Zero trust is a property of how authorisation decisions are made, and no product supplies it without the authorisation model being built.
The realistic adoption path
Start with the highest-value boundary, not with everything. For a bank that is the money-movement path: workload identity, per-operation authorisation, user identity propagation, and short-lived credentials on that path first. Then extend.
A programme that attempts uniform coverage stalls, because the value arrives only at the end while the effort is continuous — and the eventual retreat discredits the approach.
The hardest part
Authorisation policy is a data problem, not a network problem. Deciding whether this principal may perform this operation on this resource requires a model of principals, resources and relationships that most organisations do not have. Building it is the actual work, and it is why zero trust programmes take years rather than quarters.