How PKIaaS Supports Secure Mergers and Acquisitions

When an acquisition closes, the IT integration checklist runs to dozens of items: network connectivity, directory services, email migration, ERP consolidation. PKI is rarely at the top of that list. It should be near it.

The acquired company’s certificate infrastructure is one of the least visible and most consequential things that transfers in a deal. It includes CA private keys that may have been generated without documented ceremonies, self-signed roots with unknown trust distribution, certificate estates that were never inventoried, and CP/CPS governance that ranges from mature to nonexistent. When those systems are connected to the acquirer’s network, the acquirer’s security posture absorbs all of that, immediately.

This post is written for CIOs, CISOs, and the PKI and security architects who support them through M&A programs. It covers the specific PKI risks that transfer in acquisitions, what a PKI due diligence assessment should contain, how to rationalize CA hierarchies after a deal closes, and why PKI as a Service is increasingly the consolidation vehicle that enterprise PKI programs reach for when they need to absorb an acquired environment without inheriting its technical debt.

Quick Answer: What Is the PKI Consolidation Problem in M&A?

When an organization is acquired, its CA hierarchies, certificate inventory, certificate policies, and PKI governance all transfer to the acquirer whether those assets were disclosed in due diligence or not. The consolidation problem is threefold: assessing what was inherited and whether it can be trusted; determining whether to absorb the acquired CA hierarchies into the acquirer’s PKI or replace them; and migrating certificate consumers from the old PKI to the consolidated infrastructure on a timeline that does not create outages or compliance gaps. PKIaaS addresses all three phases by providing a neutral, governed platform that acquired environment certificates can be migrated to, and a managed CA hierarchy that replaces the decommissioned acquired CAs without requiring the acquirer to build and operate the replacement infrastructure themselves.

Key Takeaways

• PKI is a material security asset that transfers in acquisitions. An acquired company’s CA hierarchy, certificate inventory, HSM infrastructure, and governance documentation all become the acquirer’s responsibility from day one of integration. Undocumented or poorly governed acquired CAs represent inherited trust risk that must be assessed and remediated, not assumed to be benign.
• The first 30 to 90 days after close should focus on PKI discovery and risk triage: enumerate every CA hierarchy the acquired company operated or depended on, assess the governance and key custody of each, and identify the certificate estate’s expiry profile to prevent outages during integration.
• CA hierarchy rationalization has three options: absorb the acquired hierarchy by subordinating it under the acquirer’s root CA; replace it by establishing new issuing CAs under the acquirer’s hierarchy and migrating certificate consumers; or temporarily bridge the two hierarchies with cross-certification while migration proceeds. Each option has different security, compliance, and operational implications. The right choice depends on the trustworthiness of the acquired CA’s key custody history.
• Certificate policy alignment is the governance work that underlies the technical consolidation. The acquired company’s certificate profiles, validity periods, subject validation procedures, and issuance authorization model must be assessed against the acquirer’s Certificate Policy and brought into alignment as part of the integration program.
• PKIaaS is particularly effective as the consolidation vehicle in M&A because it provides governed, FIPS-validated CA infrastructure that can absorb acquired certificate consumers through standard enrollment protocols (ACME, EST, SCEP, WSTEP) without requiring the acquirer to build net-new CA infrastructure to replace the acquired company’s systems.

What PKI Infrastructure Transfers in an Acquisition

Most M&A due diligence focuses on financial liabilities and intellectual property. PKI rarely gets a dedicated line item, which means the acquiring organization typically discovers the full picture of what was inherited during integration rather than before close. Understanding what transfers is the prerequisite to assessing the risk.

CA Hierarchies and Root CA Key Custody

The acquired company’s CA hierarchy, including the root CA and any intermediate or issuing CAs, transfers operationally to the acquirer. The critical question is not whether the CA exists but whether its key custody history is trustworthy. A root CA whose private key was generated without a documented ceremony, stored in a software keystore rather than a FIPS-validated HSM, or whose custody was held by a single administrator who has since left the company represents a materially different risk profile than a CA with documented M-of-N key ceremony records and hardware-protected keys.

If the acquired company used a self-signed root CA, the acquirer must determine how widely that root is distributed: which devices, applications, operating system trust stores, and browsers have been configured to trust it. The broader the trust distribution, the more complex the decommissioning process if the decision is made to replace the hierarchy rather than absorb it. Locating and removing a self-signed root from every trust store in a 10,000-device environment is a non-trivial undertaking if it was never inventoried.

