The CISO's Case for Quantum Security Investment in 2026

The argument a CISO makes to a board about post-quantum cryptography in 2026 is categorically different from the one that could have been made in 2023. Three years ago, the case was: prepare for a future threat. The standards were not published. The deprecation timeline was a roadmap, not a schedule. The vendor ecosystem was thin.

That position no longer holds. NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) as final standards on 13 August 2024. NIST IR 8547 (November 2024) formally opened the deprecation period for RSA, ECDH, ECDSA, DSA, and finite-field Diffie-Hellman. The 2030 new-deployment deprecation date is now less than four years away. Vendor implementations of ML-KEM and ML-DSA are shipping. The CISO asking for PQC investment in 2026 is not predicting the future; they are responding to a published engineering timeline from the same standards body that defined the current encryption stack.

This article gives CISOs the framing, the financial exposure proxies, and the specific investment ask they need to move this from the risk register to the project list.

Why the Investment Case Is Different in 2026

The standards shift is the foundation of every other argument. Prior to August 2024, a CISO arguing for PQC investment was making a probabilistic case about a threat that was still at the algorithm competition stage. Post August 2024, the CISO is citing published, stable standards with NIST DOI references and a documented deprecation clock. These are not the same conversation.

NIST IR 8547 (November 2024) sets three concrete milestones for the US federal baseline and any framework that references NIST cryptographic guidance: 2030 is the new-deployment cutoff for RSA, ECDH, ECDSA, DSA, and finite-field DH in federal systems; 2035 is the full-retirement date. An enterprise with a 3-to-7-year migration programme (which is realistic for any organisation with a complex cryptographic estate) needs to have started that programme by 2026 or 2027 to avoid working under deadline pressure in 2029 and 2030.

The harvest-now-decrypt-later (HNDL) threat compounds the urgency. HNDL is not a future scenario. State-level adversaries are capturing encrypted traffic today under the assumption that a cryptographically relevant quantum computer (CRQC) capable of breaking 2048-bit RSA will be operational within the decade. The NSA's 2021 Cybersecurity Advisory on quantum computing confirmed that national security system operators face an active requirement to migrate. The harvest is occurring now. The question for any organisation is not whether it is being targeted but whether the data it is generating today will still be sensitive when decryption becomes possible. For any organisation handling long-tenure data (patient records, counterparty positions, classified technical specifications, genomic data) the answer is yes.

The decision the CISO needs to bring to the board is not binary. It is a capital allocation question: how do we sequence migration to achieve maximum risk reduction per pound, dollar, or euro spent? That reframing matters. A board asked to approve a five-year, multi-million programme to address a probabilistic future event will hesitate. A board asked to fund a diagnostic programme to identify which of its current cryptographic assets are most exposed, and in what order to address them, is being asked for something proportionate and tractable.

What the Board and CFO Will Ask: and What to Say

Board and CFO audiences typically ask for ROI or a defined risk exposure before approving significant security investment. Direct ROI is difficult to calculate for cryptographic infrastructure because the loss event is probabilistic and future-dated. Three financial exposure proxies provide the quantitative grounding boards need.

Regulatory fine exposure. GDPR Article 83 sets maximum penalties at 4% of global annual turnover or €20 million (whichever is greater) for breaches of Article 5(1)(f) (the security principle) or Article 32 (the technical measures obligation). If a future CRQC attack reveals personal data that was encrypted with RSA or ECDH key exchange, the regulatory exposure question is whether the organisation was using encryption that met the "state of the art" standard at the time of the breach disclosure. NIS2 Article 32 adds supervisory fines of up to €10 million or 2% of global turnover for essential entities failing to meet the Article 21 security obligations, which include the same "state of the art" standard for encryption. Commission Implementing Regulation (EU) 2024/2690 (NIS2 Article 21 implementing measures, in force from 18 October 2024) requires Article 4(f) assessment of whether cryptographic controls remain effective against known threats. That requirement is active now.

