NIST PQC Standards: What Boards Need to Decide and in What Order

In August 2024, the National Institute of Standards and Technology (NIST) finalised three post-quantum cryptographic algorithms: ML-KEM (FIPS 203, for key encapsulation mechanisms), ML-DSA (FIPS 204, for digital signatures), and SLH-DSA (FIPS 205, a stateless hash-based signature scheme). A fourth algorithm — FALCON, for digital signatures — was also standardised.

These are not draft proposals or research outputs. They are the official US federal standards for post-quantum cryptography, and the UK’s National Cyber Security Centre (NCSC) and the European Union Agency for Cybersecurity (ENISA) have both published migration guidance recommending that organisations begin planning transitions to these or compatible algorithms.

I am writing this for board-level readers. The technical detail of how these algorithms work is not your governance question. Your governance question is: what does my board need to decide, and in what order, to ensure that the organisation is on a credible migration path before the quantum threat becomes operationally relevant?

Article illustration — nist-pqc-standards-board-decisions

That question has a specific answer. Here it is.


Decision 1: Scope assessment — which of our systems use cryptography that needs to migrate?

This is the first board-level decision because it defines the scale of the problem. Before the board can approve a migration programme, budget, or timeline, it needs a written answer from the executive team — specifically, the CISO or CTO — to one question: which of our systems, integrations, and third-party dependencies currently rely on cryptographic algorithms that are vulnerable to quantum attack (primarily RSA, ECC, and Diffie-Hellman key exchange)?

The honest answer in most mid-sized companies is: we do not yet have a complete inventory. That honest answer is the starting point for the decision, not a reason to defer the decision. The board should require the inventory to be completed, on a schedule, and reported back.

The scope assessment is a technical task. But commissioning it, resourcing it, and setting a completion deadline is a board governance decision. The technical team cannot conduct a cryptographic inventory without budget, authority, and a clear mandate. The board provides all three.


Decision 2: Long-lived data prioritisation — what data needs protection now?

The HNDL (Harvest Now, Decrypt Later) threat changes the migration timeline calculation in a way that most boards have not internalised.

Standard migration thinking: migrate before quantum computers are capable of breaking current encryption.

HNDL-aware migration thinking: migrate before the data that is encrypted today needs to remain confidential past the point when quantum computers are capable of breaking current encryption.

These are different timelines, and the HNDL timeline is shorter for many organisations than the standard one.

A board needs to make a data classification decision: which of our data categories have a sensitivity horizon of five or more years? For most mid-sized companies, this includes: intellectual property in transit, long-term legal and contractual communications, financial records subject to long-term regulatory retention requirements, and personal data that carries ongoing privacy obligations.

For each category with a five-plus year sensitivity horizon, the migration priority is elevated. This is not a CISO-level decision alone — the data classification question has commercial, legal, and regulatory dimensions that require board-level context. The board should confirm the classification and the priority sequence.


Decision 3: Migration approach — phased or big-bang?

The choice between a phased migration (migrating systems in priority order, over an extended timeline) and a comprehensive migration (building a crypto-agile architecture that can support multiple cryptographic standards simultaneously) is a strategic decision with significant cost, risk, and timeline implications.

Most large organisations are choosing a phased approach, starting with the highest-risk, highest-value data systems and working down the priority list. This approach is pragmatic and allows the organisation to apply the NIST standards as they mature, rather than committing to early implementations that may need updating as the standards evolve.

For mid-sized companies, the crypto-agility option — building a cryptographic infrastructure that is algorithm-agnostic and can switch algorithms as required — is often impractical from a cost and complexity standpoint. A well-scoped phased migration, starting with the organisation’s most sensitive data systems, is typically the right approach.

The board’s governance question at this decision point: has the executive team presented a credible phased migration plan, with a timeline, a resource estimate, and a definition of what “complete” means at each phase?


Decision 4: Third-party dependency management — where is the risk we cannot directly control?

This is the decision most boards miss, and it is the one that most often determines the actual migration timeline.

Most mid-sized companies do not build their own encryption. They rely on cryptographic libraries in their software frameworks, cryptographic functions in their cloud providers’ services, and encryption in the third-party products they deploy. The migration timeline for these dependencies is not under the organisation’s direct control — it is under the control of the software vendors, cloud providers, and third-party product companies whose cryptographic implementations the organisation uses.

The board-level question: has the executive team identified which of the organisation’s critical third-party dependencies have published PQC migration roadmaps? For those that have not, what is the engagement plan?

This is not a question most compliance teams think to ask, because it requires looking outside the organisation’s own systems. But for many mid-sized companies, the longest lead time in the PQC migration is not their own systems — it is waiting for a critical third-party vendor to migrate their product.


The timeline the board should hold

The NCSC’s guidance recommends that UK organisations in critical sectors have PQC migration plans in place by 2028, with migration of the most critical systems complete by 2035. These are targets, not hard deadlines in the regulatory sense — but they reflect the intelligence community’s assessment of the quantum threat timeline.

For organisations holding data with a sensitivity horizon beyond 2028 — which includes most financial services, healthcare, defence supply chain, and professional services companies — the effective migration deadline for long-lived data is earlier than 2028, because data encrypted in 2026 with current standards may be retrospectively decryptable before 2028 if quantum capability advances faster than the current consensus timeline.

The board does not need to resolve this uncertainty. It needs to ensure the organisation is managing the uncertainty with a credible migration plan and regular review.


The governance summary

Four board decisions, in order:

  1. Commission a cryptographic inventory — scope, systems, dependencies. Set a completion date.
  2. Approve a data classification exercise that identifies long-lived sensitive data and its migration priority.
  3. Review and approve a phased PQC migration plan with timeline, resource estimate, and phase completion criteria.
  4. Require a third-party dependency review, including vendor PQC roadmap status for critical dependencies.

None of these decisions require the board to understand quantum physics or cryptographic algorithm design. They require the board to understand what decisions need to be made, in what order, and to ensure the executive team has the mandate and the resources to make them.

That is board governance. The NIST standards provide the technical destination. The board provides the governance to get there.


The Quantum Risk: What Directors Need to Know covers the PQC migration decisions in full, including the NIST August 2024 standards, the HNDL threat timeline, NIS2 personal liability implications, and what a credible board-level migration governance structure looks like for a mid-sized company.

For independent advisory support on quantum risk governance, visit Quantum Security Defence or contact Steven directly.

Steven Vaile

Steven Vaile

Board technology advisor and QSECDEF co-founder. Writes on AI governance, quantum security, and commercial strategy for boards and deep tech founders.