Quantum Computing and Security Governance: What CISM Professionals Should Watch

Why Quantum Risk Belongs on a Governance Agenda Now

Quantum computing shows up in security conversations as either science fiction or an over-hyped vendor pitch, and both framings make it easy for a security leader to deprioritize it. Neither is accurate. A cryptographically relevant quantum computer, one capable of breaking the RSA and elliptic-curve cryptography that underpins TLS, VPNs, code signing, and most enterprise key exchange, does not exist yet in any publicly known, commercially usable form. But the underlying mathematics of the threat is well understood, national governments and standards bodies are treating it as a near-certainty on a multi-year horizon, and the required migration is large enough that waiting for certainty means starting too late.

This is a governance problem before it is a technical one. CISM Domain 2 (Information Security Risk Management) exists precisely for risks like this: low current probability, potentially severe and irreversible impact, long remediation lead time, and genuine timing uncertainty. That combination is uncomfortable for risk registers built around annual review cycles, but it is not new; it is the same category of risk as long-lived PKI root certificates, EOL dependencies in critical infrastructure, or supply chain concentration risk. The governance response is the same too: identify exposure, size the remediation effort, and start the parts of the work that do not depend on knowing the exact date.

The Actual Threat: Shor's Algorithm and Public-Key Crypto

The specific mathematical threat is Shor's algorithm, a quantum algorithm that can efficiently factor large integers and solve discrete logarithm problems. Those two problems are the foundation of RSA and elliptic-curve cryptography (ECC), which together secure the overwhelming majority of key exchange, digital signatures, and certificate infrastructure in use today, including TLS/HTTPS, SSH, most VPN protocols, and code-signing certificates.

It is important for a security leader to be precise about what is and is not at risk:

• At risk: asymmetric (public-key) cryptography. RSA, DSA, Diffie-Hellman, and ECC (including ECDSA and ECDH) are all theoretically breakable by a sufficiently powerful quantum computer running Shor's algorithm.
• Not meaningfully at risk: symmetric cryptography. AES and other symmetric algorithms are affected by a different, much weaker quantum algorithm (Grover's algorithm), which roughly halves the effective key strength. AES-256 remains solidly secure against quantum attack; AES-128 is a more reasonable candidate to phase out over time, but this is a far smaller and less urgent problem than the public-key issue.
• Not affected: most hashing. Hash functions like SHA-256 and SHA-3 are similarly weakened by Grover's algorithm but not broken, and the practical impact is modest.

The scale of quantum hardware required to run Shor's algorithm against real-world key sizes, thousands of stable, error-corrected logical qubits, is well beyond what any published research program has demonstrated as of 2026. Current systems from IBM, Google, and others operate with far fewer logical qubits and significant error rates, which is the primary reason estimates vary so widely: progress depends on error-correction breakthroughs that have not yet occurred at the necessary scale.

"Harvest Now, Decrypt Later" and Data Longevity

The reason this risk matters today, not only in the year a quantum computer capable of breaking RSA appears, is a strategy commonly called harvest now, decrypt later (HNDL). An adversary with resources, most credibly a nation-state, can intercept and store encrypted traffic or exfiltrated data today and simply hold it until quantum decryption becomes feasible. For short-lived data this is a non-issue; for data with a long confidentiality horizon, it already is one.

This makes data classification and retention, not cryptographic protocol choice, the first practical governance question. Ask which categories of data your organization holds where confidentiality needs to survive 10, 15, or 20+ years:

An organization with no long-horizon confidentiality requirements has a genuinely low-urgency quantum risk profile. An organization holding health data, government contracts, or long-lived intellectual property has real exposure today, regardless of when a capable quantum computer arrives, because the interception and storage can be happening now.

Where the Standards Stand: NIST and Post-Quantum Cryptography

The US National Institute of Standards and Technology (NIST) has led the primary public standardization effort since 2016, running a multi-year, multi-round public competition to select post-quantum cryptography (PQC) algorithms believed to be resistant to quantum attack. NIST finalized its first set of PQC standards in 2024: a lattice-based algorithm for general encryption and key establishment (based on CRYSTALS-Kyber, standardized as ML-KEM) and lattice- and hash-based digital signature algorithms (based on CRYSTALS-Dilithium and SPHINCS+, standardized as ML-DSA and SLH-DSA). Additional algorithms continue through further evaluation rounds.

Governments and regulators have moved from research posture to migration mandates faster than many enterprises expect. US federal agencies operate under a National Security Memorandum directing them to inventory cryptographic systems and begin PQC migration on defined timelines, and other governments and regulated sectors, notably finance and critical infrastructure, have issued similar guidance. The practical implication for a CISM-minded leader is that PQC migration is increasingly becoming a compliance driver, not only a technical best practice, especially for organizations selling into government, defense, healthcare, or critical infrastructure supply chains.

For governance purposes, the key takeaway is that the "what algorithm do we use" question is now largely answered. The open questions are operational: inventory, prioritization, vendor readiness, and migration sequencing. That shifts this from a cryptography research problem into a familiar program management and governance problem, which is squarely CISM territory.

Adding Quantum Risk to the Risk Register

Quantum risk does not need a separate, exotic risk framework. It fits the standard risk register structure used across CISM Domain 2 risk management practice, with a few adjustments for its unusual timing profile.

1. Identify the asset, not the algorithm. Start with systems and data flows relying on asymmetric cryptography for confidentiality or integrity over a long horizon: TLS termination points, VPN gateways, code-signing infrastructure, document and email encryption, and any system whose PKI cannot be easily re-keyed.
2. Score likelihood as a function of exposure window, not a single date. A useful proxy is Mosca's inequality, a framework popularized by cryptographer Michele Mosca: risk becomes material when the sum of your data's required confidentiality lifetime plus your migration time exceeds the time until a capable quantum computer exists. If either your data lifetime or your migration time is long, your effective safety margin shrinks even under optimistic quantum timelines.
3. Score impact using existing confidentiality and integrity impact criteria. This is not a new impact category; it is a new threat vector against assets you already have impact ratings for.
4. Treat the response as a multi-year program, not a single remediation item. Full PQC migration across an enterprise typically spans hybrid rollout, testing, vendor coordination, and legacy system handling. Track it as a program with milestones, similar to a major identity or cloud migration, rather than a line item that gets a single "planned" status.

Boards and audit committees increasingly expect at least an acknowledgment of quantum risk in enterprise risk reporting, even where the assigned current-state risk score is low. A one-page inventory-and-timeline summary, refreshed annually, is usually sufficient for organizations without extreme long-horizon confidentiality needs. Compare this to how key risk indicators track other slow-moving, high-impact risks in our Key Risk Indicators guide.

Cryptographic Agility as the Practical Control

The single highest-leverage control available today is not "switch to a specific PQC algorithm." It is building cryptographic agility: the organizational and technical ability to change cryptographic algorithms and key sizes without a ground-up system rebuild. Most legacy systems hard-code cryptographic choices deep in application code, firmware, or vendor products, which is precisely why migration timelines run into years.

Practical steps that build agility regardless of exactly when quantum-capable hardware materializes:

• Inventory cryptographic dependencies. Most organizations cannot currently produce an accurate list of where and how they use RSA, ECC, and specific key sizes across applications, infrastructure, and third-party products. This inventory is valuable independent of quantum risk; it also surfaces weak or deprecated algorithms already in use.
• Favor abstraction over hard-coded crypto. Where new systems are built, use cryptographic libraries and standards (TLS 1.3, current key management services) that already support algorithm negotiation and can add PQC or hybrid modes without an application rewrite.
• Track vendor PQC roadmaps. Cloud providers, browser vendors, and major security product vendors are already rolling out hybrid classical/PQC key exchange (for example, hybrid TLS key exchange combining ECDH with ML-KEM). Confirm which of your critical vendors have a published PQC timeline and which do not.
• Prioritize by data longevity, not by system criticality alone. A moderately important system protecting 20-year-horizon data may need to migrate before a highly critical system protecting only short-lived session data.

This connects directly to broader program governance. If your organization already runs a mature architecture review or SDLC security gate, discussed in our CISM Domain 3 guide, the cleanest path is adding a cryptographic agility checkpoint to that existing gate rather than standing up a parallel quantum-specific process.

Vendor and Third-Party Questions to Start Asking

Most organizations will inherit their quantum exposure through vendors and third parties more than through systems they built themselves. This makes quantum readiness a natural addition to existing third-party risk and vendor security review processes, covered in more depth in our vendor risk management guide. Useful questions to start including in security questionnaires and vendor reviews:

• Does the vendor have a published post-quantum cryptography roadmap or timeline?
• For products handling long-lived sensitive data (document storage, backup, archival, code signing), does the vendor support or plan to support hybrid classical/PQC key exchange?
• Does the vendor's cryptographic implementation depend on hard-coded algorithm choices, or is it agile enough to update without a major version change?
• For cloud and managed key management services specifically, what is the provider's timeline for offering PQC or hybrid key exchange options?

This does not need to be an aggressive, immediate requirement for every vendor. Reserve strict PQC-readiness requirements for vendors handling the long-confidentiality-horizon data categories identified earlier, and use a lighter-touch "are you tracking this" question for lower-risk vendors.

A Realistic Governance Roadmap

A pragmatic, multi-year approach that avoids both extremes, ignoring the risk entirely or over-investing in a full emergency migration, generally looks like this:

Most organizations without extreme long-horizon confidentiality requirements are well served sitting in Phase 1 or the early part of Phase 2 today: get the inventory done, classify data longevity honestly, and fold cryptographic agility into normal architecture and vendor review practices. Organizations in defense, healthcare, finance, or critical infrastructure, or anywhere a regulator has already issued PQC guidance, should be further along, likely in Phase 2 or 3.

Frequently Asked Questions

Is quantum computing a real, current threat to my organization?

Not in the sense of an active, exploitable capability today. No publicly known quantum computer can break RSA or ECC at the key sizes used in production systems. The real, current risk is harvest now, decrypt later: encrypted data intercepted or stolen today can be stored and decrypted once quantum capability matures, which matters most for data with a long required confidentiality horizon.

When will quantum computers be able to break current encryption?

There is no reliable consensus date, and credible estimates span a wide range, roughly from the early 2030s to considerably later, depending on unresolved hardware and error-correction breakthroughs. Governance planning should be based on remediation lead time (how long your migration will take) rather than a specific predicted date.

What should a CISM-certified security manager actually do about this now?

Start with a cryptographic asset inventory and a data longevity classification exercise, add quantum risk to the risk register with an honest likelihood-and-impact rationale, begin asking vendors about their PQC roadmaps, and prioritize cryptographic agility in new architecture decisions. None of this requires predicting exactly when quantum computers will be capable of breaking current cryptography.

Does AES encryption need to be replaced because of quantum computing?

No, not in the same way public-key cryptography does. Symmetric algorithms like AES are weakened by a different quantum algorithm (Grover's) that roughly halves effective key strength, not broken outright. AES-256 remains considered quantum-resistant for practical purposes; organizations still using AES-128 have more reason to plan an eventual move to AES-256, but this is a much lower priority than public-key migration.

Are the NIST post-quantum cryptography standards final?

NIST finalized its first set of PQC standards in 2024 (ML-KEM for key establishment, ML-DSA and SLH-DSA for digital signatures), with additional algorithms continuing through further evaluation. The core algorithm selection question is largely settled; the ongoing work for most organizations is implementation, vendor adoption, and migration planning rather than waiting for new algorithm standards.

How does quantum risk fit into the CISM exam?

Quantum computing is not a named topic in the current CISM job practice areas, but the underlying skill it tests, evaluating an emerging, high-impact, long-horizon risk with genuine timing uncertainty and folding it into a risk register and governance program, is exactly the kind of scenario-based reasoning CISM Domain 2 and Domain 3 questions assess. Understanding how to reason about this risk is more exam-relevant than memorizing quantum computing specifics.

Related Guides