How to Migrate One Million Certificates to PKIaaS Without Causing Outages

A million-certificate PKI migration sounds like a multi-year project that only the largest enterprises with dedicated PKI teams could attempt. In practice, migrating a million certificates to PKI as a Service is not a million individual operations. Most of those certificates migrate through their natural renewal cycle, handled by automation clients that have been reconfigured to request renewals from PKIaaS instead of the legacy CA. The migration program is the work of establishing that automation; the automation does the actual migration.

The outage risk in any PKI migration is not from moving certificates. It is from moving them incorrectly: distributing the new PKIaaS root CA certificate to trust stores after some certificates have already been issued under it; producing certificates with incorrect profiles that applications reject; or revoking legacy CA infrastructure before all the certificates it issued have been replaced. These are avoidable risks with the right migration sequence.

This playbook covers the ten phases of a PKIaaS migration at enterprise scale: from the initial discovery that reveals what you are actually migrating, through the phased rollout that avoids cutover risk, to the post-migration governance that ensures the legacy CA never comes back. The phases are designed to be executed in sequence, with each phase’s completion criteria serving as the entry condition for the next.

Quick Answer: How Does a Million-Certificate PKIaaS Migration Actually Work?

The migration works in three operational modes running simultaneously. Automated certificates (those already managed by cert-manager, ACME clients, MDM enrollment, or autoenrollment) migrate by reconfiguring the automation client to point at the PKIaaS enrollment endpoint; the next renewal cycle completes the migration for that certificate without touching the application. Manual certificates (those provisioned by hand and renewed by hand) are migrated proactively in priority order, starting with those expiring soonest. Long-lived, infrequently renewed certificates are left to the passive renewal window unless the legacy CA must be decommissioned before they expire. The active migration program takes 4 to 9 months; the full passive renewal window adds another 12 to 18 months for the tail of the estate.

Key Takeaways

• The migration is not a cutover. Roots of trust cannot be swapped instantly without causing failures; the migration runs the legacy CA and PKIaaS in parallel during the transition period. Legacy CAs remain operational and their CRL/OCSP infrastructure remains active until every certificate they issued has expired or been replaced. Planning for this coexistence period is the first design decision in any PKI migration.
• Discovery always reveals more than the CA team knows. Network certificate discovery finds certificates issued by shadow CAs, public CAs that bypassed the internal CA, expired certificates still in use, and certificates with weak key parameters. The discovery output determines what the migration is actually migrating, which is nearly always larger and more complex than the initial estimate.
• Certificate profile mapping is the highest-risk technical preparation step. Every legacy CA template must be reproduced as a PKIaaS certificate profile with correct EKU OIDs, subject name source mappings, validity periods, and SAN constraints. A profile mapping error produces a certificate that enrolls successfully but that the application rejects, typically at exactly the wrong time.
• Automating the bottom 60% of the estate first produces the greatest risk reduction with the least effort. Automated certificates migrate with a configuration change, not a manual operation. Getting 600,000 automated certificates off the legacy CA in the first 30 to 60 days of the rollout reduces the remaining migration scope to the 400,000 that actually require attention.
• Post-migration governance is the reason migrations succeed or fail a year later. An organization that completes the migration but does not establish ongoing automation coverage metrics, certificate policy enforcement, and new certificate issuance controls will find its PKI estate reverting to manual issuance and shadow CA usage within 18 months.

Phase 1: Discovery and Inventory (Weeks 1 to 3)

The discovery phase produces the baseline inventory that everything else in the migration depends on. Do not proceed to any subsequent phase without a complete, verified certificate inventory. Attempting to design a migration program against an incomplete inventory is the most common cause of migration surprises that turn into outages.

Run both sources of discovery simultaneously:

CA-side discovery: Export the issued certificate database from every CA in scope (internal enterprise CAs, any departmental or application-specific CAs, and any externally hosted managed PKI services already in use). The CA database provides the authoritative list of what has been issued, when it expires, and from which template or profile. It does not tell you where those certificates are deployed or whether they are still in use.