The Certificate Estate

The acquired company’s certificate estate, meaning every certificate issued by or used within the acquired environment, transfers with the acquisition. This includes TLS certificates on servers and applications, device certificates on workstations and mobile devices, user certificates for email encryption and authentication, code signing certificates used in the acquired company’s build pipelines, and any certificates issued by the acquired company’s CA to third parties or partners.

The certificate estate’s expiry profile is the immediate operational risk. Certificates expiring in the first 90 days after close will fail without automated renewal, causing authentication failures and service outages at exactly the time when the integration team has the least capacity to respond. Identifying certificates expiring imminently and either renewing them under the acquired CA or migrating them to the acquirer’s CA before they expire is the first concrete action the PKI integration team should take.

Governance, Policy, and Compliance Documentation

The acquired company’s Certificate Policy (CP) and Certification Practice Statement (CPS), if they exist, define how certificates were requested, approved, issued, and managed. In practice, many acquired companies, particularly startups and mid-market firms, operated PKI without formal CP/CPS documentation. That absence does not mean the certificates were misissued, but it does mean the acquirer cannot verify that they were not.

For acquirers subject to compliance frameworks (SOC 2, PCI DSS, CMMC, FedRAMP, HIPAA), inherited certificates that cannot be traced to a documented, compliant issuance process may be considered out-of-scope for compliance attestation or may create audit findings. The acquired CA hierarchy and its governance documentation should be reviewed by the acquirer’s compliance team as part of the integration program, not post-audit.

PKI Due Diligence: What to Assess Before and After Close

PKI due diligence in M&A should happen at two stages: pre-close, as part of technical due diligence during the deal, and post-close, as part of the integration program’s first 30 days. Pre-close access to the target’s systems is often limited, so the pre-close assessment typically relies on documentation review and questionnaire responses. The post-close assessment can be a full technical discovery.

Pre-Close Assessment

The pre-close PKI questionnaire should cover these areas.

CA inventory: How many CA hierarchies does the company operate? Are any externally hosted or managed by a third party? Are any shared with partners or customers? What is the root CA for each hierarchy and when does it expire?

HSM status: Are CA private keys stored in FIPS 140-2 or 140-3 Level 3 validated HSMs? What is the NIST CMVP certificate number for the HSM(s) in use? Who has administrative access to the HSMs? Are M-of-N controls in place for root CA operations?

Certificate policies: Does the company have a published or documented CP/CPS? What certificate profiles are in use (TLS, S/MIME, code signing, device, user)? What is the approval process for certificate issuance?

Certificate inventory: How many certificates are currently active? What is the distribution of expiry dates? Are any certificates issued to third parties or partners?

Compliance: What regulatory frameworks apply to the company’s PKI? Have any audit findings related to certificate management been raised in the last 24 months?

Public CA relationships: Which public CAs does the company use for externally trusted certificates? Are domain validation records (CAA DNS records, domain validation contacts) current and documented?

Post-Close Technical Discovery

After close, the PKI integration team should conduct a technical discovery of the acquired environment. This involves running certificate discovery tools against the acquired network segments to enumerate all deployed certificates (active listening ports, configuration files, keystores), not just the certificates known to the PKI team. Certificate inventories maintained by the acquired company’s PKI team are almost always incomplete relative to what discovery tools find, particularly in environments with shadow IT or decentralized certificate procurement.

The discovery output should be analyzed to identify: certificates issued by the acquired company’s own CAs (which will need migration when those CAs are decommissioned); certificates issued by public CAs under the acquired company’s organizational name (which may need reissuance under the acquirer’s name); certificates that are already expired (and should be treated as an immediate remediation item); certificates with unusually long validity periods (pre-dating CA/Browser Forum baseline requirements, which may indicate legacy processes); and certificates with weak key parameters (RSA keys below 2048 bits, SHA-1 signatures, or other deprecated algorithms).

Encryption Consulting’s CertSecure Manager provides CA-agnostic certificate discovery across network segments, cloud environments, and certificate stores, producing the inventory baseline that M&A integration teams need to plan the consolidation program.

CA Hierarchy Rationalization: The Three Options

Once the acquired CA hierarchies have been assessed, the integration team must decide how to rationalize them. There are three structural options, each with different security, operational, and timeline implications.

Option 1: Absorb the Acquired Hierarchy

