TPM post-quantum keys VPN client: can hardware store ML-DSA?

TPM post-quantum keys for a VPN client means keeping the long-term private key that a remote access client uses to prove its identity inside a hardware root of trust, using ML-DSA (FIPS 204) or ML-KEM (FIPS 203) instead of RSA or ECC. On most laptops in service today, the hardware cannot do this yet. That fact should set the order of your migration.

For organisations running OT and critical infrastructure, remote access is often how engineers, integrators and on-call staff reach substations, pumping stations and control rooms. The client’s identity key decides who gets in. Moving that key to post-quantum algorithms is harder than moving a gateway’s key exchange, because it depends on chips you cannot patch.

Can a TPM 2.0 chip store ML-DSA or ML-KEM keys?

In practice, no: the TPM 2.0 chips found in current Windows laptops implement RSA and ECC, and they cannot generate or hold ML-DSA or ML-KEM keys. Post-quantum support has to arrive through new TPM specifications and new silicon or firmware, not through a driver update.

The Trusted Computing Group TPM 2.0 Library Specification defines the algorithms a TPM may implement. The revision widely referenced in IETF work is “Trusted Platform Module Library”, Family “2.0”, Level 00, Revision 01.83, March 2024, and the chips in the field were built against that revision or an earlier one. Academic work on quantum-resistant TPMs states it plainly: although TPM 2.0 targets laptops, servers and embedded systems, they are not quantum resistant, and QR cryptographic primitives and algorithms have to be implemented in hardware and integrated into the TPM.

Three practical points follow from this:

• Specification support is not fleet support. Even after the TCG adds post-quantum algorithms to the library specification, each TPM vendor still has to ship firmware or new parts, and each must pass validation again. Laptops bought this year may run for five years or more.
• Key sizes put pressure on TPM resources. TPMs have limited internal memory and slow interfaces. An ML-DSA-65 key is much larger than an ECC P-256 key (see the size table below), which affects how many keys a TPM can hold and how fast it can sign.
• Validation status matters. If your security policy requires FIPS 140-3 validated modules, check that the TPM’s validation covers ML-DSA or ML-KEM. Knowing that the chip implements the algorithm is not enough.

Source: IETF draft-prabel-pquip-pqc-guidance-00 (2025), parameter size tables for ML-KEM and ML-DSA.

Does the macOS Secure Enclave support post-quantum algorithms for VPN certificates?

The Secure Enclave was designed around RSA and ECC hardware, and VPN certificate identities on macOS have historically been ECC keys. Even if the enclave gains post-quantum primitives, that does not mean the VPN, certificate enrolment and EAP-TLS stack on macOS accept ML-DSA identities.

Published analyses describe the enclave’s public key accelerator as handling key generation, encryption and decryption, and digital signature services using RSA and elliptic curve cryptography (ECC). Apple has added post-quantum algorithms to its developer cryptography frameworks in recent OS releases. For a remote access deployment, though, the question is a chain of dependencies:

1. Can the enclave generate and use an ML-DSA private key on your hardware generation?
2. Can your MDM enrolment protocol request an ML-DSA certificate bound to that key?
3. Will the system keychain present that identity to the VPN client or to the 802.1X supplicant?
4. Does your relying party (VPN concentrator, RADIUS server, gateway) validate ML-DSA chains?

Every link has to hold. Test each one on the macOS versions and Apple silicon generations actually present in your fleet, and treat vendor announcements as a starting point, not as proof.

What happens to non-exportable RSA and ECC device certificates when you migrate?

They cannot be migrated. A non-exportable key is bound to one chip and one algorithm, so moving to ML-DSA means generating a new key pair and issuing a new certificate for every device. The old certificates stay valid until they expire or you revoke them.

This is often misunderstood. Changing the CA’s signing algorithm does not change the device’s own key. A laptop holding a TPM-bound ECC key with a certificate issued by an ML-DSA CA is still authenticated by ECC. What changes is that the CA signature on the certificate becomes quantum-resistant, which is useful but only half the job.

Expect the following during the transition:

• Parallel identities. Devices will carry a classical certificate and a post-quantum (or composite) certificate at the same time. Policy on the relying party decides which one is accepted for which network segment.
• Revocation at volume. Once a device has a working post-quantum identity, its classical certificate should be revoked or left to expire on a short lifetime. Do not let both stay valid indefinitely.
• Timeline pressure. NIST IR 8547 sets the reference dates: NIST will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035.

Which keys in a VPN client actually need hardware protection?

Only the long-term identity key needs hardware protection. Ephemeral key exchange keys, including ML-KEM keys, are generated per session and thrown away, so they never needed a TPM in the first place.

This distinction removes most of the pressure on TPMs and Secure Enclaves. The threat of traffic being recorded today and decrypted later sits in key exchange. Fixing it means adding ML-KEM to the handshake, which runs in the client’s memory and does not depend on the chip. Authentication is different: a forged signature is only useful to someone who holds a quantum computer at the moment of connection, so identity keys can move on a planned schedule.

Quantum Network’s QPN illustrates this split. Its software client for current Windows and macOS uses a hybrid key agreement in which a classical part and an ML-KEM part (FIPS 203) are combined into one session key, and both handshakes renew every two minutes. Those session keys are short-lived by design and do not need to sit in a TPM.

Should remote access client keys stay in software until hardware supports PQC?

For most OT operators, the better default is to keep the hardware-bound classical identity key for now, add hybrid ML-KEM key exchange right away, and move identities to ML-DSA once hardware or validated software modules are ready. Moving identity keys into software early swaps a long-term quantum risk for an immediate key theft risk.

The trade-off looks like this:

The composite option deserves attention for privileged OT access. Even if malware copies the software ML-DSA key, it still cannot use the hardware-bound classical key without the device. And a future quantum adversary able to forge the classical signature still has to beat ML-DSA as well. NIST describes this pattern simply: “Hybrid: using classical and PQC algorithms together.”

If you do keep ML-DSA keys in software for some time, limit the exposure: short certificate lifetimes, device posture checks before issuance, and keys limited to remote access rather than general-purpose signing.

How do you plan the device certificate refresh for Windows and macOS remote users during the move to ML-DSA?

Treat the refresh as a phased programme tied to hardware lifecycles: inventory first, then build the post-quantum PKI and distribute trust anchors, pilot with real chain sizes, and finally re-enrol devices as their hardware and OS versions qualify.

The time pressure is real. NIST notes that its deadlines leave little margin measured against the 10 to 20 years that previous cryptographic transitions have taken, and advises that organizations should treat the migration to PQC as a current operational priority.

Phase 1: Inventory what authenticates remote users

List every client certificate template, its key storage provider on Windows (TPM-backed or software), the keychain access settings on macOS, key algorithms, lifetimes and the issuing CA. NIST’s guidance is that organizations must identify where vulnerable algorithms are used and plan to replace or update them. Also record the TPM firmware versions and Apple silicon generations, because these decide when a device can hold a post-quantum key in hardware.

Phase 2: Build the post-quantum CA and distribute trust early

Stand up an ML-DSA (or composite) issuing hierarchy and push its root to Windows and macOS trust stores through your management tooling long before any device certificate depends on it. Trust anchors spread slowly, and remote users who rarely connect to the office network are always the last to receive them.

Phase 3: Test EAP-TLS and VPN paths with real chain sizes

Where remote users or site laptops authenticate with 802.1X, RFC 5216 (EAP-TLS) carries the certificate chain in fragmented EAP messages. With 3,309-byte ML-DSA-65 signatures and 1,952-byte public keys, a two-level chain grows a lot, so you get more fragments, more round trips and more chance of hitting timeouts on RADIUS servers and on OT-grade switches. Pilot on the slowest links you operate, such as cellular backhaul to remote sites.

Phase 4: Re-enrol in waves aligned to renewal dates

Phase 5: Enforce and retire

Once a device group has working post-quantum identities, change relying-party policy to require them for that group, then revoke the classical certificates. Keep a documented exception list for OT maintenance laptops that are tied to legacy engineering software, and review it every quarter.