M&A and Divestiture PKI Strategy: The Integration Nobody Plans For

When two companies merge, the integration plan covers systems, data, people, and processes in exhaustive detail. Somebody maps the ERP migration. Somebody maps the Active Directory consolidation. Somebody maps the email domain unification.

Almost nobody maps the PKI.

Trust anchors from the acquired company's private CA aren't trusted by the acquirer's systems — and vice versa. Certificate-dependent applications fail silently when presented with certificates from an unfamiliar CA hierarchy. Internal service-to-service encryption breaks when trust stores don't include the other side's root certificates. Client certificate authentication stops working for users who move between the two organisations' networks. Certificate lifecycle tools from one side have no visibility into the other side's certificate estate.

These problems surface at integration time — months after close, when operational pressure is highest and the teams responsible are already stretched across a dozen other integration workstreams. The window between "we discovered the PKI problem" and "this is blocking user migration" is typically weeks, not months.

Due Diligence: The PKI Questions to Ask Before Close

PKI due diligence isn't standard in most M&A playbooks, but the questions are straightforward and the answers reveal integration complexity early enough to plan for it.

Certificate estate inventory. How many certificates does the target operate? Across how many CAs? What's the split between public and private? What CLM tooling, if any, do they use? An organisation with 500 certificates from one public CA is a different integration challenge than one with 15,000 certificates across three public CAs and two internal CAs.

Private CA infrastructure. Does the target operate a private CA? If so, what platform (ADCS, EJBCA, Vault, Smallstep, cloud-managed)? Where are the root and issuing CA keys stored? Are there HSMs? Who has access? What's the certificate policy? The answers determine whether you can integrate the private CA into your hierarchy, migrate certificates to your CA, or maintain separate trust domains.

Trust anchor distribution. How are the target's root certificates distributed to endpoints? GPO, MDM, manually, baked into images? Understanding this tells you how hard it will be to extend your trust to their systems (and vice versa).

CA vendor contracts. What are the commercial terms with their public CAs? Can certificates be transferred to a new organisational entity? Are there volume commitments or long-term contracts that affect CA consolidation timing?

Certificate-dependent applications. Which applications depend on specific certificates, certificate chains, or trust anchors? This is the hardest question to answer and the most important. Applications that hardcode certificate paths, pin certificates, or validate against specific CA hierarchies will break during migration unless explicitly handled.

SCEP/NDES infrastructure. Does the target use legacy enrollment protocols for device certificate provisioning? If so, that infrastructure needs to be maintained during integration or devices will lose certificate enrollment capability. See SCEP/NDES Sunset Strategy.

Regulatory constraints. Are there regulatory requirements that affect how certificates or CAs can be changed? Financial services, healthcare, and government acquisitions often have specific requirements around cryptographic controls that constrain integration options and timelines.

Acquisition Integration Playbook

PKI integration in an acquisition typically follows three phases over 12-24 months. Compressing this timeline introduces risk; extending it increases operational overhead.

Phase 1: Cross-Trust (Months 1-3 post-close). Establish mutual trust between the two organisations' PKI hierarchies. For private PKI, this means distributing each organisation's root certificates to the other's systems. For public PKI, the certificates are already in the same trust stores (assuming both use publicly trusted CAs), but internal tools may need configuration updates to recognise certificates from the other organisation's CAs.

Cross-trust is a quick win that unblocks user and system migration without requiring any certificate re-issuance. It's also temporary — maintaining two parallel trust hierarchies indefinitely is an operational burden that should be resolved in Phase 2.

During this phase, consolidate certificate visibility. Both organisations' certificate estates should be discoverable and monitorable from a single observability platform, even if the underlying CA infrastructure remains separate. Your certificate observability should cover the combined estate from day one.

Phase 2: Certificate Estate Consolidation (Months 3-12). Migrate certificates from the acquired organisation's CAs to the acquirer's CAs. This is the bulk of the integration work. For public certificates, this means re-issuing from the acquirer's approved CAs, updating DNS and CAA records, and decommissioning the target's CA vendor relationships. For private certificates, this means re-issuing from the acquirer's internal CA, which requires trust anchor distribution to all of the target's systems.

Prioritise migration by risk and operational impact. Customer-facing certificates first (because they affect external trust). mTLS and authentication certificates second (because they affect user access). Internal service certificates third (because cross-trust covers them during migration).

Phase 3: CA Rationalisation (Months 12-24). Decommission the acquired organisation's CA infrastructure. Retire their root certificates from trust stores. Terminate their CA vendor contracts. At this point, the combined organisation operates under a single PKI architecture.

This phase is often delayed or deprioritised because the operational urgency decreases after Phases 1 and 2. But maintaining legacy CA infrastructure indefinitely is a security and operational liability — every additional trust anchor is an additional attack surface, and every additional CA vendor relationship is additional management overhead.

Divestiture: The Harder Direction

Divestitures — carving out a business unit into a separate entity — are harder than acquisitions from a PKI perspective because you're separating shared infrastructure rather than merging independent infrastructure.

The divested entity needs its own PKI. If the parent company operates a private CA, the divested entity's certificates were issued from that CA. Post-divestiture, those certificates remain valid but are issued by a CA the divested entity no longer controls. The parent company can revoke them at any time. The divested entity needs to stand up its own CA infrastructure and re-issue all internal certificates — often on an aggressive timeline defined by the transaction agreement.

Trust anchor separation is the mirror image of cross-trust. The parent company's root certificate needs to be removed from the divested entity's trust stores (eventually), and the divested entity's new root certificate needs to be distributed to its own systems. During the transition period, both root certificates coexist.

Public certificates need to be re-issued under the divested entity's domains. Domain ownership transfers must be coordinated with certificate issuance — you can't get a certificate for a domain you don't control, and domain transfer timing rarely aligns perfectly with certificate lifecycle timing.

The divestiture playbook should include: a Transitional Services Agreement (TSA) that covers continued certificate issuance from the parent's CA during the transition period (typically 6-12 months), a defined timeline for the divested entity to establish independent PKI, a certificate migration plan that maps every certificate to its new issuing CA, and a trust anchor transition plan that maintains access continuity during the switchover.

The Legal and Compliance Dimension

Certificate ownership in M&A transactions depends on the deal structure.

In an asset purchase, the acquirer buys specific assets. Certificates issued to the target company may not transfer — they're tied to the target's legal entity and domain ownership. The acquirer needs to re-issue certificates under their own entity, which requires domain transfers and new CA relationships.

In a share purchase, the acquirer buys the company. Certificates and CA relationships transfer with the entity. This is simpler from a certificate perspective but still requires integration of the CA infrastructure into the acquirer's operations.

Regulatory notification requirements vary by jurisdiction and industry. Some financial regulators require notification of material changes to cryptographic infrastructure. Some healthcare regulations require continuity of encryption controls during organisational transitions. These requirements can constrain the PKI integration timeline and must be identified early.

Sector guides: Financial services · Manufacturing.

---

← Back to Certificate Strategy: The Framework Most Organisations Skip

Related guides: PKI migration strategy, regulated PKI implementation.

External References

• NIST SP 800-53: Security Controls for Information Systems (relevant to CA governance in regulated acquisitions)
• CA/Browser Forum Baseline Requirements (domain ownership requirements for public certificate issuance)