Automated post-quantum certificate enrollment EST CMP guide

Automated post-quantum certificate enrolment is when a network gateway requests, receives and renews X.509 certificates without manual steps. The certificates carry quantum-resistant keys, such as ML-DSA for signatures or ML-KEM for key establishment, and the requests go over standard protocols like EST (RFC 7030) or CMP (RFC 9810). For OT operators running many remote sites, this automation is what makes a post-quantum PKI workable at scale.

This article covers the protocol choices, the specific problem of certifying KEM keys, zero-touch bootstrapping at remote sites, and how to set renewal intervals for gateways that link sites, cloud environments and remote users.

Can EST or CMP issue ML-DSA certificates to network gateways automatically?

Yes. Neither protocol is tied to one signature algorithm. A gateway can generate an ML-DSA key pair, sign its request with it and receive a certificate, provided the CA, the registration authority and the gateway firmware all support the ML-DSA algorithm identifiers.

ML-DSA is the signature scheme standardised in FIPS 204. It was published and became effective on August 13, 2024. Because it is a signature algorithm, it fits the classic enrolment model: the private key signs the request, and that signature proves possession of the key.

EST (RFC 7030)

EST carries a PKCS#10 certificate signing request over HTTPS. For an ML-DSA key, the gateway signs the CSR with ML-DSA and the EST server forwards it to the CA. The protocol itself changes very little. The real work is upstream: the CA software, the certificate profile and any HSM behind the CA must all handle ML-DSA. The TLS session that carries EST is a separate question. If that channel still uses classical key exchange, enrolment traffic recorded today could be decrypted later, so protect it with hybrid key exchange where your TLS stack allows.

CMP (RFC 9810)

CMP is the more expressive protocol and the one the IETF has updated most directly for post-quantum use. RFC 9810 was published on 29 July 2025 as a 116-page Proposed Standard that obsoletes RFC 4210, and together with RFC 9811, it also obsoletes RFC 9480. Its authors describe the core change plainly: the document “adds support for management of certificates containing a Key Encapsulation Mechanism (KEM) public key” and uses EnvelopedData in place of EncryptedValue.

Size matters on OT links

Post-quantum keys and signatures are much larger than their elliptic-curve equivalents, and that has knock-on effects for every enrolment message.

A CSR, a certificate chain and a CMP-protected response can each carry several of these structures. On narrowband cellular or satellite links at remote substations, test the full exchange end to end before you roll it out across the fleet.

How does certificate enrolment work for a KEM key when the device cannot sign a request with it?

You replace signature-based proof of possession with encryption-based proof: the CA or RA encrypts something to the KEM public key, and the gateway proves it holds the private key by decrypting it. CMP under RFC 9810 supports this natively. EST under RFC 7030 does not.

A KEM such as ML-KEM (FIPS 203) can only encapsulate and decapsulate shared secrets. It cannot produce a signature, so a self-signed PKCS#10 request is impossible. The CMP update addresses this directly: for KEM keys, the end entity can provide the private key to the CA/RA (e.g., for archiving), or can be required to decrypt a value in order to prove possession of the private key.

The indirect method in practice

1. The gateway sends a CMP certificate request that contains its ML-KEM public key. The message is protected by an existing credential, such as a manufacturer identity or an ML-DSA certificate.
2. The CA issues the certificate but returns it encrypted to the KEM public key, using CMS EnvelopedData.
3. The gateway decapsulates, decrypts the certificate and confirms receipt in a certConf message containing a hash of the certificate.
4. The CA treats the confirmation as proof of possession and only then publishes the certificate as valid.

The CMS layer for step 2 is RFC 9629. That RFC defines conventions for the use of KEM algorithms by the originator and recipients to encrypt and decrypt CMS content. Its companion, RFC 9936, specifies the conventions for using ML-KEM with the Cryptographic Message Syntax (CMS) using the KEMRecipientInfo structure.

Binding a KEM key to a signing identity

Many gateways hold two keys: an ML-DSA key for authentication and an ML-KEM key for key establishment. A practical pattern is to enrol the ML-DSA certificate first, then use it to authenticate the request for the KEM certificate. The IETF and NIST communities are still discussing standard ways to do this. One proposal by Abel C. H. Chen, Mike Ounsworth, James W. H. Tung, John Gray and Austin B. Y. Lin, presented at NIST, aims to support the proof of possession for KEM and requests for paired signature and KEM certificates. Until these mechanisms settle, CMP’s encryption-based method is the standards-track option.