Network and host discovery: Run active network certificate discovery against all internal network segments to find certificates on live TLS endpoints. Also scan configuration management databases (CMDB), certificate stores on servers, Kubernetes Secret stores, MDM certificate inventories, and application configuration files. Network discovery finds what is actually deployed, including certificates not in the CA database (issued by other CAs, self-signed, or issued before the CA system was in place).

The output of these two discovery passes produces the master certificate inventory with the following attributes for each certificate: serial number, subject DN, SANs, issuing CA, expiry date, key algorithm and size, signature algorithm, EKU OIDs, deployed locations (hostnames, IP addresses), enrollment protocol (if known), and owning team or business unit. This inventory is the migration’s source of truth. It should be loaded into the CLM platform that will govern the migration and the post-migration environment.

Discovery typically takes 1 to 3 weeks depending on network size and the accessibility of remote segments. Budget for the discovery to find approximately 20 to 40% more certificates than the CA team’s initial estimate. Shadow PKI (self-signed certificates, certificates from public CAs purchased without PKI team involvement, certificates issued by development CAs that were never decommissioned) is endemic in large enterprises and is almost always undercounted before discovery runs.

Phase 2: Segmentation and Prioritization (Weeks 2 to 4)

After discovery, segment the certificate estate into migration cohorts. The segmentation drives the migration sequence and automation approach for each cohort.

Cohort A: Expiring within 90 days (migrate immediately). Any certificate expiring within 90 days is an immediate outage risk. These get the highest migration priority regardless of their category. If the PKIaaS infrastructure is not yet ready to issue renewals (because the root ceremony has not occurred yet), these certificates should be renewed under the legacy CA immediately to extend the runway. Migration of their automation is a day-one priority once PKIaaS is operational.

Cohort B: Automatically renewable (migrate via automation reconfiguration). All certificates already managed by automation clients that can be reconfigured without touching the consuming application: cert-manager Certificate resources in Kubernetes, ACME clients on Linux servers, MDM SCEP enrollment profiles (Intune, Jamf, Workspace ONE), and AD autoenrollment via WSTEP. This cohort migrates when the automation client is pointed at the PKIaaS enrollment endpoint; the next renewal cycle completes the migration. For large enterprises, this cohort is typically 50 to 70% of the total estate.

Cohort C: Internet-facing TLS (migrate proactively, high business impact). Certificates on internet-facing web servers, APIs, and load balancers. These are high-impact failures if they expire or behave incorrectly. Migrate proactively before their renewal windows to validate the PKIaaS profile configuration under controlled conditions.

Cohort D: Internal application and service certificates (migrate in waves). Internal TLS, service-to-service authentication certificates, application server certificates. Migrate in waves after Cohort B and C are validated. These typically have standard renewal cycles and can be migrated through automation reconfiguration once profiles are validated.

Cohort E: Long-lived, infrequently renewed (passive migration window). Certificates with 3 to 5 year validity periods that have reliable automated renewal and whose renewal dates are more than 12 months out. Leave these to the passive migration window; the automation will renew them from PKIaaS when their renewal window arrives. Monitor via CLM to confirm renewal is occurring correctly.

Cohort F: Manual and orphaned (remediate separately). Certificates that are manually managed, not associated with any current system in the CMDB, or have weak key parameters (RSA-1024, SHA-1 signatures). These require individual investigation. Some will be migrated manually; some will be allowed to expire; some reveal shadow PKI that needs to be retired.

Phase 3: Certificate Profile and Policy Mapping (Weeks 3 to 6)

For each active legacy CA template or certificate profile in the discovery inventory, create a corresponding PKIaaS certificate profile that reproduces the template’s certificate content. This is the highest-risk technical preparation step. A profile mapping error produces certificates that enroll successfully but that applications reject, typically at the moment of deployment or at the next TLS handshake.

Profile mapping must be reviewed by someone with hands-on knowledge of how each certificate type is used. The key fields to map correctly are:

• Key Usage and Extended Key Usage OIDs: Confirm exact OIDs against what applications check. Client authentication, server authentication, code signing, S/MIME, and Kerberos PKINIT all have specific OIDs. Missing any one causes the application that checks for it to reject the certificate, even if every other field is correct.
• Subject DN source: Where does the Subject CN come from? For machine certificates, typically the hostname from AD. For user certificates, the display name from AD. For service certificates, a fixed string or a field from the enrollment request. Document the source for each field and confirm the PKIaaS profile’s subject population rules reproduce the same output.
• Subject Alternative Name types and sources: For web server certificates, the SANs are typically requester-supplied. For machine certificates, the DNS SAN comes from AD. For user certificates, the UPN SAN comes from AD. Confirm that the PKIaaS profile’s SAN rules produce the same SAN values as the legacy template.
• Validity period: Match the legacy template’s validity period unless there is a specific reason to change it (the CA/B Forum 47-day schedule for public TLS certificates, or an organizational policy change that takes effect with the migration).
• CA/B Forum compliance: If any migrated certificates will be used for public TLS (not just internally trusted), they must comply with CA/B Forum Baseline Requirements. If the legacy CA issued some certificates with non-compliant profiles (for example, using internal domain names in SANs), those profiles cannot be reproduced in PKIaaS issuance and the certificate consumers must be updated to use compliant subject and SAN values before migration.

Produce a written profile mapping document that maps each legacy template to its PKIaaS profile equivalent, with field-by-field comparison for the fields above. This document is reviewed by the pilot group migration team before the pilot begins and serves as the reference for validating certificates issued during the pilot phase.

Phase 4: PKIaaS Infrastructure Setup (Weeks 4 to 8)

Set up the PKIaaS CA hierarchy, conduct the root CA key ceremony, and configure the enrollment endpoints before any migration begins. Specifically:

Root CA key ceremony: For customer-hosted or hybrid deployments, conduct the root CA key ceremony per the procedure in your CP/CPS. For vendor-hosted deployments, schedule the ceremony with the PKIaaS provider. Do not proceed with migration until the ceremony is complete and the evidence package is in hand.

Enrollment endpoint configuration: Configure the ACME endpoint (for Linux and Kubernetes), EST endpoint (for network devices and constrained endpoints), SCEP endpoint (for MDM and legacy OT), and WSTEP proxy (for Windows AD autoenrollment). Deploy the WSTEP proxy before updating any GPO. Validate each endpoint with a test enrollment before the pilot phase.

Root CA trust distribution: Distribute the new PKIaaS root CA certificate to all domain machines via the Trusted Root Certification Authorities GPO policy. Allow at least one full Group Policy refresh cycle (90 minutes default, or triggered manually with gpupdate /force) before any certificate is issued by the PKIaaS CA to any machine in the domain. A machine that receives a PKIaaS certificate before the PKIaaS root is in its trust store will not trust its own certificate, causing exactly the failure the migration is designed to avoid.

CLM connectivity: Connect the CLM platform to both the legacy CA and the PKIaaS CA. The CLM provides the unified certificate inventory that tracks migration progress, identifies certificates that have not migrated on schedule, and catches expiry risks during the migration period when both CAs are active. Encryption Consulting’s CertSecure Manager supports connectors for both legacy CA systems and PKIaaS providers, providing this dual-CA inventory from the start of the migration program.

Phase 5: Pilot Group Migration (Weeks 7 to 10)

The pilot migrates a controlled subset of the estate, typically 500 to 2,000 certificates across each certificate type in scope, before any production rollout begins. The pilot is not a test of the concept; it is a test of the specific profiles, automation configurations, and monitoring that will be used in production. Pilot certificates must come from real production certificate consumers, not test environments with different configurations.

The pilot validation checklist for each certificate type:

• Issued certificate has the correct issuer (PKIaaS CA, not the legacy CA)
• Subject DN matches the expected value from the profile mapping document
• SANs are present and match expected values
• Key Usage and EKU OIDs match the profile mapping document
• Certificate chains correctly to the PKIaaS root CA that is now in the consuming system’s trust store
• The application or protocol using the certificate validates successfully (TLS handshake completes, 802.1X authentication succeeds, smart card logon succeeds, etc.)
• OCSP response for the new certificate returns “good” from the PKIaaS OCSP responder
• The certificate appears in the CLM inventory attributed to the PKIaaS CA, not the legacy CA

