DC-003 Design scenario 2026-08-06

Design Case 3: The Board Wants Zero Trust, and That Is Not a Design

The bank buys a fintech with a flat network. The board, briefed by vendor marketing, mandates zero trust. Twelve months, legacy apps that cannot be touched, no downtime on payments. The design turns the buzzword into four testable properties and phases the work so a breach at month four hits a smaller target.

The scenario

The bank acquires a smaller fintech lender. The acquired company runs a flat network: once you are inside, everything is reachable. The board, briefed by vendor marketing, mandates “zero trust.” Integration has to complete within 12 months.

The acquired estate includes legacy applications that cannot be modified, with no modern authentication and no mutual TLS, plus payment-adjacent systems that cannot take downtime. The team is the bank’s existing security function and two engineers inherited from the acquisition.

The decision, sentence one

Deliver zero trust as a phased migration of trust decisions from network location to identity. Not as a product purchase, and not as a big-bang rebuild.

The board named a framework. The architecture’s job is to hand back testable properties: no implicit trust from network location, and every access authenticated, authorized, encrypted and logged. Anything that cannot be expressed as one of those four does not get budget, because it is marketing.

Moving the trust decision from network location to identityOn the left, the acquired fintech's flat network: one foothold reaches every application, database and store, because being inside is the whole authorisation. On the right, the same estate with an identity-aware proxy deciding per request on user and device, mutual TLS between workloads, policy-as-code authorisation, and legacy applications wrapped or segmented where the proxy cannot reach them. Underneath, the four testable properties the board's mandate has to become before it can be given a budget.BEFORE — TRUST FROM NETWORK LOCATIONOne footholdApp AApp BDatabasePaymentsAdminPII storeOnce you are inside, everything is reachable.AFTER — IDENTITY, EVALUATED PER REQUESTUser and deviceIdentity-aware proxydecides on every requestLegacy appwrapped, orsegmentedWorkloadWorkloadmTLSPolicy-as-code authorisation on every call.THE FOUR TESTABLE PROPERTIES — ANYTHING ELSE DOES NOT GET BUDGET1  No implicit trust from network location2  Every access authenticated3  Every access authorised and encrypted4  Every access logged
The left half is not a diagram of a bad network. It is a diagram of a network where being inside is the authorisation, which is a design choice that was reasonable when the perimeter was the building. The right half moves that decision to identity and makes it per request. The strip underneath is what the board’s word has to become before anyone can be held to it.

Scope

In: access paths across both entities, covering user to application, workload to workload, and administrator to production. Unification of the workforce identity plane. Protection of the crown-jewel data stores, meaning payment flows and customer PII.

Out: replacing or modifying the legacy applications. The acquired firm’s customer-facing product architecture. Corporate productivity networking beyond what the identity work touches. Each is a separate program with its own business case.

Constraints

Trust boundaries

  1. User to application. Currently defended by network location. This is the boundary the migration exists to replace with identity and device posture, evaluated per request.
  2. Workload to workload. The flat network’s real exposure. East-west movement with no internal authorization is how a single foothold becomes a breach.
  3. The acquisition boundary itself. Two organizations, two identity systems, two sets of privileged users, one unknown asset inventory. This is the vector in every integration post-mortem worth reading.
  4. The admin plane, doubled. Inherited privileged accounts with unknown provenance are the highest-risk access in the combined estate on day one.

Assumptions

  1. The acquired identity provider can be federated into the bank’s. If it cannot, workforce identity unification becomes phase zero and the timeline moves. Flagged to the board, not buried in an appendix.
  2. A credible asset inventory can be built inside 60 days. Every downstream decision inherits from this one, so it gets verified before anything else is promised.

Design commitments

1. Unify workforce identity before buying anything. Federate the acquired IdP into the bank’s, reconcile privileged accounts, and establish one source of truth for who anyone is. Every later control depends on identity being answerable.

Rejected: selecting a “zero trust platform” first. Tooling bought before identity is unified automates the confusion at scale, and does it on a three-year contract.

2. Identity-aware ingress in front of applications. Applications sit behind an identity-aware access proxy making per-request decisions on user identity and device posture, replacing VPN-and-network-location trust for user access. This is the pattern in my private Zero Trust reference build: identity-aware proxy at the edge, mutual TLS in the service mesh, policy-as-code authorization, all of it reproducible in Terraform.

Rejected: network-first microsegmentation as the opening move. It is necessary eventually. As step one it spends a year re-IP-ing a flat network, during which the flat network stays flat.

3. Wrap the crown jewels, then migrate by data sensitivity. Payment flows and customer PII stores get wrapped first, with proxied access, tightened egress and dedicated logging, without rebuilding them. Phases follow data sensitivity, not organizational convenience or whichever team volunteers.

Rejected: big-bang re-architecture. Twelve-month transformation programs that defer all risk reduction to the end tend to die at month eight with nothing shipped. Phasing that front-loads the crown jewels means a breach at month four hits a smaller target than it would have at month one, and smaller again by month seven.

Phasing order, and the blast radius it buys downTwelve months in four phases. Phase zero, the first sixty days, builds the asset inventory, federates the identity provider and reconciles privileged accounts, before any tooling is bought. Phase one wraps the crown jewels, meaning payment flows and customer PII stores. Phase two broadens identity-aware ingress in order of data sensitivity. Phase three contains the legacy applications as a written compensating control with an expiry review. The bar underneath shows the exposure a breach would carry, falling each quarter rather than only at the end.Phase 0 · days 0–60Asset inventoryIdP federationPrivileged accountsPhase 1Crown jewels wrappedPayment flows, PII storesProxied, egress tightenedPhase 2Identity-aware ingressbroadened in order ofdata sensitivityPhase 3Legacy containmentCompensating control,with an expiry reviewBLAST RADIUS OF A BREACHQuarter 1Quarter 2Quarter 3Quarter 4A breach at month four hits a smaller target than it would have at month one.Smaller again by month seven. Reported to the board as exposure reduced in money, never as percent complete.
The phases are ordinary. The bar underneath is the argument. A programme that delivers its risk reduction in the last quarter is a programme that carries full exposure through three quarters of an integration, which is exactly the window in which acquisitions get breached.

4. Legacy containment, named as what it is. Applications that cannot do modern authentication get wrapped by the proxy where it can reach them, and contained by network-level segmentation only where it cannot. Segmentation is used as a compensating control, written down as a compensating control, and given an expiry review date.

Rejected: modifying the legacy applications. That is risk without ownership. The people who understood those systems left two employers ago.

The risk statement

Acquisition integrations are the canonical breach scenario: a flat network, unknown assets and inherited privileged users, all during the exact period when everyone’s attention is on the deal. A breach through the acquired entity in year one costs regulatory penalty plus impairment of the deal’s rationale.

Against that, a phased identity-first program is the cheaper line item by an order of magnitude, and it buys measurable risk reduction every quarter instead of a promise at the end of the year.

First steps

First 60 days: build the asset inventory, federate the IdP and reconcile privileged accounts, and put identity-aware ingress in front of the two crown-jewel data stores. Report to the board as exposure reduced per quarter, in money.

Previous: Case 2, approving an AI vendor for KYC . Method and grounding: Design Cases .