PKI standards are evolving faster than ever. Newly approved and pending requirements will soon reshape certificate management practices for organizations worldwide—and more changes are already on the way.

At the recent face-to-face meeting of the CA/Browser (CA/B) Forum in Warsaw, members advanced several proposals that will influence automation, validation methods, and post-quantum readiness across the Web PKI.

Here’s a look at the most significant developments and what they mean for certificate authorities, browser vendors, and enterprises relying on trusted digital identity.

Microsoft PQC Pilot

At the meeting, Microsoft announced that they’re launching a pilot program to support ML-DSA roots for TLS in its trusted root program. ML-DSA is the standard for PQC-compliant digital signatures. This will be a pilot program, for test purposes only, and not allowed for use in production systems.

To facilitate adoption once production capabilities are in the field, DigiCert is writing a draft ballot to allow ML-DSA in the CA/BF TLS Baseline Requirements.

Microsoft’s products are more influential in code signing. But since the digital signatures used in code signing have long lifetimes, the company decided it was best to test the more ephemeral TLS certificates.

Google Chrome team praises X9

Google’s unilateral sunsetting, via the Chrome Root Program, of support for certificates with client authentication enabled has created problems for mutual TLS (mTLS) applications that use public TLS certificates.

Because of the importance of the Chrome Root Program, public certificate authorities have all announced that they will no longer issue such certificates for the Web PKI. Currently, unless the customer specifically requests otherwise, new Web PKI TLS certificates issued by DigiCert will support only server authentication, as required by the Google root program. As of March 1, 2026, DigiCert will no longer issue such certificates.

But there’s an option for customers who need client authentication certificates that can be easily trusted externally: the DigiCert X9 PKI. At the CA/BF meeting, the Chrome team recognized the problem and mentioned X9 as a good alternative to the Web PKI for mTLS applications.

Chrome root program changes in the offing

The Chrome team announced several other updates they expect to add to the Chrome Root Program Policy, the current version of which is 1.7. The following changes are expected in version 1.8.

1. Automation support to become mandatory across the root program

The Chrome team announced an update that will require all certificate authorities to support certificate lifecycle automation. The current version has such a requirement for CAs applying for admission to the root program (see section 4.3.1 Automation Support), but the new requirement will affect existing CAs as well. 

2. For some time, the Chrome team has been advocating for the adoption of Merkle trees in a new standard for the Certificate Transparency logs called Photosynthesis. They reiterated this support at the CA/BF meeting.

Merkle trees are a data storage technique for tamper-evident data logging, best known for their use in the Bitcoin blockchain. The use of hashes in all nodes of the tree allows anyone to prove the accuracy of any specific logged transaction by validating the hashes from it up to the tree root.

The possible end of “manual” validation methods

In line with their advocacy for certificate automation, the Chrome team has formally proposed a ballot to the Server Certificate Working Group to eventually sunset all domain control validation (DCV) methods that aren’t automatable. The proposal, called a ballot in CA/BF procedure, is currently in a discussion period. The changes would include the end of support for all methods involving phone or email—methods that aren't amenable to automation and difficult or impossible to implement with Multi-Perspective Issuance Corroboration (MPIC), another CA/BF priority for the security of the Web PKI.

The first scheduled change in the ballot will happen March 15, 2026, with the sunsetting of method 3.2.2.4.8 (“IP Address”). In 2027 and 2028, support for all methods relying on email, phone contact, Fax, SMS, or Postal Mail would sunset.

Change remains the constant in PKI

The next few years will bring sweeping updates across the Web PKI. Now’s the time for organizations to assess their automation capabilities and ensure they’re ready for post-quantum-era requirements.

Watch for future DigiCert insights as these ballots move from proposal to policy.