Defence and government procurement. For organisations in the US defence supply chain, NSA CNSA 2.0 (September 2022) mandates ML-KEM-1024 and ML-DSA-87 for National Security Systems, with initial deployment requirements beginning 2025 for high-priority categories including firmware, software updates, browsers, and operating systems. NSM-10 (May 2022) requires federal agencies to inventory quantum-vulnerable systems and submit prioritised migration plans. These requirements flow downstream to defence contractors. An organisation that cannot demonstrate PQC readiness when responding to a defence or government contract tender faces disqualification risk, not in 2030, but now, as procurement requirements begin to embed CNSA 2.0 compliance conditions. [INFERRED: current rate of CNSA 2.0 embedment in procurement conditions; verify against current DoD and prime contractor tender documentation before citing as an active disqualification risk in a specific procurement context.]

Insurance market pressure. The trajectory of the cyber insurance market on cryptographic requirements mirrors the pattern observed with TLS 1.0/1.1 deprecation: once insurers incorporated TLS version requirements into underwriting questionnaires, organisations without TLS 1.2 found their policy conditions tightened or premiums adjusted. There is no confirmed broad market requirement for PQC migration status as a formal underwriting condition as of mid-2026. This is a directional signal, not a confirmed mandate. The signal is nonetheless worth presenting to a board: the direction is visible, and acting before it becomes a formal condition is less expensive than acting after. [ASSUMED: current state of cyber insurance PQC underwriting requirements; verify with current market data before board presentation.]

The DORA angle is specific to EU financial entities. DORA Article 6(6) requires financial entities to identify and continuously assess all sources of ICT risk, which supports a quantification obligation within the ICT risk management framework. The quantum risk (specifically HNDL exposure on long-lived financial data) is an identifiable ICT risk that belongs in the DORA risk register and, where material, in the risk capital model. An institution that has not quantified this exposure is running a documented gap in its ICT risk framework.

Three Frames for Presenting to the Board

Different board compositions respond to different risk framings. Three distinct frames work, in increasing order of persuasiveness for boards that are sceptical of security investment generally.

The deprecation compliance frame. "NIST has published the replacement standards and formally deprecated the algorithms we depend on by 2030. This is not a prediction; it is a published timeline from the same body that defines our current encryption standards. We need a migration plan and budget before the deprecation window closes." This frame works best with technically literate boards or audit committees who are familiar with standards lifecycle management. It positions PQC migration as infrastructure lifecycle work, not threat response.

The HNDL risk frame. "Adversaries may already be collecting our encrypted data. The question is not whether Q-Day happens before our data expires, it is whether the data we are generating today will still be sensitive when it does. For our [financial records / patient data / contracts], the answer is yes." This frame is most effective when the CISO can name a specific data category with a long confidentiality requirement. Abstract quantum threat discussions do not move boards; specific data categories with specific retention horizons do.

The regulatory cost frame. "Our current cryptographic posture may not satisfy 'state of the art' obligations under GDPR, NIS2, and DORA as PQC standards become the established baseline. Remediation after a breach disclosure costs significantly more than planned migration." This frame lands best with legally risk-averse boards and general counsels. The financial exposure proxies in the previous section supply the numbers.

For extended guidance on presenting the quantum risk to a board, see Quantum Risk on the Board Agenda: A CISO's Preparation Framework.

What to Ask the Board to Approve in 2026

The mistake CISOs make in PQC investment presentations is asking the board to approve the full migration programme. The board rejects the cost or defers the decision. The correct ask in 2026 is the first phase only: fund the cryptographic bill of materials (CBOM) and migration assessment.

A CBOM is a structured inventory of every cryptographic asset in the organisation (every algorithm, key size, protocol, certificate, and library) mapped to the systems and data it protects, with a confidentiality lifetime and migration complexity estimate for each asset. It is not an abstract exercise. It is the instrument that makes risk visible: which data is HNDL-exposed, how long will each system take to migrate, and which assets need to move first. Without a CBOM, the CISO cannot tell the board how much the full migration will cost or how long it will take. NIST NCCoE SP 1800-38B provides the reference methodology and effort templates for CBOM construction.

