Close-up of a bunch of metal keys on a dark surface, representing cryptographic key management

PKI, HSM and Key Management: The Blind Spots in Most PQC Inventories

/ PQC (Post-Quantum Cryptography) / By

Ask most organisations where their quantum-vulnerable cryptography lives and they will hand you a list of TLS endpoints. That list is useful, but it is the visible tip of the problem. The certificate authorities that sign those certificates, the private keys held in hardware security modules, and the keys sitting in cloud key management services are routinely under-counted, and they are exactly the assets that take longest to migrate. PKI and HSM discovery is the work of bringing them into the inventory with enough detail to plan against.

The timing matters. NIST finalised NIST IR 8547, Transition to Post-Quantum Cryptography Standards, in October 2026, confirming that quantum-vulnerable public-key algorithms will be deprecated after 2030 and disallowed under NIST standards after 2035. At the same time, publicly trusted TLS certificates are getting shorter-lived every year. Trust anchors that last decades and leaf certificates that last weeks now sit in the same estate, and an inventory has to handle both.

Why PKI, HSM and KMS Assets Are Under-Counted

Most first-pass cryptographic inventories are built from network scanning. A scan sees the certificate a server presents on a port and the cipher suites it negotiates. It does not see:

  • The issuing hierarchy. Offline root CAs and many issuing CAs are deliberately unreachable from the network, so they never appear in a scan, even though every certificate below them inherits their algorithm choice.
  • Certificates that are issued but not served. Client authentication, device identity, code signing, S/MIME and VPN certificates live in CA databases and endpoint stores, not on listening ports.
  • Keys inside HSMs. By design, an HSM never exposes private key material. Unless someone queries the HSM’s own management interface, its partitions, key types and key usage stay invisible.
  • Cloud KMS keys. Keys created by platform teams across multiple cloud accounts are governed by key policies that a network scan cannot reach.

PKI, HSM and cloud platform teams also tend to keep separate registers with different fields, so the inventory looks complete for web traffic and almost empty for the trust infrastructure underneath it. This is the gap that a Cryptographic Bill of Materials (CBOM) is meant to close, but only if PKI, HSM and KMS sources feed into it.

What PKI and HSM Discovery Needs to Show

A list of certificate serial numbers is not enough to plan a migration. Each asset class needs the fields that drive decisions.

AssetWhat to captureWhy it matters for PQC
CA hierarchyRoot, intermediate and issuing CAs; trust chains; who relies on each rootA quantum-vulnerable root undermines every certificate beneath it
Issued certificatesSignature algorithm, key type and size, validity period, purpose, issuing CAShows volume, ownership and which certificates will outlive the 2030 and 2035 milestones
HSM partitionsPartitions, key types, key usage, applications bound to each partition, firmware levelHardware and firmware upgrades have the longest lead times
KMS keysKey spec, usage (encrypt, sign, wrap), key policy, rotation, import methodSeparates symmetric keys from the asymmetric and key-wrapping uses that are quantum-vulnerable

CA hierarchy and trust chains

Map every root and issuing CA, including private CAs stood up for one project and forgotten. NIST IR 8547 is explicit that PKI components “must be updated to issue, distribute, and manage certificates that use PQC algorithms and to sign certificates and revocation status information using PQC algorithms”. The UK NCSC’s migration timelines guidance (20 March 2025) adds that migrating an enterprise PKI will require a new PQC root of trust and reissued certificates across the network. You cannot plan that without knowing which roots you have and what depends on them.

Algorithms, key sizes and validity periods against data shelf-life

Record the signature algorithm and key size of every CA and certificate, then compare validity periods with two dates: NIST’s deprecation (after 2030) and disallowance (after 2035) milestones, and the confidentiality lifetime of the data each key protects. NIST IR 8547 restates the familiar rule: if data must stay secure for X years and migration takes Y years, you must start before X plus Y exceeds the time until a cryptanalytically relevant quantum computer exists. Root CAs are often issued with validity periods measured in decades, so a root created recently with RSA or ECDSA may still be trusted long after those algorithms are disallowed.

HSM partitions and key usage

For each HSM, capture partitions, the key types they hold, which applications use them, and the firmware version. NIST IR 8547 notes that hardware modules “must be upgraded or redesigned to support PQC algorithms” and that hardware lead times are long. Vendors are moving: Thales, for example, announced native ML-KEM and ML-DSA support in Luna HSM firmware v7.9 (July 2025). Whether your estate can use it depends on model, firmware and validation status, so record them.

