This is a bank Information Security and Cyber Risk view of quantum computing with a very specific lens: attacker economics, realistic exploit paths, and what we can do now that stays correct even if timelines move. This is not a prediction document.
- Audience: Quantum Computing Working Group, CISO staff, Enterprise Architecture, Risk Management
- Scope: Operational cost to run cryptanalytically-relevant quantum systems, security impact on common bank cryptography, and how attacker cost shapes realistic attack paths
- Sources referenced (high level): NIST PQC FIPS approvals (FIPS 203/204/205), Gidney–Ekerå RSA-2048 estimates, Google Security Blog updates, cryogenic refrigeration power references
One-Page Summary (For Quick Briefings)
- The risk: If a cryptanalytically relevant quantum computer (CRQC) exists, some widely-used public-key cryptography becomes breakable in a way that impacts certificates, identity, and trusted connections—not just “encrypted files.”
- The near-term issue: Adversaries can collect encrypted data now and attempt to decrypt it later. If we retain sensitive data for long periods, we’re increasing our future exposure by default.
- Why the economics matters: Early quantum capability will be scarce and expensive. Most attackers will keep choosing cheaper paths (credentials, platform compromise, fraud, process abuse) unless the payoff is unusually high and quantum is the only practical way in.
- What we should do now: Build a real crypto inventory, reduce long-term confidentiality exposure (especially archives), modernize certificate/key lifecycle and prove we can rotate at scale.
- What “good” looks like: Clear governance, measurable readiness metrics, and a phased transition plan aligned to standards and vendor roadmaps.
How to Use This Document (Working Group)
This paper is meant to drive productive cross-functional decisions. It’s not a claim about exactly when quantum breakthroughs happen.
Use it like this:
- Use the One-Page Summary to align on the narrative and avoid “sci-fi quantum panic.”
- Use Key Decisions Needed to drive steering committee outcomes.
- Use the Action Plan and Vendor Checklist to turn talk into work items.
- Treat the Cost Model as a scale/scarcity framing tool—not a procurement estimate.
Scope and Non-Goals
In scope
- Quantum as a cryptography transition and trust/identity problem for a bank
- Attacker economics: why scarcity and cost shape what is realistic
- Practical actions that reduce risk even under timeline uncertainty
Not in scope
- Forecasting dates for CRQC
- Detailed vendor-specific designs
- A bank budget estimate (this is for planning and prioritization)
Working Assumptions (for Discussion)
These are here so we don’t talk past each other:
- This is a multi-year transition and is constrained by vendor readiness and legacy systems.
- Early CRQC access is likely limited, expensive, and controlled, not commodity.
- Attackers will still pursue cheaper alternatives when they achieve the same outcomes.
- The highest exposure is long-lived confidentiality: data we keep for many years is the easiest “harvest now, decrypt later” target.
Executive Summary
Quantum computing is best treated as an asymmetric risk. The key point isn’t “quantum hacks banks.” The real issue is this: once a CRQC exists, RSA and most elliptic-curve cryptography (ECC) move from “effectively unbreakable” to “breakable with enough capability and access.” That shift hits the bank where it matters most: identity and trust—certificates, signatures, and secure connections.
From an InfoSec perspective, the near-term operational problem is not criminals running Shor’s algorithm tomorrow. The near-term problem is:
- Harvest now, decrypt later against data with long confidentiality requirements, and
- The reality that migrating the bank to post-quantum cryptography (PQC) is a long, messy, vendor-dependent program.
Attacker economics matters. Even optimistic estimates for breaking RSA-2048 assume enormous fault-tolerant systems—often discussed in ranges from ~1M up to ~20M physical qubits, depending on assumptions and architecture. That implies early capability shows up first in nation-state or major industrial contexts. Criminals will still prefer cheaper, lower-risk paths that bypass crypto entirely: CA/PKI compromise, DNS/control-plane attacks, key theft, endpoint compromise, identity fraud, and business process abuse.
Bottom line for bank InfoSec:
- Treat quantum as a strategic cryptography transition program, not a “quantum project.”
- Prioritize what must remain confidential for years (archives, legal holds, sensitive PII stores, investigative data, high-impact communications).
- Assume early CRQC access is scarce and expensive; most criminal ROI will still come from “cheap paths.”
- Plan for hybrid crypto in high-value channels and for rapid certificate/key rotation at scale.
What This Means for Our Bank (Plain-English Summary)
This topic is less about “quantum computers breaking into the bank” and more about trust over time.
- What changes: Some common public-key cryptography used for identity, certificates, and secure connections becomes vulnerable if CRQC exists.
- What likely happens first: Adversaries collect encrypted data now and try to decrypt it later—especially where confidentiality needs to hold for 5–10+ years.
- What probably does not happen first: Criminal groups don’t suddenly get a cheap “push-button” way to break bank systems. They’ll keep doing what works: steal creds, steal tokens, compromise endpoints, abuse processes, compromise platforms.
- What we should do: Treat this as modernization and resilience: know where crypto is used, reduce long-term exposure, and design for fast change.
Key Decisions Needed (Steering Committee)
If we want this to be executable and not just “interesting,” these decisions matter:
- Define long-life confidentiality: Which data types must remain confidential for 5–10+ years (and how long, realistically).
- Set transition posture: Pilot early (targeted, controlled) vs. wait for broad vendor maturity before moving.
- Confirm priority scope: Which channels and platforms are “first wave” (customer-facing, inter-bank, identity, critical internal).
- Set operational readiness targets: How fast we must be able to rotate compromised certificates/keys across critical services.
- Establish vendor expectations: What we require from key vendors (roadmaps, upgrade paths, evidence of testing).
- Define governance and exceptions: Who can approve delays, what evidence is required, and how risk acceptance is tracked.
Discussion Prompts (Working Group)
Use these to keep workshops outcome-oriented:
- Which data and records must remain confidential for 5–10+ years?
- Where do we rely most on certificates and trust chains (customer, inter-bank, internal)?
- How fast can we rotate certificates/keys today—realistically, at scale?
- Which vendors are “must-have” for transition (network/security products, identity, key management)?
- Where are our worst legacy constraints (systems we can’t upgrade quickly)?
- What decisions can we make now that remain correct no matter how timelines shift?
Where Cryptography Shows Up in a Bank (Quick Map)
Non-specialist point that matters: cryptography isn’t just “encryption.” It’s how systems prove identity and establish trust.
Common places it lives:
- Customer channels: web/mobile sessions, login flows, step-up auth, API security
- Internal connections: service-to-service, admin access, remote access
- Certificates and PKI: internal and external trust chains
- Software/device trust: code signing, device identity, update mechanisms
- Data protection: backups, archives, long-retention records
Practical implication: the “blast radius” is often identity, authentication, and trust chains, not just stored encrypted files.
1. Quantum Computing Primer (as it matters for security)
For security, there are two quantum algorithms we actually care about:
- Shor’s algorithm: breaks RSA and ECC discrete log at scale if you have a sufficiently large fault-tolerant quantum computer.
- Grover’s algorithm: speeds brute-force search roughly by square root, affecting symmetric crypto and hashes (usually mitigated by bigger key sizes/digests).
Security implications:
- RSA/ECC is the primary long-term concern (key exchange, certificates, signatures, some token schemes).
- AES and modern hashes remain usable with parameter adjustments (e.g., AES-256 instead of AES-128).
- PQC is already standardized for government use. Banks should align to those standards and to vendor roadmaps.
NIST has approved three PQC Federal Information Processing Standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA).
2. Crypto Impact Map for Common Bank Systems
Quantum impacts the bank mainly through public-key crypto (key exchange + signatures). Symmetric crypto and hashing are usually a parameter adjustment story, not a “throw it all out” story.
| Category | Common bank examples | Quantum impact | Mitigation / target state |
| Public-key (key exchange) | Secure connections (web/app), remote access, internal service-to-service | Shor breaks RSA/ECC key exchange | Move to post-quantum-ready key exchange; typically staged/hybrid transition |
| Public-key (signatures) | Certificates, code signing, document signing, device identity | Shor breaks RSA/ECC signatures | Move to post-quantum-ready signatures; staged/hybrid where needed |
| Symmetric encryption | Data-at-rest, backups, hardware-wrapped keys | Grover reduces margin | Use AES-256 and strong modes; review key management |
| Hashing / MAC | Integrity checks, password storage, tokens | Grover reduces margin for preimage search | Use strong hashing; keep password defenses strong |
| Protocols / PKI | CA chain, certificate status checks, pinning | If signatures break, trust chain weakens | PQ-capable PKI, shorter lifetimes, rapid re-issuance and rotation |
Practical read: quantum primarily threatens identity and trust (PKI), not just “encrypted blobs.”
3. Attacker Economics Framework (Cost vs Payoff)
Here’s the lens that keeps this grounded: attackers choose the cheapest reliable path to the objective. Quantum shifts the cost curve for breaking certain crypto, but attackers still compare it to conventional alternatives.
Five variables are enough to frame it:
- C_capex: cost to build/acquire capability (hardware, facilities, political access)
- C_opex: cost to operate (power, cryogenics, staffing, downtime)
- C_access: cost/risk to get time on the system (scarcity, monitoring, attribution, competition)
- V_target: value per successful outcome (money, intel, strategic advantage)
- R: probability of success and time to results (including retries)
A rational attacker uses quantum only if:
[
(V_{target} \times R) – (C_{capex} + C_{opex} + C_{access})
]
beats conventional approaches.
Implications for banks:
- Scarce compute pushes criminals toward repeatable, low-risk monetization—and most of that doesn’t require breaking crypto.
- Nation-states may justify high spend when the payoff is strategic.
- Even if RSA/ECC is theoretically breakable, the better ROI is often: key theft, CA/PKI compromise, DNS/control-plane takeover, endpoint compromise, identity fraud, process abuse.
4. How Big Is “Crypto-Relevant” Quantum?
Published estimates vary widely because assumptions vary: error rates, error correction overhead, architecture, and desired time-to-solution.
Two reference points that get cited a lot:
- Gidney–Ekerå: factoring RSA-2048 in ~8 hours under certain fault-tolerant assumptions, often mapped to ~20 million physical qubits in some surface-code scenarios.
- Google later discussed a path that could reduce that to roughly ~1 million physical qubits running for ~a week (still far beyond today).
How to interpret this (governance-friendly):
- Treat these as order-of-magnitude signals, not forecasts.
- Whether the threshold is 1M or 20M physical qubits, it implies an industrial-scale system—not a laptop tool.
- The stable conclusion is: migration time is long, and “harvest now” is real.
5. Operational Cost Model: Quantum vs Classical
Leadership will ask: “How expensive is this capability?” We should be honest: we can’t price a future technology precisely. But we can frame scale in a way that is credible and useful.
5.1 What drives operating cost for large quantum systems
- Cryogenics: dilution refrigeration, precooling, maintenance; cold is expensive and continuous
- Control electronics: RF/microwave control, readout, synchronization, low-noise amplification
- Facilities: power distribution, redundancy, vibration isolation, physical security
- Staffing: cryo technicians, RF engineers, quantum ops, reliability engineering, safety
- Uptime losses: calibration and sensitivity will dominate early operations; downtime is normal
5.2 Illustrative annual OpEx bands (power-only)
Cryogenic and supporting infrastructure can be power-hungry. Pulse-tube refrigeration for precooling is often described as consuming ~10 kW to provide ~1 W of cooling near 4 K (orders of magnitude matter here). Lab-scale dilution refrigerators are often described in the ~5–10 kW range depending on configuration; scaling to industrial multi-module systems changes everything.
These are illustrative bands designed to communicate scale:
| Scenario | Quantum scale assumption | Total facility load | Annual electricity @ $0.10/kWh | What it means |
| A (research CRQC) | ~1M physical qubits; modular | 50–150 MW | $44M–$131M | “Large data center class” |
| B (large CRQC) | ~4M physical qubits | 200–600 MW | $175M–$526M | Nation-state/mega-corp territory |
| C (very large CRQC) | ~20M physical qubits | 1–3 GW | $876M–$2.63B | Utility-scale industrial system |
Important: this is not a factual price quote. This is a framing tool: at RSA-2048-breaking scales, we’re talking about something that behaves like an industrial facility.
5.3 How to use this with leadership (without overpromising)
- Use the ranges to communicate scale, not precision.
- Different technical paths could shift numbers materially; don’t anchor to a single estimate.
- The security takeaway remains stable: early CRQC is likely scarce, expensive, and controlled.
6. Cost-Based Analysis: What Quantum Enables (and what it doesn’t)
Risk committees will ask: “So what does it cost to break our crypto, and what does that actually get them?” The right way to answer is to segment by outcome.
6.1 Bulk decryption vs targeted decryption
- Bulk decryption (criminal monetization): needs high throughput and low marginal cost. Early quantum is unlikely to be cost-effective.
- Targeted decryption (strategic intelligence): fewer targets, higher value. This is where nation-states can justify cost.
- Authentication/impersonation: if signatures are breakable and the ecosystem trusts them, attackers could mint identities—but many will still choose cheaper paths (CA compromise) if available.
6.2 What “break RSA” really means in real systems
Factoring RSA doesn’t magically “hack the bank.” It enables specific downstream actions depending on architecture:
- Decrypting recorded connections only in certain cases—especially depending on whether the channel used forward secrecy (stealing a long-term key later doesn’t automatically expose recorded past sessions).
- Forging signatures on certificates/software only if the ecosystem trusts that chain and there aren’t layered controls.
- Impersonating endpoints only if identity relies solely on vulnerable keys without device trust/attestation, key protection, behavioral signals, or compensating controls.
6.3 Harvest now, decrypt later (operational reality)
This is the simplest risk to explain: an attacker can record encrypted traffic or steal encrypted archives now, then try to decrypt later when capability exists.
Leadership guidance:
- The biggest concern is long-life confidentiality (sensitive customer data, legal holds, investigations, archives).
- If we can rotate keys/certs quickly and reduce unnecessary retention, we reduce future blast radius even before PQC is fully deployed.
- Security basics still dominate real-world outcomes: most breaches are stolen keys, stolen creds, compromised systems, not math breaks.
7. If Quantum Is Expensive, Where Do Attackers Go Instead?
Assume quantum compute exists but is scarce. Attackers will target choke points that deliver the same outcomes cheaper, quieter, and more repeatable.
7.1 High-ROI alternatives to direct crypto breaks
- CA / PKI compromise: issue fraudulent certs, intercept traffic, sign malware
- DNS / routing attacks: redirect users, harvest tokens, downgrade controls
- Key theft: steal private keys from endpoints, build systems, secrets stores, backups, admin consoles
- Identity proofing & ATO: SIM swaps, session theft, social engineering, helpdesk abuse
- Recovery/enrollment abuse: bypass “strong crypto” through weak human processes
- Session/token theft: steal active sessions instead of breaking encryption
- Control-plane compromise: cloud admin, IAM, secrets managers, CI/CD—own the platform beats breaking math
- Supply chain compromise: update channels, packages, signing keys
These are cheaper, easier to scale, and usually less attributable than running specialized quantum jobs.
7.2 Why CA and DNS become especially attractive
If public-key crypto becomes questionable, trust anchors matter more. Attacking the trust anchor (CA/DNS/registrar/device trust stores) can scale across many victims with lower compute and higher reliability.
7.3 Bank-specific “cheap paths” to the same objectives
- Steal service/API keys that gate payment workflows
- Compromise privileged access to payments/reconciliation platforms
- Attack customer channels to steal session tokens at the application layer
- Abuse customer support and account recovery paths
- Compromise email/collaboration tooling used for approvals and payment instruction workflows
- Compromise third-party integrations/MSPs and pivot inward
- Attack monitoring/logging integrity to extend dwell time
8. What Must Be True for Criminals to Justify Quantum Cost?
Organized cybercrime will rent, buy, or steal capability when three things are true: repeatable monetization, operational safety, and sufficient access time.
8.1 Repeatable monetization examples
- A widely used product where vulnerable keys are embedded/reused (rare if hygiene is good)
- Legacy crypto at scale where forward secrecy isn’t used and static keys are common
- Large-scale impersonation if the identity ecosystem depends on vulnerable signatures without layered controls
8.2 Operational safety realities
- CRQC use will likely be monitored; large Shor jobs are not subtle
- Scarcity creates broker markets; broker markets increase law-enforcement and counter-intel risk
- Criminal groups prefer capabilities that are easy to distribute and hide—industrial facilities are neither
8.3 Sufficient access time
Even optimistic models can assume days of stable runtime. Criminal operationalization needs dependable scheduling and quality-of-service—this looks more like a state or major vendor service model than a typical underground marketplace.
9. Who Can Realistically Build and Operate CRQC-Class Systems?
The first organizations to achieve CRQC-scale access are those that can fund multi-billion-dollar R&D and operate specialized facilities:
- Governments / intelligence services: strategic incentives, long timelines, tolerance for massive CapEx
- Major technology firms: talent, supply chain leverage, modular engineering capability
- National labs / consortia: strong science capability, slower operationalization
- Quantum vendors: likely via partnerships and national support rather than alone
Implication: early quantum capability is likely capacity constrained and policy constrained.
10. Could Organized Crime Use Quantum via Shared Tenancy?
Key question: could criminals “rent” quantum the way they rent cloud GPUs?
10.1 Shared tenancy is possible in theory, constrained in practice
- Multi-tenancy requires strong isolation, scheduling, remote job submission
- CRQC-class hardware will likely face restricted access and geopolitical controls
- Error-corrected Shor is not a commodity workload; orchestration and calibration are non-trivial
10.2 More plausible model: brokers and insiders
- Insider access could leak time-on-system or results
- Brokers might sell outputs (factored keys) rather than raw compute time
- State-aligned criminal groups could receive capability via sponsorship
10.3 Scarcity pushes cost up
If CRQC becomes real, governments and critical infrastructure will compete for access. Scarcity increases “price per run,” reducing criminal viability and pushing criminals toward cheaper non-quantum paths.
11. Bank Infrastructure Components Likely Targeted (Under Quantum Scarcity)
If direct cryptanalysis is expensive, attackers will go after trust, identity, and control plane.
11.1 Trust and control-plane components
- PKI / CA infrastructure (issuance workflows, signing keys, HSM-backed controls)
- DNS (authoritative zones, registrar controls, resolvers, monitoring)
- Identity providers (SSO, MFA, enrollment, recovery)
- Privileged access and admin pathways (admin consoles, approvals, break-glass)
- Remote access and third-party access gateways
- Secrets management (vaults, CI/CD secrets, API keys)
- Time and update trust (NTP posture, update channels, package registries)
- Endpoint/device management (MDM, EDR, patch tooling, configuration enforcement)
- Corporate communications identity (email/collaboration used for approvals and “human trust”)
11.2 High-value data stores and flows
- Traffic captures/logs that may be decrypted later (especially if forward secrecy isn’t used consistently)
- Backups/archives with long retention and high confidentiality requirements
- Payment workflow data where integrity/authentication compromise enables fraud
12. What Happens If the Bank Migrates to PQC (and what remains exploitable)
PQC reduces exposure to Shor, but it doesn’t make the bank “quantum proof.” It shifts the cryptographic attack surface while leaving system weaknesses intact.
12.1 Expected benefits
- Reduces long-term exposure for key exchange and signatures if deployed correctly
- Forces crypto agility and better certificate/key lifecycle discipline
- Improves governance: inventory, vendor requirements, metrics
12.2 Residual risks
- Implementation bugs, immature tooling, performance impacts (bigger keys/handshakes)
- Legacy systems and embedded devices will be the long tail
- Key theft remains key theft (PQC keys can still be stolen)
- Downgrade/misconfiguration risks; hybrid modes must be designed carefully
13. Bank Cost to Respond: The PQC Transition Program
Our cost is mostly a multi-year engineering + governance program, not a one-time purchase. The variability is driven by how centralized our certificate management is, and how modern our stacks are.
13.1 Typical cost buckets
- Crypto inventory/discovery: scanning, dependency mapping, certificate/key registry modernization
- Standards/architecture: algorithm policy, hybrid guidance, minimum parameters, timelines
- PKI modernization: CA upgrades, automation, shorter lifetimes, rotation drills
- Vendor uplift: readiness, contracts, roadmap tracking, testing
- Application/infrastructure upgrades: load balancers, gateways, remote access, service-to-service, libraries
- Testing/performance: handshake latency, bandwidth, mobile constraints, HSM compatibility
13.2 Illustrative program sizing (not a budget)
| Program element | Effort driver | Indicative scale (mid-large bank) |
| Crypto inventory | System diversity and discovery maturity | 3–9 months baseline; continuous thereafter |
| Secure connections / certificates uplift | Certificate sprawl + automation | 6–18 months for core modernization |
| App remediation | Legacy stacks + vendor constraints | 12–36 months across portfolio |
| Vendor transition | Contract cycles + product roadmaps | 18–48 months aligned to renewals |
| Operational readiness | Rotation drills + playbooks | Quarterly exercises; ongoing |
14. Scenario Analysis: “Cost to Attack” vs “Cheapest Path”
This is decision support, not prediction.
Scenario 1: Nation-state targeting strategic bank communications
- Objective: decrypt sensitive historical communications or impersonate trusted infrastructure
- Quantum use: feasible when strategic value is high and access is controlled
- Cheapest path may still be: CA compromise, endpoint compromise, telecom/vendor leverage, lawful access
- Reality for banks: impact looks like high-end intrusion—hard attribution, long-term confidentiality exposure
Scenario 2: Cybercrime monetization at scale (fraud)
- Objective: steal money repeatedly with low risk
- Quantum use: unlikely early; too scarce and too attributable
- Likely path: ATO, SIM swap, social engineering, malware, token theft, API key theft, payment workflow abuse
Scenario 3: Vendor ecosystem compromise
- Objective: compromise a widely used vendor to scale across many victims
- Quantum use: only if vulnerable crypto yields repeatable compromise
- More likely: supply chain malware, CI/CD compromise, signing key theft; quantum becomes relevant if signatures can be forged or keys derived
15. Indicators the Bank Should Monitor
If we don’t define measurable indicators, this stays “quantum fear” instead of governance.
- Crypto inventory coverage: % of systems with known algorithms/libraries/cert dependencies
- Certificate lifecycle maturity: time to rotate certs/keys; automation coverage
- PQC vendor readiness: top vendors with published PQC timelines; gaps and risk
- Secure-connection posture: forward secrecy adoption; removal of older configurations
- Data-at-rest posture: long-retention archives using AES-256 + strong key management
- External signals: credible error-corrected scaling demonstrations, standards adoption, government policy shifts
16. Control Recommendations (Bank InfoSec)
These controls reduce risk whether CRQC arrives in 5 years or 15.
16.1 Controls that directly reduce quantum cryptography exposure
- Adopt a bank cryptographic standard anchored to NIST PQC FIPS and define migration timelines
- Implement continuous crypto discovery (cert inventory, endpoint scanning, dependency mapping)
- Use staged/hybrid transitions for the highest-value channels where practical
- Reduce long-term confidentiality exposure: AES-256, strong key management, retention minimization where permissible
16.2 Controls that reduce “cheapest path” alternatives
- Harden CA/cert issuance: HSM-backed keys, strict workflows, strong logging, separation of duties, rotation drills
- Secure DNS/registrar: strong access controls, registry locks, configuration hardening, monitoring for changes
- Strengthen secrets management: remove secrets from code, rotate API keys, enforce least privilege
- Improve identity recovery and customer auth to reduce ATO: device binding, step-up, fraud analytics
- Reduce session/token theft: protect tokens, shorter lifetimes where possible, detect unusual logins
- Harden privileged access: separate admin accounts, reduce standing access, approvals for high-risk actions, monitoring
- Secure remote/third-party access: time-bound access, strong auth, device checks, monitoring
- Protect supply chain: secure update channels, protect signing keys, monitor CI/CD integrity
- Protect “human trust” workflows: secure email/collaboration used for approvals; add verification steps for high-risk actions
17. Governance: Roles, Responsibilities, and Decision Rights
Quantum readiness is cross-functional. Clarity matters more than perfect forecasts.
- InfoSec / Cyber Governance (2nd line): set crypto standards, define posture, require inventory, metrics/reporting, validate exceptions
- Security Engineering / Architecture (1st line): target-state patterns, reference implementations, hybrid guidance
- Infrastructure / Network: upgrade endpoints/gateways/load balancers/service mesh; remove weak configs
- Application teams: update dependencies, remediate hardcoded crypto, test performance and compatibility
- Vendor management: bake PQC readiness into third-party risk and contracts
- Legal / Records: align retention and confidentiality requirements to harvest-now risk
18. High-Level Bank Action Plan (Phased)
18.1 0–6 months: Get control of inventory and narrative
- Stand up a bank-wide crypto inventory (systems, vendors, certificates, long-life confidentiality data)
- Identify long-life confidentiality datasets/flows; validate retention + protection expectations
- Set near-term policy direction anchored to NIST PQC (what we adopt and when)
- Run a rotation drill: prove we can reissue and deploy certs/keys quickly at scale
18.2 6–18 months: Pilot and modernize the trust layer
- Modernize certificate/trust workflows so rotation is routine, automated, auditable
- Pilot PQC/hybrid options in limited high-value channels; prioritize interoperability and operational reality
- Update vendor expectations: roadmaps, upgrade paths, testing evidence
18.3 18–48 months: Expand adoption and retire legacy dependencies
- Expand across priority platforms as vendor support matures
- Reduce the long tail: legacy systems, embedded dependencies, hard-to-change products
- Formalize retirement timelines for legacy crypto + exception handling
19. Governance and Metrics (Executive-Friendly)
Quantum readiness succeeds when it’s treated like an enterprise control program: ownership, reporting, measurable outcomes.
Decision points
- Policy stance: which algorithms are approved for new builds; what phases out and when
- Scope priorities: which channels/data types move first
- Exception process: what “temporary” means and how risk is tracked
Suggested metrics
- Inventory coverage: % of critical systems with known crypto dependencies + certificate ownership
- Rotation readiness: time to replace compromised cert/key across critical services
- Vendor readiness: % of top vendors with PQC roadmap + tested upgrade path
- Long-life protection: % of long-retention archives using strong encryption + key management
20. Vendor and Third-Party Readiness Checklist (High-Level)
Use this to structure vendor conversations:
- Provide current cryptography dependencies (certs, signing, encryption)
- Provide a timeline for supporting NIST PQC standards in relevant products
- Provide an upgrade plan that doesn’t require disruptive redesigns for customers
- Support rapid certificate/key rotation with documented operational procedures
- Provide evidence of testing and interoperability (so upgrades don’t break connectivity)
Open Questions and Next Inputs (Working Group Tracker)
Open questions
- What are our top long-life confidentiality datasets and required protection duration?
- Which critical systems cannot meet fast rotation expectations today—and why?
- Which top vendors have credible roadmaps vs. unclear/high-risk postures?
- For highest-value channels: pilot early or wait for broader maturity?
Next inputs to collect
- Current-state view of certificate/key ownership and rotation ability for critical services
- Ranked list of systems/data stores by confidentiality duration and business impact
- Vendor statements/roadmaps relevant to our environment (as available)
Appendix A. Worked Example: “Price per Break” Thought Experiment
This appendix helps explain why cost shapes attacker choices without pretending we can price quantum precisely.
A.1 Assumptions
- Attacker access is via a state sponsor, major vendor, or broker market
- Quantum job time is scarce and expensive (power + staffing + depreciation + scarcity premium)
- Each RSA-2048 run requires hours-to-days when you include calibration, retries, and operational overhead
A.2 Executive-friendly conclusion
If the marginal cost of a quantum run is comparable to—or exceeds—the payoff, criminals won’t use it. They’ll pick cheaper alternatives. Quantum becomes relevant when the value is strategic, repeatable, or when other paths are blocked.
Appendix B. Reference: PQC Standards Snapshot
NIST has approved the following PQC standards for federal use, which banks typically use as an anchor for roadmaps:
| Standard | Function | Algorithm family | Typical bank use cases |
| FIPS 203 | Key encapsulation (KEM) | ML-KEM (Kyber) | Secure connection + remote access setup during transition |
| FIPS 204 | Digital signatures | ML-DSA (Dilithium) | Code signing, device identity, document signing |
| FIPS 205 | Digital signatures | SLH-DSA (SPHINCS+) | Backup signature option, high-assurance signing |
Appendix C. Source Notes and References (High-Level)
- NIST (Aug 13, 2024): approval of PQC FIPS 203/204/205
- Gidney & Ekerå (2021): RSA-2048 factoring estimates under fault-tolerant assumptions
- Google Security Blog (May 23, 2025): cost discussion / updated framing for quantum factoring
- Cryogenic refrigeration references: pulse-tube and dilution refrigeration power characteristics (order-of-magnitude)
Glossary (Plain Language)
- CRQC: cryptanalytically relevant quantum computer—large/stable enough to threaten widely used public-key crypto
- PQC: post-quantum cryptography—algorithms designed to resist classical and quantum attacks
- PKI / certificates: systems and trust chains used to prove identity and establish secure connections
- RSA / ECC: common public-key crypto families used today for key exchange and signatures
- CA: certificate authority—issues certificates that systems trust
- MFA: multi-factor authentication
- SSO: single sign-on
- ATO: account takeover
- SIM swap: hijacking a phone number to intercept text message passcodes
- API key: system-to-system credential
- Hybrid approach: using classical + PQC during transition to reduce risk while ecosystems mature
- Harvest now, decrypt later: collecting encrypted data now to decrypt later if capability emerges
- Forward secrecy: property where later theft of a long-term key doesn’t automatically expose past recorded sessions
Algorithms
Below is a compact table covering:
- Currently deployed classical algorithms
- Quantum-vulnerable public-key algorithms
- Post-Quantum (PQC) NIST-selected algorithms
- Their quantum readiness
Symmetric Encryption
| Algorithm | Type | Short Description | Quantum Readiness |
| AES-128 | Symmetric block cipher | Most widely used encryption (TLS, disk, DB, VPN) | ⚠️ Reduced strength under Grover (effective ~64-bit) |
| AES-256 | Symmetric block cipher | Stronger AES variant | ✅ Considered quantum-resistant (effective ~128-bit) |
| ChaCha20 | Stream cipher | Used in TLS & mobile devices | ⚠️ Reduced security margin but still strong |
| 3DES | Block cipher | Legacy banking cipher | ❌ Not secure (classical + quantum) |
Note: Symmetric crypto is NOT broken by quantum — just requires doubling key size.
Public-Key Encryption (Key Exchange / Encryption)
| Algorithm | Type | Short Description | Quantum Readiness |
| RSA-2048 | Integer factorization | TLS certs, VPN, S/MIME | ❌ Broken by Shor |
| RSA-3072 | Integer factorization | Higher strength RSA | ❌ Broken by Shor |
| Diffie-Hellman (DH) | Discrete log | Key exchange | ❌ Broken by Shor |
| ECDH (P-256, P-384) | Elliptic curve | Modern TLS key exchange | ❌ Broken by Shor |
| ElGamal | Discrete log | Encryption scheme | ❌ Broken by Shor |
All classical public-key encryption = Not quantum safe
Digital Signatures (Classical)
| Algorithm | Type | Short Description | Quantum Readiness |
| RSA-2048 Signature | Integer factorization | TLS, DNSSEC, code signing | ❌ Broken by Shor |
| ECDSA | Elliptic curve | TLS, JWT, blockchain | ❌ Broken by Shor |
| DSA | Discrete log | Legacy signature | ❌ Broken by Shor |
| Ed25519 | Elliptic curve | Modern lightweight signature | ❌ Broken by Shor |
All classical signature schemes = Not quantum safe
Hash Functions
| Algorithm | Type | Short Description | Quantum Readiness |
| SHA-256 | Hash | Integrity, signatures, blockchain | ⚠️ Grover halves strength (~128-bit) |
| SHA-384 | Hash | Higher security hash | ⚠️ Reduced margin but strong |
| SHA-3 | Hash | Modern alternative to SHA-2 | ⚠️ Reduced margin but strong |
| MD5 | Hash | Legacy | ❌ Broken classically |
Hashes are not catastrophically broken by quantum, but security margin halves.
NIST-Selected Post-Quantum Encryption (Key Establishment)
| Algorithm | Type | Short Description | Quantum Readiness |
| CRYSTALS-Kyber (ML-KEM) | Lattice-based KEM | NIST selected PQ encryption | ✅ Quantum-resistant |
| Classic McEliece | Code-based | Long-studied PQ encryption | ✅ Quantum-resistant |
| BIKE (alternate) | Code-based | PQ candidate | ✅ Quantum-resistant (pending finalization) |
| HQC | Code-based | PQ candidate | ✅ Quantum-resistant (pending finalization) |
These replace RSA / ECDH.
NIST-Selected Post-Quantum Signatures
| Algorithm | Type | Short Description | Quantum Readiness |
| CRYSTALS-Dilithium (ML-DSA) | Lattice-based | Primary NIST PQ signature | ✅ Quantum-resistant |
| Falcon | Lattice-based | Smaller signatures, complex math | ✅ Quantum-resistant |
| SPHINCS+ | Hash-based | Conservative, slower | ✅ Quantum-resistant |
These replace RSA/ECDSA/EdDSA.
Hybrid (Transition Models)
| Approach | Description | Quantum Readiness |
| RSA + Kyber | Classical + PQ combined | ✅ Secure if PQ holds |
| ECDH + Kyber | Hybrid TLS model | ✅ Current migration model |
| ECDSA + Dilithium | Hybrid signature | ✅ Migration path |
Hybrid = Recommended transition approach today
Quick Risk Summary Table
| Category | Quantum Impact | Action |
| Symmetric (AES-256) | Minimal | Keep 256-bit |
| Hash (SHA-256/3) | Manageable | Prefer SHA-384+ |
| RSA / ECC | Total break | Migrate |
| DNSSEC (RSA/ECDSA) | Total break | Plan PQ DNSSEC |
| Code Signing | Total break | High priority |
| VPN / TLS | Total break | Hybrid migration |
Bottom Line
- Anything based on factoring or discrete log = broken
- Symmetric crypto = safe with larger keys
- PQC algorithms (Kyber/Dilithium) = future safe
- Migration should be hybrid-first
Leave a Reply