Performance overhead is a legitimate concern that boards with engineering awareness will raise. ML-KEM-768 key encapsulation adds approximately 1,088 bytes to a TLS 1.3 handshake compared to ECDH P-256. ML-DSA-65 signatures are 3,309 bytes (per NIST FIPS 204 Table 2), compared to 64 bytes for ECDSA P-256. On modern broadband infrastructure with TLS session resumption, the bandwidth overhead for typical web traffic is sub-1%. The honest caveat: constrained IoT and operational technology devices need individual profiling, blanket claims of negligible overhead are not accurate for every deployment context. A board that has heard the performance objection can be told: it is a real engineering consideration that the CBOM phase will quantify per system. It is not a reason to delay the discovery work.

The cost structure of PQC migration is dominated by people and time rather than product licensing. The CBOM itself typically requires 3 to 6 months of security architect time, augmented by automated scanning tools that identify cryptographic library usage and TLS cipher suites across the network estate. Migration planning follows: 4 to 8 weeks of architect and CISO time to produce a prioritised migration roadmap with cost estimates. Implementation proceeds in phases: public-facing TLS (weeks to months for modern web and API infrastructure); internal PKI, VPNs, and application-layer cryptography (months to years, depending on scale); OT and legacy hardware (years, with operational and vendor constraints, and the most expensive phase in most organisations). The Year 1 cost is the CBOM and planning phase. It is proportionate. It produces the data needed to cost and authorise every subsequent phase. Not funding Year 1 means all subsequent decisions are made blind.

Active Mandates: What Is Already Required Now

For CISOs in organisations with US government or national security system customers, current obligations apply now, not at some future standard-setting date. CNSA 2.0 mandates ML-KEM-1024 and ML-DSA-87 for National Security Systems. NSM-10 (May 2022) requires all federal agencies to have submitted inventories of quantum-vulnerable systems and prioritised migration plans. These are active requirements. An organisation in the defence industrial base that cannot demonstrate CNSA 2.0-aligned cryptography for its NSS-supporting systems is operating outside existing contractual and regulatory expectations. For detailed audit framework guidance, see the CNSA 2.0 compliance audit framework.

For CISOs in EU critical infrastructure, financial services, or cloud and ICT service provision, the obligations are equally live. NIS2 Article 21(2)(h) requires the use of cryptography and encryption as part of appropriate security measures; Commission Implementing Regulation (EU) 2024/2690 requires assessment of whether cryptographic controls remain effective against known threats under Article 4(f). DORA Article 9(2) requires financial entities to implement ICT security policies covering cryptographic controls, with the binding specifications in Commission Delegated Regulation (EU) 2024/1774. These are not future-dated requirements. They are in force.

The NIST FIPS 203/204/205 publication in August 2024 and NIST IR 8547 in November 2024 are the shift events that changed what "state of the art" means for cryptographic controls under all of these frameworks. An organisation that reviewed its cryptographic policy in 2024 or 2025 without addressing that shift may have an undetected gap in its compliance position.

What a Proportionate Investment Looks Like

Year 1: fund the CBOM and migration assessment. The output is a prioritised migration roadmap with cost estimates for each phase, a risk-scored inventory of cryptographic exposures, and a compliance gap analysis against the frameworks applicable to the organisation. Total investment: 3 to 6 months of security architect time plus tooling.

Months 1 to 6 of the deployment phase: deploy hybrid key exchange on externally facing web and API infrastructure. X25519+ML-KEM-768 (per IETF draft-ietf-tls-hybrid-design) is operational and deployed at scale by Google Chrome, Mozilla Firefox, and Cloudflare. The client-side support already exists. This addresses the highest HNDL exposure (external data flows) at the lowest migration cost. The hybrid approach preserves compatibility with clients that are not yet PQC-capable while adding immediate HNDL protection.

Years 2 to 3: internal PKI, VPN infrastructure, and application-layer cryptography. The major cost here is engineering time and change management, not licensing.

Year 3 onwards: OT, legacy, and embedded systems. This is the most expensive phase and the one most organisations have not costed. It requires hardware replacement timelines, vendor coordination, and operational planning to avoid downtime in production environments. The CBOM will identify precisely which systems fall here, and give the board an honest picture of the total programme cost before it is committed.

The argument for the CFO: Year 1 funding is the diagnostic that makes the rest of the programme possible to plan and approve. Without it, the organisation is making uncosted commitments to multi-year infrastructure work. With it, every subsequent phase has a defined scope, a cost estimate, and a link to the regulatory obligation it satisfies.