In this option, the acquired company’s root CA is subordinated under the acquirer’s root CA or the PKIaaS root CA. This preserves the acquired CA hierarchy’s chain of trust for existing certificates while bringing it under the acquirer’s governance framework. Certificates already issued by the acquired issuing CAs remain valid under their original chain; new certificates issued going forward are issued by acquirer-governed CAs in the same hierarchy.

This option is appropriate when the acquired CA’s key custody history is sound (documented ceremony, HSM-backed keys, verifiable M-of-N controls), the acquired root CA certificate has sufficient remaining validity to serve as a subordinate CA, and the trust distribution of the acquired root is narrow enough that managing it as a subordinate is operationally feasible.

The operational requirement for this option is that the acquired root CA’s private key must be available for a cross-certification ceremony that creates the subordination relationship. If the key is not available, not in hardware, or custody is uncertain, this option is not viable without unacceptable risk.

Option 2: Replace the Acquired Hierarchy

In this option, new issuing CAs are established under the acquirer’s root CA (or the PKIaaS root CA), and all certificate consumers in the acquired environment are migrated to enroll from the new issuing CAs. The acquired company’s CA hierarchy is decommissioned after all certificates issued by it have either expired or been replaced by certificates from the new hierarchy.

This option is the correct choice when the acquired CA’s key custody history is undocumented or untrustworthy, when the acquired root CA is self-signed and broadly distributed in trust stores that are difficult to update, when the acquired CA’s certificate profiles do not meet the acquirer’s policy requirements, or when a clean security break is the priority over continuity of the existing trust chain.

The timeline challenge with replacement is migrating all certificate consumers before the acquired CA is decommissioned. This requires the CLM layer to track which certificates are still issued by the old CA and which have been replaced, and to enforce a deadline after which the old CA is revoked and decommissioned. Certificates that have not been migrated before decommissioning will fail authentication.

Option 3: Bridge the Hierarchies Temporarily

In this option, a bridge CA is created that cross-certifies the acquirer’s root and the acquired company’s root, establishing mutual trust between the two hierarchies. This allows certificates from either hierarchy to be validated by systems anchored to either root, enabling integrated operations while the longer-term migration is executed.

Bridge CAs are appropriate as a temporary integration measure in large acquisitions where the migration timeline will span 12 to 24 months and immediate mutual authentication between the two environments is operationally critical. They are not appropriate as a permanent architecture decision: a bridge CA adds complexity to the trust model, creates additional revocation and monitoring obligations, and leaves both CA hierarchies in production simultaneously, doubling the governance burden.

Any bridge CA established as part of an M&A program should have a documented sunset date and a tracked migration plan that ensures all certificate consumers in the acquired environment are migrated to the consolidated hierarchy before the bridge is decommissioned.

Certificate Policy Alignment: The Governance Work Behind the Technical Consolidation

Technical CA hierarchy rationalization is the visible work of M&A PKI consolidation. Certificate policy alignment is the governance work that underlies it and is equally important for organizations with compliance obligations.

The acquired company’s certificate profiles define what information was validated before certificates were issued, what extensions and key usages were included, what validity periods were used, and who was authorized to approve issuance requests. These policies may differ substantially from the acquirer’s. Common misalignments include:

• Validity period misalignment: Acquired environments often have long-lived certificates issued under historical policies (3 to 5 year TLS certificates, 10-year device certificates) that exceed the acquirer’s current policy or CA/Browser Forum requirements for publicly trusted certificates. These certificates must be identified and scheduled for replacement on a timeline that does not disrupt operations.
• Subject validation gaps: The acquired CA may have issued certificates to organizational units or department names that do not map to the acquirer’s organizational structure, or may have validated subject information less rigorously than the acquirer’s policy requires. Certificates with inaccurate or misaligned subject information may need to be reissued under the acquirer’s validated naming conventions.
• Profile proliferation: Acquired environments often have accumulated certificate profiles that reflect ad hoc requests over years of operation, resulting in dozens of profiles where the acquirer’s policy might define five. Rationalizing profiles as part of the consolidation program reduces ongoing governance complexity.
• Authorization model gaps: The acquired company’s certificate issuance authorization model (who could request certificates, what approval was required, whether requests were logged and auditable) may not meet the acquirer’s standards. Establishing the acquirer’s authorization model in the consolidated environment requires configuring the CLM layer to enforce the correct approval workflows for acquired-environment users and systems.

