Inherited Trust Is Not a Legacy Asset: Sequencing Zero Trust Through a UK M&A Integration
Photo: Federal Bureau of Investigation, Public domain, via Wikimedia Commons
A merger completes on a Friday. On the following Monday, two identity providers, two certificate authorities, three VPN concentrators and an unknown population of service accounts are expected to operate as a single estate. In practice they operate as two estates sharing a payroll calendar — and every trust relationship inherited from either side of the deal is now a trust relationship the combined business has never knowingly granted.
Zero trust does not arrive with the transaction. It has to be manufactured afterwards, deliberately, and in an order that keeps the audit trail intact. What follows is a phased approach for the twelve months after completion, written for the UK deal context in which regulatory notification, data protection obligations and integration engineering all run on the same clock.
Inherited trust is a liability, not an asset
In a mature single organisation, most trust relationships have an owner, a purpose and a review date. In a merger, a large minority have none of the three. The acquirer typically inherits federation trusts to partners it has never contracted with, service accounts created by a contractor who left in 2019, flat network segments justified by an application nobody can now name, and a supplier VPN that terminates into the same subnet as the HR system.
Finance writes down goodwill when a deal underperforms. Nobody writes down inherited trust. It simply propagates, quietly widening the set of identities that can reach the systems that matter most.
Phase zero: discovery that produces evidence, not diagrams
Diagrams are opinions with boxes on them. Discovery should output an evidence pack instead: an inventory of identity providers with their authentication protocols, PKI hierarchies and issuing authorities, DNS zones and conditional forwarders, egress and ingress points, remote access paths, privileged access workstations, and every machine identity with a named owner or, where no owner exists, an explicit gap record.
That evidence pack serves two UK audiences at once. Where a transaction is notifiable, the National Security and Investment Act 2021 places obligations on acquirers in relation to data infrastructure and critical suppliers; separately, the ICO expects pre-completion data sharing to rest on a lawful basis, with minimisation and, where appropriate, a clean-team arrangement. The same artefacts that satisfy a regulator — asset lists, data flows, access paths — are the ones a security architect needs. Build them once.
Do not rely solely on the seller's asset register. Sample it. Select thirty accounts at random and trace each one to a human being. The gap between the register and reality is the most useful single number the programme will produce.
Phase one: federate identity before you touch the network
The instinct is to flatten the network first, because flattening feels like visible progress. It is the wrong order. Every week the two identity estates remain separate is a week of duplicate accounts, local administrator sprawl and helpdesk-driven exceptions that will later need unwinding.
Sequence the work as follows.
- Establish one authoritative directory per population, with joiner, mover and leaver processes that fire on the first day of employment, not the thirtieth.
- Federate rather than merge. A SAML or OIDC trust between the two estates allows conditional access policy to be evaluated centrally while leaving the underlying directories intact, and it is reversible on a Friday evening if it must be.
- Migrate privileged identities first. The popular reverse order is wrong. Privileged identity is where inherited trust does most damage, and it is where exceptions are hardest to claw back later.
- Publish the retirement date for the bridge. A federation bridge with no end date is simply a new instance of the problem the deal was meant to solve.
The measure of success is not the number of accounts migrated. It is the number of authentication paths that no longer exist.
Phase two: write the merged policy as testable assertions
A merged security policy that lives as a document satisfies nobody. It should instead be a set of assertions that return pass or fail against the estate: no interactive authentication to a production segment from an unmanaged device; no service account with a credential older than ninety days; no inbound path from a third-party network without an identity-aware proxy in front of it; no administrative session from outside the UK without a managed, attested device.
Assertions give a board something readable and an auditor something samplable. They also resolve the harmonisation argument cleanly: where the two legacy policies disagree, the stricter rule holds until an owner justifies an exception in writing, with an expiry date.
Mapping the assertion set to the NCSC Cyber Assessment Framework and to ISO/IEC 27001 Annex A is worth doing once, at the start, so that the integration evidence can be reused at the next assurance cycle rather than rebuilt.
Phase three: segmentation without east-west inheritance
The governing rule is straightforward: no traffic crosses the old corporate boundary without an identity check and a logged decision. Build the merged segmentation model from the workload outward, not from the acquired network inward. Treat the acquired estate as what it temporarily is — an external network that happens to share a postcode and a brand.
In practice this means default-deny between the two legacy domains, a small number of explicitly justified east-west exceptions, and inspection points placed where the two estates meet rather than in the middle of each. Resist the temptation to create a single large shared services segment because it is convenient for the first three applications. It will be inconvenient for the next thirty.
Phase four: decommissioning is the closing balance sheet
Integration programmes are usually declared complete at cutover. That is precisely when the decommissioning debt begins to accrue.
Maintain a dated register with one line per item: legacy identity provider, VPN concentrator, federation trust, certificate, DNS zone, service account, firewall rule, and each with an owner, a removal date and a named approver. Report the burn-down monthly to the same forum that receives the migration dashboard, so that removal is measured with the same seriousness as delivery. A programme that can show 140 retired trust relationships in a year has done more for its risk position than one that can show a new portal.
Governance: one council, one clock
A joint trust council — security architecture, identity, network, data protection, internal audit, plus the acquired entity's technical lead — should own the sequence, arbitrate disagreements about the stricter rule, and hold the exception register. Report three things to the board: assertion pass rate, exception count over thirty days old, and the decommissioning burn-down.
What finished looks like
At day one hundred: a single authoritative directory per population, a federated trust with a published retirement date, and a baseline assertion set running weekly. At day three hundred and sixty-five: no unowned machine identities in production, no legacy VPN concentrator still accepting connections, and an evidence pack that can be handed to an assessor without a rebuilding exercise.
Two organisations merging is entropy increasing by default. The purpose of a zero-trust integration is to be the one programme in the building that consistently pushes in the other direction — and to leave behind the paperwork to prove it.
