In 2025, Sectigo initiated one of the most significant infrastructure changes in its PKI ecosystem, namely the migration of certificate issuance to new, proprietary Public Root Certification Authorities. This change affects all major product lines, including SSL/TLS certificates (DV, OV, EV) and S/MIME, and has a direct impact on how trust chains are built in browsers, operating systems, and server environments.

While for most end users the migration will be largely invisible, from the perspective of administrators, DevOps teams, security architects, and hosting providers it is a change that must be consciously considered when planning compatibility and service continuity.

Context: why does the root CA matter operationally?

A Public Root CA represents the highest trust anchor in the PKI model. Every browser and operating system maintains its own root trust store, which determines whether a given certificate is considered trustworthy. Changing a root CA is therefore not cosmetic and directly affects:

• the certificate validation process on the client side,
• compatibility with legacy devices,
• the behavior of applications using their own TLS libraries,
• the stability of integrations in closed environments (IoT, embedded, OT).

The Sectigo migration aligns with a broader trend of cleaning up and simplifying CA hierarchies, in line with current trust program requirements from Mozilla, Apple, Microsoft, and Google, as well as CA/B Forum recommendations.

What exactly is Sectigo changing?

Until now, Sectigo relied on historical and widely distributed root CAs, including USERTrust, often combined with extensive cross-signing. The new strategy assumes:

• a transition to new, dedicated Sectigo Public Root CAs,
• full presence of these roots in major trust stores,
• simplification of certification paths,
• reduction of long-term dependence on older legacy roots.

In practice, this results in a more predictable and controlled trust environment, while simultaneously requiring compatibility verification on the relying party side.

Migration schedule: key dates.

Sectigo is rolling out the changes in stages, depending on the certificate type:

• S/MIME from March 1, 2025.
• EV TLS from April 15, 2025.
• OV TLS from May 15, 2025.
• DV TLS from June 2, 2025.

After these dates, newly issued certificates will by default rely on the new root CAs. Existing certificates remain valid until the end of their validity period.

Impact of the migration on production environments.

In modern systems such as current versions of Windows, macOS, Linux, Android, iOS, and contemporary browsers, the change is in most cases transparent. Issues may arise in environments that:

• use manually managed trust stores,
• implement certificate pinning at the root or intermediate level,
• rely on older system images, containers, or appliances,
• use TLS libraries that do not automatically synchronize with the system trust store.

In such cases, root CA migration may manifest as TLS errors, certificate validation failures, or broken API connections.

Cross-signing as a transitional mechanism.

To reduce the risk of incompatibility, Sectigo applies cross-signing of new roots by older, widely recognized CAs. This mechanism allows certificates to be accepted by both modern and older environments.

However, cross-signing should be treated as a temporary solution, not a long-term strategy. Ultimately, organizations should aim to update systems and simplify their trust chains.

The significance of the migration in the broader PKI context.

The changes introduced by Sectigo are consistent with the overall direction of the PKI ecosystem:

• shortening and simplifying certification chains,
• eliminating historical compatibility compromises,
• preparing for future TLS changes, including post-quantum readiness,
• the growing importance of automation and proper trust store management.

For organizations managing a larger number of certificates, this is a good moment to review internal processes related to certificate installation, monitoring, and renewal.

FAQ: frequently asked questions about the Sectigo Root CA migration.

Do I need to replace certificates that are already installed?

No. Certificates issued before the migration dates remain valid until they expire. The migration applies only to newly issued certificates and reissues.

Will the migration affect SEO or Google rankings?

Not directly. As long as the certificate is correctly installed and the browser trusts the new root CA, the migration has no impact on SEO. Issues may arise only in the case of incorrect TLS configuration resulting in security warnings.

Can older devices stop trusting Sectigo certificates?

Yes, in extreme cases. This mainly affects very old systems, embedded devices, and applications with their own outdated trust stores. In such environments, updates or manual trust chain management may be required.

Can certificate pinning cause issues?

Yes. Pinning at the root or specific intermediate CA level may lead to failures after migration. Sectigo explicitly discourages this approach and recommends relying on standard PKI validation.

What about multi-year certificates?

In the case of multi-year subscriptions, certificates will be reissued according to the new root CA hierarchy once the migration dates are reached.

Do I need to change anything on the server?

In most cases, no. However, it is worth verifying that the server provides a complete and correct certificate chain and does not rely on manually defined, outdated CA bundles.

How to translate the Sectigo Root CA migration into real actions with HEXSSL?

The migration of Sectigo Public Root CAs is a good moment not only to ensure that a certificate works, but also to verify the entire TLS environment in a systematic way. In practice, this means combining analysis, monitoring, and automated diagnostics. This is exactly where HEXSSL serves as a control layer between the certificate authority and the production environment.

Verify the actual certificate chain of your domain.

The first step should be checking which certificate chain is actually delivered by the server to the TLS client, not just which certificate was installed.

➡ Use the SSL Checker to:

• view the full certification chain (leaf, intermediate, root),
• check whether the domain already uses the new Sectigo hierarchy,
• detect issues that may only surface after the Root CA migration.

This is the baseline reference point before making any changes.

Monitor issuer changes and certificate reissues.

During the Sectigo migration, some certificates may be reissued under the new hierarchy, especially within multi-year subscriptions or automated renewals. Without monitoring, such changes often go unnoticed until problems occur.

➡ Enable continuous monitoring with SSL Monitor to:

• receive alerts about issuer changes,
• maintain TLS configuration consistency across multiple domains,
• respond quickly to unexpected trust chain changes.

Monitoring is especially critical in production and multi-domain environments.

Automate diagnostics in technical environments.

If you manage a larger number of domains, APIs, or test environments, manual verification does not scale. Root CA migration should be treated as an infrastructure change, not a one-off incident.

➡ Use HEXSSL-CLI to:

• run automated HTTPS and HSTS tests,
• audit multiple domains in a single run,
• integrate TLS checks into CI/CD pipelines,
• detect differences between test and production environments.

This approach minimizes the risk of errors after deploying new certificates.

Organize certificate management in one place.

The migration of Sectigo Public Root CAs often exposes a lack of centralized visibility. Certificates may be scattered, documentation outdated, and responsibilities unclear.

HEXSSL enables you to:

• centrally manage your certificate portfolio,
• analyze the history of CA hierarchy changes,
• prepare for security and compliance audits,
• build a consistent TLS strategy instead of reacting to incidents.

This is particularly important for organizations that treat certificates as critical infrastructure rather than a one-time purchase.

The migration of Sectigo Public Root CAs is a fundamental but predictable and well-planned change. For modern environments it will be nearly invisible, while for legacy systems it may serve as a catalyst for necessary updates. From the perspective of security and long-term PKI stability, this is a step in the right direction. The migration itself does not constitute a threat. However, it is a moment when imperfections in TLS configuration and PKI management become visible. Instead of reacting only after problems occur, it is worth using this stage to strengthen control over certificates.

➡ Check your domain now with the SSL Checker.
➡ Enable monitoring with SSL Monitor.
➡ Automate audits with HEXSSL-CLI.

This approach allows you to go through the Sectigo Root CA migration in a predictable, controlled, and standards-compliant manner. Have questions about the migration? Feel free to contact us.

Additional information about the planned migration: Sectigo Public Root CAs Migration.