Stop inventorying keys.

If you have a reason to migrate to post-quantum cryptography (PQC), you should not be inventorying keys for the purpose of migration, and you should stop listening to anyone who suggests that you do so. You should not be creating a cryptographic bill of materials. You should not be running cryptographic discovery tools. A key inventory is the wrong place to start a migration, and will result in an intractable to-do list based on the wrong abstraction, while simultaneously missing the most urgent part of the problem.

There are two problems when it comes to post-quantum cryptography: the store-now, decrypt-later (SNDL) attack on key establishment and the future threat of man-in-the-middle (MITM) attacks by a quantum computer. While both attacks are equally important, only SNDL is urgent, since it is a threat to current traffic from a future computer.

The most common SNDL risk comes from ephemeral key establishment in a synchronous online protocol where a one-time-use shared secret is generated by two parties and used to bootstrap symmetric encryption for the rest of the connection. In the pre-quantum world, this is usually (elliptic curve) Diffie-Hellman. If this key can be calculated by a passive observer¹, then that observer can decrypt the rest of the connection. Far and away, the most common instance of vulnerability to SNDL occurs in the TLS handshake. Luckily, there are standardized solutions to the threat from SNDL. ML-KEM-768+X25519 hybrid key agreement is a quantum-resistant key establishment algorithm that can be used in place of elliptic curve Diffie-Hellman in TLS.

A key inventory will not identify this threat! If your post-quantum migration begins with a key inventory, you will never encounter the ephemeral key exchange in TLS because it is ephemeral. The keys are used once. They are not persisted to disk. Any TLS implementation from the last decade will be using perfect forward secrecy out of the box², meaning that compromising one session does not compromise other sessions. In TLS, this means generating a new encryption key for every handshake that is authenticated by the long-term identity key in the certificate, rather than encrypting a session key that can then be decrypted by the long-term key in the certificate.

Luckily, the migration process for key agreement is fairly straightforward. You update your TLS library to a version that supports PQC key establishment, and it automatically negotiates quantum-resistant key establishment with clients that support it, mitigating the SNDL attack. Updating software can be hard³, but this update process should be no different than any other update process you apply, and requires no additional coordination or “key inventory”. It also mitigates the only urgent threat.

Now, consider certificates and their corresponding private keys. In the context of HTTPS, now that all handshakes have perfect forward secrecy as of TLS 1.3, the key in the certificate is only used for authentication and is only relevant to preventing MITM attacks. For a quantum computer to be used to MITM a connection, the computer necessarily needs to exist at the time of the conversation, since the causality of time prevents you from performing an MITM attack on a conversation that has already finished⁴.

Inventorying all keys might reveal all corresponding certificates. However, the migration process for certificates is complicated—you need to find a CA that supports post-quantum cryptography in modern browsers (spoiler alert: none currently, due to size and standardization issues). But even if they did, let’s consider what the next steps might be. You could start by finding every key, then run a key-generation algorithm to produce a new “migrated” post-quantum key. This is a ridiculous approach—the keys do not spontaneously generate themselves. Each key is used as part of some system for some purpose (e.g., TLS termination). The migration process is not simply a drop-and-replace of one PEM file with another.

Instead, it makes far more sense to think about the migration problem in terms of systems or protocols:

1. Figure out which systems or protocols you have that use cryptography. If you’re not sure, it’s almost definitely just HTTPS. If you’re not sure where you’re using HTTPS, that is its own problem that is completely independent of migrating to post-quantum cryptography.
2. Determine how to mitigate SNDL in the system. For HTTPS, this is likely just upgrading your TLS library. If you have a bespoke system that doesn’t support key agility, then you get to do bespoke problem solving and update the system design.
3. Since SNDL is the only urgent threat, to be honest, unless you have compliance obligations, you can stop here.
4. If you really care about MITM, determine how to automatically migrate issuance of new certificates from a post-quantum CA. This will primarily be managed by updating your ACME client (or whatever automatic issuance system you’re using). If you aren’t automatically issuing HTTPS certificates, then your migration process is to switch to an automatic system.

Note that none of the steps in this migration involve finding every single key in use. And again, had we started with finding keys, we would have missed mitigating the SNDL attack.

There are clearly other systems that use cryptography. Anything that uses a cloud key management system, such as AWS KMS or Cloud KMS, disk encryption, etc. But again, even in the KMS case, the keys do not spontaneously generate themselves. Something is using the key for a purpose. The migration strategy should be to make sure the system understands how to use post-quantum keys, and then let the system migrate itself.