Offline provisioning of post-quantum certificates, air-gapped

Offline provisioning of post-quantum certificates for air-gapped networks means issuing, installing and managing quantum-resistant identity credentials (usually ML-DSA certificates) on encryption gateways that never reach a public certificate authority, update server or online validation service. Every step of trust, from key generation to revocation, is carried out through controlled manual procedures.

For OT operators this is not unusual. Substations, water treatment plants and pipeline compressor stations often run without any route to the internet. The difficulty is that most PKI guidance assumes protocols like ACME or EST and live OCSP responders. This article covers how to do the same work with removable media, signing ceremonies and well-chosen lifetimes.

How do you enroll a quantum-safe encryption gateway at a site with no internet connection?

You enroll it through a staged, offline ceremony: the gateway generates its own key pair, exports only a certificate signing request, and gets back a signed certificate plus the trust anchor on verified removable media. You can do this in a secure staging area before shipping, or on site with a technician.

Staging versus on-site enrollment

The two models differ mainly in where the risk sits. Staging concentrates the cryptographic work in one controlled room. On-site enrollment avoids shipping a device that already holds a valid identity.

Either way, the private key should never leave the gateway. The only things that cross the air gap are the CSR going out and the certificate, chain and CRL coming back.

The gateway also needs to work without outside services once it is installed. Quantum Network’s Quantum Gateway, for example, sends no telemetry, has no cloud dependency and supports air-gapped networks. With that kind of design, enrollment is the only stage that needs a deliberate data transfer.

How can ML-DSA certificates be issued and installed without an online certificate authority?

Run a two-tier PKI: an offline root CA that is powered on only for ceremonies, and an issuing CA that also stays off the network and signs gateway CSRs in batches. Certificates, chains and CRLs move in both directions on write-once or hash-verified media.

Choosing the signature algorithm per tier

FIPS 204 defines ML-DSA in three parameter sets, and the size of each set has practical effects on certificate chains and constrained devices:

• ML-DSA-65: 1,952-byte public key and 3,309-byte signature (NIST FIPS 204, Table 2, August 2024).
• ML-DSA-87: 2,592-byte public key and 4,627-byte signature (NIST FIPS 204, Table 2, August 2024).

A three-certificate chain therefore carries several kilobytes of signature data. That doesn’t matter for a USB transfer, but it does matter if your gateway firmware has fixed buffers for certificate parsing. Test full chains on the target hardware before the first ceremony.

A root that signs only a handful of times over its whole life can also use the stateful hash-based schemes in NIST SP 800-208 (LMS and XMSS). NIST describes these as “most appropriate for applications in which the use of the private key may be carefully controlled”. There is an operational condition, though: key and signature generation must be performed in hardware cryptographic modules that do not allow secret keying material to be exported. If you can’t track state reliably across ceremonies years apart, stateless ML-DSA is the safer choice.

A practical ceremony sequence

1. Export the CSR from the gateway to fresh media and record its SHA-256 hash on a paper form.
2. At the issuing CA, recompute the hash and compare it against the form before you sign.
3. Write the certificate, the full chain and the current CRL to new media, with a hash manifest.
4. Import on the gateway, verify the manifest, and confirm the certificate’s public key matches the key the gateway holds.

FIPS 204 lets you store an ML-DSA signing key as a compact seed: the 32-byte seed used as input to key generation serves as a compact signing key format. For CA keys this makes split, offline backup much easier, as long as the seed itself is protected as the full private key.

How do you establish initial trust between new gateways at isolated OT sites?

Initial trust comes from a root certificate (trust anchor) installed through a channel you physically control, then confirmed with a fingerprint check done by a second person. Once two gateways share that anchor, each can validate the other’s certificate without any network service.

This has always been the weak point of any PKI. The IETF X.509 profile authors (Housley et al.) call the distribution of trusted CA public keys “a security critical out of band process”. In an air-gapped OT setting, “out of band” should mean a written procedure with named roles, not an email attachment.

• Two-person fingerprint check: the technician reads the root fingerprint off the gateway display or console, and a remote engineer compares it against the value in the PKI register over the phone.
• Name constraints: issue each site’s gateway certificates with subject names tied to that site, and set the peer policy to accept only expected peer names, not any certificate from the root.
• Pinning for small estates: with only two or three sites you can pin peer certificates directly. IEC 62443-4-2 allows for this: in CR 1.9, the alternative to chain validation for self-signed certificates is deploying leaf certificates to all hosts that communicate with the subject.

How should certificate revocation work for quantum-safe gateways in air-gapped networks?

Use CRLs signed by the offline issuing CA, with a validity period longer than your site visit interval, and carry them in on the same verified media used for other maintenance. Back this up with certificate lifetimes short enough that expiry limits the damage if a revocation is missed.

IEC 62443-4-2 CR 1.9 expects components to validate certificates by checking a given certificate’s revocations status. Without network access, OCSP is not an option, so the CRL is the main tool. The IETF has long warned that if revocation information is untimely or unavailable, the assurance associated with the binding is clearly reduced.

Which key lifetimes and cryptoperiods suit post-quantum keys that are rarely rotated offline?

Use the per-key-type guidance in NIST SP 800-57 Part 1. It doesn’t change because the algorithm is post-quantum. Keep roots long-lived and well protected, keep gateway identity keys short enough that a scheduled maintenance visit can rotate them, and leave session keys to the protocol.

• Private signature keys: a maximum cryptoperiod of about one to three years is suggested (NIST SP 800-57 Part 1 Rev. 6 initial public draft, 2025).
• Private authentication keys: no more than one or two years, depending on its usage environment (same source).
• Classical algorithm sunset: NIST IR 8547 proposes that 112-bit quantum-vulnerable algorithms be deprecated after 2030, disallowed after 2035 (initial public draft, November 2024).

The draft also ties signing keys to certificates: when the corresponding public key has been certified by a CA, the cryptoperiod for a private signature key ends no later than the notAfter date on the last certificate issued. In practice, that means your gateway certificate lifetime is your rotation schedule.

Mapping lifetimes to OT maintenance cycles

The last row is where offline operation causes the least trouble. In QPN, for example, the hybrid classical and ML-KEM handshakes renew every two minutes with no operator involvement. The long-lived credentials are the ones that need planning.

The policy direction is clear. NSM-10, as quoted by NIST’s Dustin Moody, calls on agencies to “prioritize the transition of cryptographic systems to quantum-resistant cryptography” by 2035. Any root CA you create now for an OT estate will probably still be in service by then, so it should be post-quantum from the start.