The output of certificate policy alignment work is a revised CP/CPS that covers the consolidated PKI program, including how acquired-environment certificate consumers are governed going forward. For organizations subject to SOC 2, PCI DSS, CMMC, or FedRAMP, the CP/CPS revision is an audit artifact that demonstrates that certificate policy governance has been extended to the acquired environment, not left as an undocumented gap.

Why PKIaaS Is the Right Consolidation Vehicle for M&A

Historically, the options for PKI consolidation after an acquisition were limited: absorb the acquired CA into an existing self-managed PKI (requiring the acquirer’s PKI team to take on expanded operational scope), or rebuild the acquired PKI from scratch on the acquirer’s infrastructure (expensive, slow, and still increases the internal team’s operational burden). PKIaaS changes the calculus by providing a third option: migrate both the acquirer’s and acquired environment’s certificate consumers to a managed, governed CA platform, reducing the total operational burden rather than just redistributing it.

Speed of Deployment

A PKIaaS provider can have a new issuing CA operational in weeks, not months. For an M&A integration team facing certificate expiry risk in the acquired environment from day 30, the ability to establish a governed issuing CA rapidly and begin migrating certificate consumers before the legacy CA expires is a material operational advantage over building a self-managed replacement.

Enrollment Protocol Coverage

M&A integration involves absorbing an environment that may use different enrollment protocols, MDM platforms, and DevOps toolchains than the acquirer’s existing environment. A PKIaaS provider that supports ACME (RFC 8555 with External Account Binding), EST (RFC 7030), SCEP, WSTEP with on-premises Active Directory agent, and CMP (RFC 4210) can serve certificate consumers in the acquired environment using the protocols those systems already support, without requiring the acquired environment’s systems to be reconfigured to use the acquirer’s existing enrollment infrastructure before migration can proceed.

This matters particularly for MDM-managed device fleets. If the acquired company managed its devices through a different MDM platform (Jamf rather than Intune, or Workspace ONE rather than Jamf), a PKIaaS provider with native integrations for multiple MDM platforms can serve both device fleets from a single CA without requiring the acquiring organization to migrate all acquired devices to its preferred MDM as a prerequisite to certificate consolidation.

Governance Portability

One of the recurring complications in M&A PKI consolidation is that the acquirer’s existing PKI governance (CP/CPS, certificate profiles, issuance authorization workflows) was designed for the acquirer’s organizational structure and does not cleanly accommodate the acquired company’s organizational units, naming conventions, or business units. A PKIaaS provider supports multiple certificate profiles, organizational units, and authorization workflows within a single CA hierarchy, enabling the consolidated PKI to serve both organizations’ certificate consumers under a unified governance framework without requiring the acquired organization’s users and systems to immediately conform to the acquirer’s naming and policy standards.

No Incremental Infrastructure Investment

Absorbing an acquired environment’s certificate consumers into a self-managed PKI requires capacity planning and potentially additional HSM hardware, CA software licenses, and HA/DR infrastructure. These are capital expenditures that emerge from the acquisition integration program at a time when the organization may already be under budget pressure from deal costs. PKIaaS converts this to a subscription cost that scales with the certificate volume being migrated, without requiring upfront capital expenditure on infrastructure that must be sized for peak consolidated load before the migration volume is known.

Data Sovereignty in Cross-Border M&A

Cross-border acquisitions introduce data sovereignty considerations that affect PKI consolidation architecture. An acquired company operating in the EU under GDPR, in Germany under BSI requirements, in the UK post-Brexit, or in a jurisdiction with local data localization requirements may have regulatory constraints on where CA key material and certificate metadata can be stored and processed.

For PKI consolidation in cross-border M&A, confirm with the acquiring organization’s legal counsel and the PKIaaS provider: the countries in which CA key material will be stored and processed after consolidation; whether the PKIaaS provider can offer geographic key restriction as a contractual commitment for the acquired environment’s certificates; and whether the consolidated PKI program will be subject to a new regulatory framework in the acquirer’s jurisdiction that differs from the acquired company’s existing compliance obligations.

Some cross-border M&A programs require a regionally segmented PKI architecture: the acquirer’s global PKIaaS root CA, with region-specific issuing CAs whose key material is restricted to the relevant geographic boundary. This is a supported architecture in most enterprise PKIaaS deployments and should be designed into the consolidation program from the outset rather than retrofitted after a regulatory finding.

A Phased Migration Approach