Any pilot failure is a blocker for the production rollout. Do not proceed to Phase 6 until all pilot failures are diagnosed, the root cause is identified in the profile mapping or enrollment configuration, the configuration is corrected, and the corrected pilot certificates pass all validation checks. The pilot is the most important investment in outage prevention in the entire migration program.

Phase 6: Automation Tooling Deployment (Weeks 8 to 14)

Before the staged rollout begins, the automation tooling for each cohort must be deployed and configured. The automation is what makes migrating 600,000 certificates feasible without a proportional increase in the migration team’s headcount.

Kubernetes and cloud-native (Cohort B): Update cert-manager ClusterIssuer resources to point at the PKIaaS ACME endpoint with EAB credentials. For each Certificate resource, confirm the issuerRef points to the PKIaaS ClusterIssuer. On the next renewal trigger (when the certificate’s remaining validity falls below the renewBefore threshold), cert-manager automatically requests the renewal from PKIaaS. No manual action is required per certificate.

Windows AD autoenrollment (Cohort B): Update the Certificate Enrollment Policy in the domain GPO to point at the PKIaaS WSTEP proxy endpoint as the primary CEP server, with the legacy CA CEP as the secondary fallback. Apply the GPO to the pilot OU first (verified in Phase 5), then stage to production OUs per the rollout sequence in Phase 7. Domain machines automatically enroll from PKIaaS on the next Group Policy refresh or autoenrollment trigger.

MDM-enrolled devices (Cohort B): Update the SCEP or PKCS certificate profile in Intune, Jamf, or Workspace ONE to point at the PKIaaS SCEP endpoint. On the next device MDM check-in or forced sync, the MDM platform delivers the updated profile and the device renews its certificate from PKIaaS. For Intune with native PKIaaS integration, the NDES server is eliminated from the architecture.

Linux servers and DevOps (Cohort B and C): Update ACME client configurations (certbot, acme.sh, or HashiCorp Vault ACME) to use the PKIaaS ACME endpoint URL. Infrastructure-as-code tools (Terraform, Ansible, Puppet) that provision certificates should be updated to use the PKIaaS REST API or ACME endpoint. For CI/CD pipelines, update the OIDC exchange configuration to obtain certificates from PKIaaS.

Network devices (Cohort D): Update SCEP profile configurations on network devices to point at the PKIaaS SCEP endpoint. For devices managed through a network management system, update the template configuration centrally. For individually configured devices, update during the next maintenance window.

Phase 7: Staged Rollout by Cohort (Months 3 to 7)

The staged rollout executes cohort migrations in priority order, with defined success criteria and rollback triggers for each cohort before proceeding to the next. The sequence is Cohort A (immediate expiry risk), then B (automated, broadest scope), then C (internet-facing TLS), then D (internal applications), with E proceeding passively in the background.

For each cohort, define:

Go criteria: What must be true before this cohort’s rollout begins. Typically: pilot for this certificate type passed all validation checks, automation tooling for this cohort is deployed and tested, CLM shows the cohort’s legacy CA certificates in inventory, and the PKIaaS OCSP and ACME endpoints are confirmed healthy from monitoring.

Success criteria: What constitutes a successful cohort migration. Typically: X% of cohort certificates are now attributed to the PKIaaS CA in CLM inventory; zero enrollment failures in the automation logs; application-level monitoring shows no authentication failures attributable to certificate issues; OCSP response for all new certificates returns “good.”

Rollback trigger: The specific condition that triggers an immediate rollback for this cohort without waiting for further escalation. Typically: more than 1% of the cohort’s certificates producing validation errors at the application layer; OCSP response failing for more than a defined threshold of the new certificates; any certificate with a profile discrepancy that could cause a downstream application failure.

