The public web PKI industry is evaluating a new certificate model called Merkle Tree Certificates (MTCs). While the standard is still under development within the IETF PLANTS working group, the proposal is attracting significant attention because it aims to address a challenge facing the industry as post-quantum cryptography (PQC) becomes reality: how to maintain efficient, scalable certificate operations when cryptographic signatures become much larger.

For most organizations, the key takeaway is not whether MTCs ultimately become the dominant model. It is that the operational trends driving their development are already becoming clear.

MTCs are a proposed form of X.509 certificate that integrates public logging directly into the certificate model. Instead of relying solely on traditional certificate signatures, certificates can be validated through proofs that they exist within a publicly logged Merkle tree structure. This approach is intended to reduce overhead associated with shorter certificate lifetimes and larger post-quantum signatures while maintaining security and transparency.  

Importantly, MTCs are not a replacement for X.509. The current proposal describes them as a new form of X.509 certificate rather than an entirely separate PKI system.  

One of the strongest signals emerging from MTC discussions is the growing expectation that certificate lifetimes will continue to shrink. TLS certificates are under mandates to shorten through a phased approach, resulting in a 47-day lifespan by 2029. When it comes to MTCs, discussions have explored seven-day validity periods, but that period is not a finalized requirement in the current standard. The operational direction is nevertheless clear: more frequent certificate replacement increases the importance of reliable, repeatable processes.

• Certificate renewals and replacements may happen more frequently.
• Manual certificate workflows become harder to sustain at scale.
• Failures in issuance, deployment, or renewal need to be detected quickly.

For certificate teams, MTCs are as much an operations story as a cryptography story. Frequent renewals cannot depend on spreadsheets, fragmented scripts or tools, or one-off manual installations. Organizations need automation across the certificate lifecycle, including:

• Discovery and inventory
• Issuance and deployment
• Renewal and replacement
• Revocation and monitoring

Automated certificate lifecycle management (CLM) can help organizations reduce operational risk while preparing for changes in certificate formats, validity periods, and cryptographic standards. Organizations that already have CLM in place will be significantly better positioned to adapt to future certificate models.

MTCs may make automation even more important because certificate operations could involve retrieving, deploying, monitoring, and serving multiple certificate forms that become available at different times.

As certificate lifetimes continue to decrease, automated enrollment and renewal protocols become increasingly important.

The current MTC proposal describes standalone and landmark-relative certificates that become available at different times and may need to be served based on what the relying party supports. Managing that process manually would be difficult at scale. Whether organizations ultimately use ACME or other automation technologies, the underlying principle is clear: MTCs may make manual certificate management increasingly impractical.

Even when MTCs gain broad adoption, enterprises should not expect an immediate transition.

Existing applications, devices, infrastructure, and embedded systems are likely to move at different speeds. As a result, organizations may need to manage directly signed certificates alongside new MTC certificate forms as support evolves.

In fact, the current MTC proposal describes two certificate forms for the same underlying log entry: an initial standalone certificate and a smaller landmark-relative certificate that becomes available after the relevant landmark is allocated. Because the landmark-relative form only works with sufficiently up-to-date relying parties, servers may need to maintain both forms and select the appropriate one for each connection. This adds operational complexity that will be difficult to manage without automation.

The most important lesson from the MTC discussion may have nothing to do with MTCs themselves.

Whether the industry ultimately adopts MTCs, a different post-quantum certificate format, or a combination of approaches, organizations need the ability to adapt quickly as standards evolve. Google's post-quantum roadmap explicitly emphasizes cryptographic agility as a foundational capability for the future.

Organizations should focus on:

• Maintaining a complete inventory of certificates and cryptographic assets
• Implementing automated certificate lifecycle management
• Establishing a clear post-quantum readiness strategy
• Adopting technologies that support operational flexibility as standards evolve

The future of certificate management may include MTCs, but the organizations best prepared for that future will be those that invest in automation, visibility, and cryptographic agility today.