M&A PKI consolidation rarely happens in a single event. The practical approach is a phased migration that prioritizes by risk and operational impact.

Phase 1 (Days 1 to 90): Discovery and triage. Run certificate discovery across the acquired environment. Build the certificate inventory with expiry profile, issuing CA attribution, and system dependency mapping. Identify certificates expiring in the next 90 days and establish emergency renewal procedures (either renewing under the acquired CA on short notice, or accelerating migration to the acquirer’s CA). Assess acquired CA key custody and make the hierarchy rationalization decision (absorb, replace, or bridge).

Phase 2 (Months 3 to 12): Infrastructure establishment and migration. If replacing the acquired hierarchy, establish the new issuing CAs under the acquirer’s PKIaaS root. Configure enrollment protocol connectors for the acquired environment’s systems (ACME for web servers and DevOps, SCEP or WSTEP for MDM-managed devices, EST for network infrastructure). Begin migrating certificate consumers in prioritized order: short-lived certificates first (TLS on internet-facing systems), then internal server certificates, then device certificates, then user certificates. Maintain the CLM layer’s tracking of which certificates have been migrated and which remain on the legacy CA.

Phase 3 (Months 12 to 24): Legacy CA decommissioning and policy consolidation. Once all certificate consumers have been migrated to the consolidated CA hierarchy, decommission the acquired CA infrastructure. Remove the acquired root from trust stores on devices and servers that still carry it. Publish updated CRL and OCSP responses indicating the acquired CA is decommissioned. Complete the CP/CPS revision to incorporate the now-consolidated certificate policy. Validate that the CLM layer’s inventory no longer shows any active certificates attributed to the decommissioned CA.

How Encryption Consulting Can Help

Encryption Consulting provides M&A PKI due diligence, consolidation architecture, and managed PKI services for acquirers navigating the inherited trust risk and operational complexity of post-acquisition certificate infrastructure.

• PKI Assessment Service: For organizations in active M&A integration, Encryption Consulting’s PKI Assessment Service provides a structured assessment of both the acquirer’s and acquired company’s PKI programs, producing a gap analysis, a hierarchy rationalization recommendation, and a consolidation roadmap with phased migration priorities. This is the fastest path to a defensible integration plan.
• PKI as a Service: Encryption Consulting’s PKIaaS offering provides the governed, FIPS 140-3 HSM-backed CA infrastructure that acquired environments can migrate to, with ACME, EST, SCEP, WSTEP, and CMP enrollment support for diverse acquired-environment system types and MDM platforms. Contact us at Encryption Consulting to discuss your M&A integration timeline and requirements.
• CertSecure Manager: Encryption Consulting’s CertSecure Manager provides the CA-agnostic certificate discovery and CLM layer required for M&A PKI consolidation, with the ability to inventory certificates issued by the acquired company’s CAs, public CAs, and the consolidated PKIaaS CA in a single unified view. Migration tracking, expiry monitoring, and automated renewal across all CA sources make it the operational backbone of a multi-phase consolidation program.
• PKI Services: For organizations that need expert support on the governance side of consolidation, including CP/CPS revision to cover the acquired environment, certificate profile rationalization, and issuance authorization model design for the consolidated PKI program, Encryption Consulting’s PKI Services cover the full advisory engagement from consolidation architecture through go-live.
• Compliance Advisory Services: For acquirers whose M&A program spans regulated environments (CMMC, FedRAMP, PCI DSS, HIPAA, DORA), Encryption Consulting’s Compliance Advisory Services provide support for mapping the consolidated PKI program against the applicable compliance frameworks and producing the evidence documentation that demonstrates compliant certificate governance across the integrated organization.
• HSM as a Service: For acquired environments whose CA key material was stored in software keystores rather than HSMs, migration to Encryption Consulting’s HSM as a Service provides FIPS 140-3 Level 3 certified HSM capacity for the consolidated CA infrastructure, resolving the hardware security gap that frequently emerges as a due diligence finding in acquired environments.

Conclusion

PKI consolidation in M&A is one of the most under-planned elements of IT integration programs and one of the more consequential. An acquired company’s CA hierarchy and certificate estate represent a combination of operational risk (certificates expiring without renewal, legacy CAs with no managed successor), security risk (inherited root CAs with undocumented key custody, certificates issued without subject validation), and compliance risk (governance gaps that become audit findings when the acquirer’s compliance program extends to the acquired environment).