Cohort B (automated certificates) is the highest-leverage cohort. Reconfiguring cert-manager, AD autoenrollment, and MDM enrollment profiles to point at PKIaaS moves the largest volume of certificates with the lowest per-certificate effort. In a 1-million certificate estate where 60% are automated, migrating Cohort B moves 600,000 certificates in 4 to 8 weeks of automation reconfiguration work across a PKI team of 3 to 5 people.

Phase 8: Legacy CA Coexistence Management (Ongoing During Rollout)

During the migration period, two CA hierarchies are simultaneously active. Managing the coexistence period correctly prevents the most common migration outage: a legacy CA certificate expiring during migration without being renewed by PKIaaS because the system’s automation was not reconfigured in time.

The CLM layer is the operational tool for coexistence management. It should be configured to display the migration status of every certificate in the estate: which CA issued it, whether the automation for this certificate has been reconfigured to use PKIaaS, and how much time remains before it expires. Configure CLM alerts for legacy CA certificates that are within 60 days of expiry and have not yet migrated. These are the certificates at risk of expiring without a PKIaaS replacement if the migration schedule slips.

The legacy CA must remain fully operational during the coexistence period. Its CRL publication schedule must be maintained so that legacy CA-issued certificates can still be validated by systems checking revocation. Do not modify the legacy CA’s CRL distribution points, OCSP configuration, or CA certificate trust chain during the migration. Any disruption to legacy CA revocation infrastructure during the migration period will cause failures for the certificates that have not yet migrated.

Track migration velocity weekly: what percentage of the total estate is now attributed to the PKIaaS CA in CLM, what percentage remains on the legacy CA, and whether the migration is proceeding at the pace required to complete before the legacy CA decommissioning target date. If velocity is below plan, identify whether the gap is in the automated cohorts (configuration not deployed yet), the manual cohorts (insufficient team capacity for manual migration), or the passive cohort (certificates with long validity not yet reaching their renewal windows).

Phase 9: Legacy CA Decommissioning (Months 12 to 24)

Legacy CA decommissioning is the final step, and it must not be rushed. Decommission the legacy CA before all its certificates have been replaced or expired causes an immediate outage for every certificate still in service under that CA. The CLM inventory is the gating control: do not proceed with decommissioning until the inventory confirms zero active certificates attributed to the legacy CA.

The decommissioning sequence:

• Confirm through CLM that zero active certificates remain attributed to the legacy issuing CA
• Revoke the legacy issuing CA certificate from the legacy root CA
• Publish a final CRL from the legacy issuing CA that reflects the revocation of all certificates it ever issued. This final CRL should have a validity period extending beyond the longest validity of any certificate the CA ever issued, so that revocation lookups for any old certificate can still be answered from the cached CRL
• Keep the legacy CRL distribution points accessible for the full CRL validity period
• Remove the legacy root CA certificate from the domain Trusted Root Certification Authorities via GPO, piloting on a non-critical OU before applying domain-wide
• Archive the legacy CA database, HSM (or CA software state), and ceremony evidence for the retention period required by your compliance framework

Phase 10: Post-Migration Governance

Post-migration governance is what separates a permanent improvement from a temporary improvement that reverts within two years. Organizations that complete a PKI migration but do not establish ongoing controls for the post-migration environment find their certificate estate drifting back toward manual issuance, shadow PKI, and the same operational debt they migrated away from.

Automation coverage metric: Define and track the percentage of certificates in the environment that are managed by automation (cert-manager, MDM enrollment, ACME clients, autoenrollment). Target 90% or above for new certificates after the migration is complete. Any new certificate that enters the environment without automation coverage should be treated as a process exception requiring remediation.

Certificate issuance gate: Update the organization’s certificate request process to require that all new internal certificates be requested through the PKIaaS enrollment automation (ACME, EST, SCEP, WSTEP) rather than through manual CSR submission. Manual CSR submission is still supported for special cases, but requires an approval workflow and a CLM entry that tracks the manual certificate for renewal. This prevents the accumulation of manually managed certificates that drove the original migration necessity.

Policy enforcement in CLM: Configure the CLM to flag policy violations continuously: certificates with key sizes below the current minimum, signature algorithms below the current standard, validity periods exceeding current policy, or certificates issued outside the approved PKIaaS CA. Policy violations should route to the owning team for remediation on a defined timeline, not to a spreadsheet that gets reviewed quarterly.