Is ACME suitable for renewing post-quantum certificates on edge devices that connect to my own data centre?

Usually not as the primary mechanism. ACME (RFC 8555) was built to prove control of DNS names and IP addresses. Gateways inside an OT network rarely have a public name or an exposed HTTP listener to validate, so EST or CMP against a private CA is generally the better fit.

In ACME, a client requests a certificate and the CA validates each incoming issuance request, e.g. with ACME challenges. Those challenges assume the CA can reach the device, or a DNS zone the device controls. That works for a web-facing service. It works poorly for a gateway behind a firewall at a pumping station whose only job is to build a tunnel back to your data centre.

ACME also does not remove the KEM problem. It still finalises orders with a PKCS#10 CSR, so it can carry ML-DSA keys if your ACME CA supports them, but it has no native proof-of-possession method for a KEM key.

How do I bootstrap trust for zero-touch enrolment of a new gateway at a remote OT site?

Use BRSKI (RFC 8995). The gateway proves its factory identity, receives a signed voucher naming your registrar as the trusted domain, and then enrols its operational certificate through EST. No technician has to load trust anchors on site.

The sequence has four parts:

• Factory identity: the manufacturer installs an initial device identity (IDevID, in the IEEE 802.1AR model) and a manufacturer trust anchor.
• Voucher: your on-site or central registrar asks the manufacturer’s authorisation service for a voucher. The voucher tells the gateway which domain CA to trust, so it does not have to trust the network it was plugged into.
• Operational enrolment: the gateway enrols a locally significant identity (LDevID) from your CA, ideally an ML-DSA certificate.
• Post-quantum upgrade: where the hardware supports it, a KEM certificate follows via CMP, authenticated by the new LDevID.

The classical anchor problem

Most factory identities shipping today use classical signatures. That is tolerable for a one-time bootstrap, but it sets a deadline. NIST IR 8547 lists ECDSA, EdDSA and RSA as deprecated after 2030 and disallowed after 2035. Ask suppliers when post-quantum or hybrid IDevIDs will be available. Also record in your asset inventory which installed gateways still rely on classical factory identities.

Air-gapped and intermittently connected sites

Where the gateway cannot reach the manufacturer, obtain vouchers in advance and carry them in at commissioning. Alternatively, run the registrar inside the isolated zone with a pre-provisioned trust anchor. CMP’s transport-independent messages can also be carried by file transfer and returned the same way. Some gateways are designed for this environment. Quantum Network’s QPN gateway, for example, sends no telemetry, has no cloud dependency and supports air-gapped networks, so whatever enrolment design you choose should not assume an outbound internet path.

How often should post-quantum gateway certificates be renewed automatically?

For internally issued gateway certificates, choose a lifetime that keeps renewal routine and testable, typically weeks to a few months. Trigger renewal well before expiry, so a site that is offline for several days still renews in time. Revisit lifetimes against the NIST 2030 to 2035 timeline.

No standard sets a single interval for private PKI gateway certificates. The right value balances three things:

• Exposure window: shorter lifetimes limit how long a compromised key stays valid when revocation checking is unreliable, which is often the case on OT links.
• Connectivity: a site that may be unreachable for a week needs a renewal trigger with at least that much margin, plus time for an operator to react to a failure alert.
• Algorithm agility: short lifetimes let you change parameter sets or move from hybrid to pure post-quantum profiles without a separate re-issuance campaign.

Policy deadlines to plan around

Public-sector deadlines are getting closer. National Security Memorandum 10 established the year 2035 as the primary target for completing the migration to PQC across federal systems. Executive Order 14412 accelerated this timeline, requiring federal high-value assets and high-impact systems to migrate by 2030 for key establishment and 2031 for digital signatures. For critical-infrastructure operators outside government these dates are not binding, but suppliers and CA software roadmaps will follow them.

NIST’s general guidance is direct: “organizations should begin migrating their systems to quantum-resistant cryptography”. Automated enrolment is how that migration reaches hundreds of remote gateways without a site visit to each one.