At 6:45 a.m., a nurse taps her badge to open a clinical workstation. The badge certificate chains to an internal root. The new certificate is ready, but one older gateway does not recognize the trust path. The nurse cannot sign in. Her first patient is waiting.

Picture that during a post-quantum cryptography migration. The algorithm can be correct and the transition can still fail.

I have seen teams start with algorithm selection. Which key-establishment standard? Which signature scheme? Those decisions matter. But the first question for a CISO is more operational: who issues the new certificate, which systems must trust it, and how will the old trust path be retired?

Start with the chain, not the algorithm

A certificate is useful only when the systems on both ends can validate it. The certificate authority signs it. Devices and applications check the certificate through a chain of trust. Change a key or signature algorithm and every relying system needs a supported path to accept the new certificate.

That is why PKI deserves its own workstream. NIST’s updated crypto-agility guidance notes that certificate authority signatures can need to remain verifiable for decades. It also lays out tradeoffs between hybrid certificates and separate traditional and post-quantum roots of trust (NIST crypto-agility guidance).

Those are architecture decisions with operating costs. Two trust paths can preserve compatibility during a staged migration. They also mean more certificate chains to test, more policy to manage, and a decision about when the older path stops issuing.

A successful handshake is not proof of migration.

Put PKI on the critical path

I want every migration plan to answer four questions:

  • Where is trust anchored? Map root and intermediate authorities, issuance profiles, certificate stores, HSM dependencies, and the teams that own them.
  • Who relies on each certificate? Include employee devices, applications, network services, connected equipment, and suppliers. Mark which can update remotely and which require physical access.
  • How does the certificate lifecycle work? Record issuance, renewal, expiration, revocation, status checking, emergency replacement, and rollback. A spreadsheet of algorithms cannot answer those questions.
  • What transition model are we choosing? Decide how traditional and post-quantum trust will coexist, how compatibility will be tested, and what evidence allows a team to retire the old path.

The UK National Cyber Security Centre expects many organizations to run traditional and post-quantum enterprise PKIs side by side during a staged migration. Its guidance also says a system does not provide quantum-secure authentication until PKI migration is complete and traditional certificates have expired or been revoked (NCSC migration timelines).

That detail matters to a person trying to get through a normal workday. A failed trust chain can block a nurse from a workstation. It can also stop a software update from being accepted. Those are different business consequences, and each needs a named owner.

Test the business path

Do not stop at a lab handshake. Test certificate issuance and renewal. Test revocation. Test clients with old trust stores. Test an application that has not been updated in years. Test how monitoring identifies a failed chain and how operations teams recover without silently re-enabling weak settings.

Then test the supplier boundary. Ask vendors which certificate profiles, trust anchors, HSM models, and update paths their products support. Ask for dates and evidence, not a general statement that “PQC is on the roadmap.”

If the answer depends on a firmware update, a new root, or a service release, put that dependency into the migration schedule. Do not let it hide in a vendor slide.

What I want from a CISO

Fund PKI as a workstream with an accountable enterprise owner. Report progress by certificate class and relying party instead of algorithms alone. Track which trust chains have an owner, which have been tested, and which still depend on legacy issuance.

Put a date on ending issuance under the traditional root. Keep it tied to tested replacement paths and service readiness. If nobody can say who will stop issuing legacy certificates, the program has not defined its end state.

My position is clear. A cryptographic inventory shows where algorithms are used. A PKI map shows who depends on whose trust. The migration is not ready until both are connected to owners, tests, and retirement decisions.

Fellow CISOs and PKI leaders, what evidence will you require before retiring a legacy trust anchor? Here is what I am watching this quarter.

Lekshmy Sankar, PhD