KMS key policies and key specs

Symmetric keys such as AES-256 are not the main quantum concern. The exposure sits in asymmetric KMS keys used for signing or key agreement, and in RSA-based wrapping used to import or move keys between systems. Record key specs and policies so these uses stand out. Cloud providers have started adding post-quantum options; AWS KMS, for instance, added ML-DSA signing keys in June 2025, which gives teams a concrete target once discovery shows where classical signing keys are in use.

Quantum Sentinel, a Sinevis technology partner, describes this coverage on its CBOM use-case page: it inventories issued certificates from Active Directory Certificate Services and collects metadata from HSMs, key managers and cloud KMS services without retrieving key material. Its platform overview lists PKI and HSM connectors among its read-only discovery methods and states that only cryptographic metadata is collected, never private keys.

Continuous Monitoring as Certificates Churn

A PKI inventory goes stale faster every year. CA/Browser Forum ballot SC-081v3, adopted on 11 April 2025, sets a falling maximum validity for publicly trusted TLS server certificates in the Baseline Requirements:

Certificates issuedMaximum validityDomain validation reuse
Before 15 March 2026398 days398 days
15 March 2026 to 14 March 2027200 days200 days
15 March 2027 to 14 March 2029100 days100 days
From 15 March 202947 days10 days

The 200-day limit has applied since March 2026, and the 100-day step is less than five months away. These rules cover publicly trusted TLS certificates, not private PKI, but the automation they force tends to spread across the whole estate. Two consequences follow for post-quantum planning.

First, a point-in-time inventory is out of date within weeks. Every renewal can change the issuing CA, key type or key size, so PKI discovery has to be a recurring process rather than a project deliverable. Quantum Sentinel’s continuous posture monitoring describes continuous re-discovery and a Quantum Readiness Score tracked over time, so regressions show up rather than hide between audits. Its certificate and PKI visibility use case focuses on mapping the PKI you actually run, trust-chain mapping, and early warning before certificates and keys reach end of life.

Second, churn is an opportunity. Automatically renewed certificates can move to new algorithms once the CA and relying parties support them; certificates still renewed by hand are where crypto-agility breaks down, and discovery should flag them.

How PKI and HSM Discovery Shapes Migration Sequencing

With trust infrastructure in the inventory, the migration order becomes much clearer. A sequence that works for most enterprises:

  1. Trust anchors and HSM capability first. Roots and HSMs have the longest lead times and everything else depends on them. Confirm which HSMs can support ML-KEM and ML-DSA, plan firmware or hardware upgrades, and choose a PKI migration approach. The NCSC lists options including a parallel PKI, direct cutover, staged coexistence and cross-signing.
  2. Long-lived signatures next. Code-signing and firmware-signing keys produce signatures that must be trusted for years in the field. NIST IR 8547 notes that, although signatures are not exposed to harvest-now-decrypt-later attacks, the signature transition is urgent because of its complexity and the number of parties involved.
  3. Key establishment protecting long-lived data. KMS and HSM keys that wrap or transport keys for data with a long confidentiality life carry real harvest-now-decrypt-later exposure and should be prioritised accordingly.
  4. Short-lived, automated certificates last. These follow the CA once it can issue PQC or hybrid certificates.

Prioritisation works best when findings are scored in business context rather than by algorithm alone. Quantum Sentinel’s cryptographic exposure assessment provides a Cryptographic Exposure Score that ranks weak or quantum-vulnerable cryptography by business impact, and its migration planning evidence attaches a migration priority and a named replacement algorithm to each finding, with policies for banned algorithms and minimum key sizes. Its page is candid that it does not hold the migration plan itself, so plan ownership, waves and dates stay with you. For the wider programme, see our guide to the PQC migration journey, or take our free PQC compliance check for a quick baseline before you start.

How Sinevis Can Help

Sinevis delivers post-quantum readiness assessments that put PKI, HSMs and key management at the centre of the inventory rather than at the edge. As an authorised Thales service partner, delivering globally, we design, deploy and upgrade Thales Luna HSMs and CipherTrust key management, and run certificate lifecycle management programmes, so the findings from discovery turn into practical upgrade and migration work. For automated discovery we work with Quantum Sentinel, one of our technology partners, to build and maintain a continuously updated CBOM across PKI, HSM and key management systems.

To scope a PKI and HSM discovery exercise, contact the Sinevis team.

Sources