The organizations that handle M&A PKI consolidation well share a common approach: they treat PKI as a material asset in due diligence rather than an afterthought; they run certificate discovery in the acquired environment within the first 30 days; they make a deliberate hierarchy rationalization decision (absorb, replace, or bridge) based on the assessed trustworthiness of the acquired CA’s key custody; and they use a CLM layer that maintains a unified certificate inventory across the legacy and consolidated CAs throughout the migration program so that no certificate falls through the gap between the two systems.

PKIaaS is particularly effective as the consolidation vehicle because it provides governed CA infrastructure rapidly, supports the diverse enrollment protocols that acquired environments already use, and does not require the acquirer’s internal team to take on expanded operational scope at the same time they are managing the integration program’s other workstreams.

If your organization is in pre-close due diligence, early integration, or mid-consolidation on an acquisition and needs structured support for the PKI program, reach out to Encryption Consulting. We have supported PKI due diligence and consolidation programs across multiple M&A transactions and can help your team build a plan that is technically sound, operationally realistic, and defensible to auditors.

This post is reviewed on a six-month cadence and immediately when material changes in PKI standards, compliance frameworks, or data sovereignty regulations affect M&A PKI consolidation architecture.

Frequently Asked Questions

What PKI risks does an acquiring organization inherit in a merger or acquisition?

Acquiring organizations typically inherit: CA private keys that may have been generated without documented ceremonies or M-of-N controls; self-signed root CAs with unknown trust distribution; expired or soon-to-expire certificates on production systems that were never tracked; overly broad certificate profiles; CAs with no CP/CPS documentation; undocumented trust stores on servers and devices; and certificates issued by public CAs under the acquired company’s name that may need revocation and reissuance. Each represents a concrete security or compliance exposure requiring assessment and remediation during the integration program.

How long does PKI consolidation typically take after an acquisition?

A small acquisition with a simple CA hierarchy and a certificate estate under 1,000 certificates can complete consolidation in 3 to 6 months. A large acquisition involving multiple CA hierarchies, complex certificate profiles, regulated-industry compliance requirements, and geographically distributed infrastructure typically requires 12 to 24 months. The first 30 to 90 days should focus on discovery and risk triage; the middle phase on hierarchy rationalization and migration; and the final phase on decommissioning legacy CA infrastructure and validating the consolidated trust model.

What is a bridge CA and when is it used in M&A PKI consolidation?

A bridge CA establishes cross-certification between two independent CA hierarchies, allowing certificates from either hierarchy to be trusted by systems anchored to either root. In M&A, it serves as a temporary measure enabling mutual authentication between the acquirer’s and acquired entity’s systems during the consolidation period. Bridge CAs should be treated as temporary with a defined sunset date, not a permanent architecture decision. The preferred long-term outcome is a single unified hierarchy with the bridge decommissioned once migration is complete.

Can PKIaaS import or subordinate an existing CA hierarchy from an acquired company?

Yes. PKIaaS platforms support importing an external root CA to subordinate an existing hierarchy. If the acquired root CA’s private key is available and the key custody model permits it, the acquired issuing CAs can be subordinated under the PKIaaS root. Alternatively, new issuing CAs can be established under the PKIaaS root to replace the acquired hierarchy with fresh issuance while existing certificates run to their natural expiry. The correct approach depends on whether the acquired CA’s root key can be trusted or whether a clean break is preferable.

What is the difference between certificate migration and certificate replacement in an M&A context?

Certificate migration moves management of existing certificates to the acquirer’s PKI or CLM platform without replacing the certificates themselves; they remain valid under their original issuing CA until natural expiry, at which point they renew under the consolidated hierarchy. Certificate replacement proactively revokes and reissues all affected certificates under the acquirer’s hierarchy before their natural expiry. Replacement is required when the acquired CA is being decommissioned before existing certificates expire, or when compliance frameworks require certificates to be issued under a specific auditable CA.

What should be in a PKI due diligence checklist for M&A?

A PKI due diligence checklist should cover: all CA hierarchies operated or used by the target; FIPS validation status of HSMs used for CA key storage; documentation of root CA key generation ceremonies and custody; existence of CP/CPS documents; mapping of certificate consumers that depend on the target’s CAs; expiry profile of the certificate estate; identification of any compromised or revoked certificates; public CA relationships and domain validation records; data sovereignty requirements affecting CA key storage locations; and integration touchpoints (MDM platforms, SIEM, IdPs, DevOps toolchains) that rely on the target’s PKI.