Certificate estate growth management: Enterprise certificate estates grow 8 to 12% annually as new services, devices, and workloads are added. Post-migration governance must include a regular review of coverage: are new application deployments requesting certificates through the PKIaaS automation, or are developers provisioning self-signed certificates and bypassing the PKI program? CLM discovery should run continuously, not just at the point of migration, to catch new unmanaged certificates before they become outage risks.

CA/B Forum 47-day schedule preparation: CA/B Forum Ballot SC-081v3 (approved April 2025) reduces the maximum public TLS certificate validity to 47 days effective March 15, 2029. For organizations migrating to PKIaaS before that date, the migration is an opportunity to establish cert-manager or ACME automation with the shorter validity period from the start, rather than having to retrofit automation for a certificate estate that was managed manually under 1-year or 90-day validity. Post-migration, confirm all public TLS certificates are renewed by automation with appropriate advance renewal windows (14 to 21 days before expiry for 47-day certificates).

Migration Timeline Summary

Phase	Timeline	Key output	Gating condition for next phase
1. Discovery and inventory	Weeks 1 to 3	Complete certificate inventory with expiry profile	Inventory loaded into CLM with attribution and expiry data
2. Segmentation and prioritization	Weeks 2 to 4	Cohort definitions and migration sequence	Cohort A identified and emergency renewals complete
3. Profile and policy mapping	Weeks 3 to 6	Profile mapping document, field-by-field comparison	All active templates mapped; document reviewed and approved
4. PKIaaS infrastructure setup	Weeks 4 to 8	Operational PKIaaS CA; root in trust stores; endpoints validated	Root distributed; all enrollment endpoints responding to test enrollments
5. Pilot group migration	Weeks 7 to 10	Validated pilot certificates per certificate type	All pilot validation checks pass; no profile or chain errors
6. Automation tooling deployment	Weeks 8 to 14	Automation configured for Cohorts A, B, C, D	Automation tested in pilot; validated renewal for each cohort
7. Staged rollout by cohort	Months 3 to 7	60% to 80% of estate on PKIaaS	Success criteria met per cohort before next cohort begins
8. Coexistence management	Months 3 to 18	CLM dual-CA inventory; no expiry gaps	Ongoing; resolves as passive cohort migrates through renewal
9. Legacy CA decommissioning	Months 12 to 24	Legacy CAs retired; trust stores cleaned	CLM confirms zero active legacy CA certificates
10. Post-migration governance	Ongoing	Automation coverage metrics; policy enforcement; CLM discovery	Permanent operational state

How Encryption Consulting Can Help

• PKI Assessment Service: Encryption Consulting’s PKI Assessment Service produces the discovery baseline, cohort segmentation, and profile mapping document that Phase 1 through 3 of this playbook require. For organizations that need an independent assessment before committing to a migration approach, the assessment provides a defensible migration plan with effort estimates and risk analysis.
• PKI as a Service: Encryption Consulting’s PKIaaS offering is the destination CA infrastructure for the migration, with ACME+EAB for cert-manager and Linux automation, native Intune and Jamf MDM integration eliminating NDES from the architecture, WSTEP proxy for AD autoenrollment, SCEP for network devices and legacy OT, and REST API for infrastructure automation tools. Contact us at Encryption Consulting to discuss your migration scope and timeline.
• CertSecure Manager: Encryption Consulting’s CertSecure Manager provides the CLM layer that makes the migration manageable: unified inventory across the legacy CA and PKIaaS CA from day one of the migration; cohort tracking and migration velocity metrics; expiry alerts for legacy CA certificates that have not yet migrated; and the continuous discovery that post-migration governance requires to catch new unmanaged certificates before they become outage risks.
• PKI Services: For organizations that need hands-on expert support through the profile mapping, pilot validation, or automation tooling deployment phases, Encryption Consulting’s PKI Services provide advisory and implementation support through each phase of the migration playbook, with particular depth in AD CS template migration, cert-manager ClusterIssuer configuration, and MDM enrollment automation.
• CBOM Secure: For organizations whose migration also involves rationalizing legacy cryptographic algorithm usage (RSA-1024, SHA-1, or 3DES certificates found in discovery), Encryption Consulting’s CBOM Secure provides the cryptographic inventory and algorithm posture assessment that guides remediation priorities alongside the certificate migration program.

Conclusion

Migrating a million certificates to PKIaaS is a program, not a project. The active migration phases take 4 to 9 months. The passive renewal window for the tail of the estate adds 12 to 18 months. The post-migration governance is permanent. Organizations that plan for the program’s full timeline and invest in the discovery, profile mapping, automation, and CLM infrastructure that supports it complete the migration without outages and emerge with a certificate program that is materially better governed than what they started with.

The organizations that struggle with PKI migrations are typically not the ones that encountered technical problems. They are the ones that underestimated discovery scope, skipped the pilot validation phase under time pressure, or tried to decommission the legacy CA before the CLM confirmed migration completeness. The playbook above is designed to prevent each of those failure modes with specific gating conditions that cannot be bypassed without explicit risk acceptance.

The CA/B Forum 47-day validity schedule, effective March 15, 2029, makes the migration urgent. Organizations that arrive at that date still managing a large TLS certificate estate manually, renewing 90-day or 1-year certificates by hand, will face an immediate operational crisis as the renewal frequency triples. Migrating to PKIaaS automation before that date is risk mitigation for a known, dated regulatory event.

If your organization is planning a PKIaaS migration and wants to validate the approach before committing to a program, reach out to Encryption Consulting. We have executed and advised on enterprise PKI migrations across financial services, healthcare, defense, and critical infrastructure environments.

This post is reviewed on a six-month cadence and when the CA/B Forum publishes updates to the SC-081v3 certificate validity reduction schedule or when cert-manager, Intune, or Jamf publish significant changes to their PKI integration models.

Frequently Asked Questions

How long does it take to migrate one million certificates to PKIaaS?

The active migration program (discovery through staged rollout) takes 4 to 9 months. The passive renewal window for long-lived certificates adds 12 to 18 months. Full legacy CA decommissioning typically occurs 12 to 24 months from program start. Most of the estate migrates through automated renewal reconfiguration rather than individual certificate replacement, so the program scales without requiring proportional team growth.

Do all one million certificates need to be replaced at once?

No. Most certificates migrate through their natural renewal cycle. When automation is reconfigured to point at PKIaaS, the next renewal cycle replaces the certificate without touching the consuming application. Proactive replacement is only required for certificates expiring before the automation can handle their renewal, or when the legacy CA must be decommissioned before all its certificates expire naturally.

How should certificates be prioritized for migration?

Highest priority: certificates expiring within 90 days. Second: automatically renewable certificates (cert-manager, MDM-enrolled, ACME-automated, AD autoenrollment) because they migrate via configuration change, not per-certificate work. Third: internet-facing TLS (high business impact if incorrect). Fourth: internal applications and services. Passive renewal handles long-lived certificates with reliable automation. Manual and orphaned certificates require individual investigation and remediation.

What is the risk of causing outages during a PKIaaS migration?

The primary outage risks are: PKIaaS root CA not in trust stores before first certificates are issued; profile mapping errors producing certificates that applications reject; enrollment failures leaving systems without a certificate; and legacy CA revocation before all its certificates have migrated. Each is addressed by specific gating conditions in the playbook: root distribution before any certificate issuance, pilot validation before production rollout, CLM monitoring for enrollment failures, and CLM confirmation of zero active legacy CA certificates before decommissioning.

When can the legacy CA be decommissioned after migrating to PKIaaS?

The legacy CA should be decommissioned only after CLM confirms zero active certificates attributable to it remain in the environment. The decommissioning sequence: confirm zero active certificates in CLM, revoke the legacy issuing CA from the legacy root, publish a final CRL with validity extending beyond the longest certificate the CA ever issued, maintain CRL distribution points for the full CRL validity period, then remove the legacy root from trust stores via GPO (piloting on a non-critical OU first).