Navigate the Cryptographic Resilience Transition with Confidence

This tribute examines Anderson's seminal 2001 paper "Why Information Security is Hard – An Economic Perspective" and his later work on protocol maintenance costs, demonstrating how his prescient analysis anticipated the very obstacles that make PQC migration so difficult today.

The Central Insight: It's the Incentives, Not the Technology

Anderson's foundational observation was deceptively simple yet revolutionary:

"Information insecurity is at least as much due to perverse incentives... Many of the problems can be explained more clearly and convincingly using the language of microeconomics."

Before Anderson, the security community believed better tools would solve security problems. He demonstrated that the real barriers were economic: network externalities, asymmetric information, moral hazard, adverse selection, liability dumping, and the tragedy of the commons.

Why this matters for PQC: Financial institutions today face the same perverse incentives Anderson identified. The party in the best position to implement PQC protection (the bank) is often not the party who will suffer most from quantum-enabled decryption attacks (the customer whose data is harvested today for decryption in 2035).

Liability Dumping: Anderson's Banking Prophecy

Anderson's early research on ATM fraud revealed a pattern that persists today:

"In the USA, if a customer disputed a transaction, the onus was on the bank to prove that the customer was mistaken or lying; this gave US banks a motive to protect their systems properly. But in Britain, Norway and the Netherlands, the burden of proof lay on the customer... Since this was almost impossible, the banks in these countries became careless."

The result? US banks, despite spending less on security, achieved better outcomes—because their incentives aligned protection with liability.

The PQC parallel is striking. Under current liability frameworks, banks have had limited economic incentive to begin expensive PQC migrations when:

• Quantum computers capable of breaking RSA don't yet exist
• Until the January 2025 EU DORA, banking sector regulations haven't explicitly mandate PQC readiness
• Customers cannot prove their data was harvested for future decryption
• The harm from "Store Now, Decrypt Later" attacks won't materialise for years

Anderson would immediately recognise this as a classic liability dump: banks control protection decisions today, but the customer (and eventually society) bears the risk tomorrow.

The Tragedy of the Commons and Cryptographic Infrastructure

Anderson's application of the "Tragedy of the Commons" to distributed denial-of-service attacks translates directly to cryptographic infrastructure:

"While individual computer users might be happy to spend $100 on anti-virus software to protect themselves against attack, they are unlikely to spend even $1 on software to prevent their machines being used to attack Amazon or Microsoft."

For PQC migration: Cryptographic infrastructure has been a shared commons for decades. TLS certificates, HSMs, key management systems, and cryptographic libraries are embedded throughout banking infrastructure, managed by different teams with different budgets and priorities. No single owner has the authority—or the budget—to upgrade everything.

The tragedy unfolds when each business unit sees PQC as "someone else's problem," shared infrastructure teams lack budget for quantum-safe upgrades, and third-party vendors await customer demand before investing.

Network Externalities and the "Microsoft Philosophy"

Anderson explained why software ships insecure:

"The huge first-mover advantages that can arise in economic systems with strong positive feedback are the origin of the so-called 'Microsoft philosophy' of 'we'll ship it on Tuesday and get it right by version 3'... This is perfectly rational behaviour in many markets where network economics apply."

The PQC vendor landscape exhibits identical dynamics. Discovery tool vendors race to market, prioritising features and speed over comprehensive testing. Integration complexity is pushed onto customers. Banks are sold tools designed to appeal to procurement timelines rather than operational reality.

The Protocol Maintenance Problem

Anderson's later work, particularly "The Initial Costs and Maintenance Costs of Protocols" (Security Protocols 2005), directly anticipated PQC challenges:

"Security maintainability is the elephant in the living room; people know there's an awful problem but are generally too polite to mention it."

He identified why the security community long ignored maintenance:

"Vendors used to not care very much; after all, people replace their mobile phones every year, and their PCs every three to five years, so why not just wait for the vulnerable equipment to be thrown on the skip?"

PQC migration breaks this assumption catastrophically. Banking infrastructure operates on 20–30 year replacement cycles. HSMs, core banking systems, and SWIFT interfaces installed in the 2010s will still be operational in 2035. You cannot wait for "vulnerable equipment to be thrown on the skip" when quantum computers may break currently deployed encryption before scheduled hardware refresh.

Asymmetric Information and the "Lemons" Problem

Anderson applied Akerlof's famous "lemons" analysis to security products:

"When buyers don't have as much information about the quality of products as sellers do, there will be severe downward pressure on both price and quality."

The PQC market exhibits classic "lemons" characteristics:

• Buyers cannot easily evaluate cryptographic implementation quality
• Claims about "quantum-safe" products cannot be verified by non-specialists
• Market selection favours vendor marketing over technical merit
• The "nobody gets fired for buying IBM" effect drives procurement toward established names regardless of PQC competence

The Common Criteria Failure and Certification Theatre

Anderson's critique of security evaluation was blistering:

"The European equivalent, ITSEC, introduced a pernicious innovation – that the evaluation was not paid for by the government but by the vendor seeking an evaluation on its product... This motivated the vendor to shop around for the evaluation contractor who would give his product the easiest ride."

This warning applies directly to emerging PQC certifications. As quantum-safe products enter the market, certification schemes will emerge. Without structural changes to who pays for evaluation and who bears liability for certification failures, these schemes will reproduce the pathologies Anderson identified.

"Making Security Sustainable": Anderson's Final Warning

Anderson's 2018 CACM article addressed long-term software maintenance:

"We have no idea how to patch 20-year-old software; so we will need fresh thinking about compilers, verification, testing, and much else."

This is the PQC challenge in a nutshell. Financial services infrastructure requires security maintenance for decades. Yet we have no established methodology for migrating cryptographic algorithms across 20+ year system lifetimes while maintaining operational continuity.

Applying Anderson's Framework to PQC Strategy

What would Anderson advise a financial institution beginning PQC migration?

1. Map the Incentives, Not Just the Infrastructure

Before any technical discovery, understand: Who bears the cost of migration? Who suffers the consequences of delay? What regulatory changes would shift these incentives?

2. Assign Clear Liability

Establish accountable ownership before deployment. Anderson's research showed that security improves when the party who can protect a system is also the party who suffers from failure.

3. Budget for Maintenance, Not Just Implementation

PQC isn't a one-time deployment; it's a 20-year maintenance commitment. Build budget cases that reflect ongoing cryptographic agility costs.

4. Distrust Vendor Certifications

Apply Anderson's scepticism to PQC product claims. Ask who paid for evaluations, who benefits from positive findings, and what liability vendors accept.

5. Coordinate to Escape the Tragedy of the Commons

Individual bank action is insufficient. Industry coordination (through bodies like FS-ISAC and CMORG) and regulatory frameworks (like DORA) are necessary to overcome collective action problems.

6. Start with Governance, Not Tools

Anderson's analysis of why technical solutions fail makes clear: governance frameworks, liability assignments, and budget authority must precede technical deployment.

Conclusion: The Prescience of a Pioneer

Ross Anderson saw further than anyone. In 2001, he predicted that security would increasingly become an economic problem requiring economic solutions. His work on protocol maintenance costs anticipated the PQC challenge by two decades. His analysis of liability dumping explains why banks hesitate to begin expensive migrations whose benefits accrue to future customers.

As Bruce Schneier wrote in his obituary: "He was the first person to understand that security problems are often actually economic problems."

For PQC migration, this insight is not merely academic—it is operational. Financial institutions that treat PQC as purely a technology problem will fail. Those that apply Anderson's economic lens—understanding incentives, liabilities, and coordination requirements—will navigate the transition successfully.

We stand on the shoulders of giants. Ross Anderson gave us the conceptual tools to understand why security is hard. It falls to us to apply those tools to the greatest cryptographic transition since the move to public-key cryptography.

Key References:

• Anderson, R. (2001). "Why Information Security is Hard – An Economic Perspective"
• Anderson, R. (2007). "The Initial Costs and Maintenance Costs of Protocols" - Security Protocols 2005, LNCS 4631
• Anderson, R. (2018). "Making Security Sustainable" - CACM
• Article 6 (including 6.4) DORA Regulatory Technical Standard for ICT Risk Management
• Cross-Market Operational Resilience Group (CMORG) Guidance for Post-Quantum Cryptography
• FS-ISAC Post Quantum Cryptography (PQC) Business Guidance
• Professor Ross Anderson's Research Archive
• Recital 9 DORA Regulatory Technical Standard for ICT Risk Management
• Schneier, B. (2024). "In Memoriam: Ross Anderson" - CACM

In our tribute to Ross Anderson, we explored how his security economics framework explains the obstacles financial institutions face in PQC migration. But there's a deeper question: why is this cryptographic transition so much harder than previous ones?

The answer lies in a concept from Science and Technology Studies: technological momentum.

Large Systems Don't Just Exist—They Persist

In 1987, historian Thomas P. Hughes analysed how large technological systems evolve. His key insight was that mature systems develop "momentum"—a combination of infrastructure, institutional commitments, trained expertise, and cultural assumptions that makes fundamental change progressively more difficult.

Hughes wasn't writing about cryptography. He was analysing electrical power networks. But his framework illuminates exactly why PQC represents a categorically different challenge.

The Critical Window: 1995–1999

Before 1995, cryptographic systems served bounded populations where coordination remained manageable. The explosive growth of consumer internet usage created the conditions for technological lock-in. By 1999, the system had acquired substantial momentum. Every subsequent transition occurred within the established paradigm.

Previous Transitions: Incremental Change

TLS protocol migrations involved updates with explicit backward compatibility. The underlying RSA/ECC algorithms remained unchanged.

SHA-1 to SHA-2 occurred within existing certificate infrastructure. The X.509 format remained unchanged; only the signature algorithm identifier differed.

DES to AES affected specific applications—disk encryption, VPNs—not the certificate infrastructure underpinning internet security.

These transitions share common characteristics: incremental changes, maintained backward compatibility, and crucially—no requirement to replace fundamental public-key algorithms.

PQC: The First Fundamental Transition Since Lock-In

PQC is categorically different. It's the first cryptographic transition since technological momentum was established that requires fundamental paradigm change.

Maximum path dependency. Thirty years of infrastructure accumulation. Every technology wave—mobile, cloud, IoT, APIs—has embedded RSA/ECC dependencies.

No backward compatibility. PQC algorithms cannot interoperate with classical algorithms for security-critical applications.

Fundamental algorithm replacement. Unlike hash algorithm updates, PQC requires replacing RSA and ECC—the mathematical foundations deployed globally since the 1990s.

Ecosystem-wide coordination. PQC affects certificates, key exchange, signatures, HSMs, and every system depending on public-key cryptography.

The Perfect Storm

This is why PQC faces something previous transitions never did: all of Anderson's perverse incentive categories operating simultaneously.

Network externalities prevent early movers from capturing full benefits. Information asymmetry about quantum timelines prevents informed decisions. Moral hazard distorts risk calculations. Adverse selection makes vulnerability invisible. Liability dumping shifts costs to customers.

Previous transitions faced one or two of these barriers. PQC faces them all—precisely because it's the first fundamental change since the system acquired momentum.

What This Means

Understanding technological momentum isn't merely academic. It explains why PQC cannot be approached like previous upgrades—and why the transition ahead isn't an upgrade at all, but the first fundamental reconfiguration since the paradigm was established.

That's why governance before tools matters. That's why Pre-Discovery™ matters. And that's why success requires recognising PQC for what it is: not another version update, but a once-in-a-generation transformation.

References:

• Hughes, T.P. (1987). "The Evolution of Large Technological Systems" in The Social Construction of Technological Systems
• Anderson, R. (2001). "Why Information Security is Hard—An Economic Perspective"

Tim D Williams is Chief Technology Officer at ProteQC. He is undertaking academic research on security economics and PQC transitions for publication later this year. This blog previews aspects of Tim's research.

When it comes to cryptography and the threat of harvest now, decrypt later (HNDL) attacks, most consumers assume it doesn't apply to them. It can feel too technical or just out of reach. However, if you've taken out a 20‑ or 30‑year mortgage, you're already at risk.

According to Mordor Intelligence's Home Loan Market Size, Forecast, Trends, loans with maturities over 20 years made up 48.58% of the global home loan market in 2025. That's nearly half the market tied to long-term financial commitments. And with those commitments comes the long-term storage of your personal data. That means almost half of all home loans involve extended obligations, which require banks to store customer data securely for decades. When you take out a mortgage, you are trusting your bank with sensitive personal and financial information such as your name, Social Security number, credit history, property details, and payment schedules. This data must remain protected for the full life of the loan.

HNDL attacks put long-term protection at risk. In these scenarios, attackers capture encrypted data today and hold onto it, waiting until future technologies like quantum computing allow them to break current encryption. Data that appears secure now could very well be compromised years later if security standards don't evolve.

So What Should Banks Do?

• Accelerate cryptographic upgrades: Start deploying post-quantum cryptography to strengthen and modernize existing systems.
• Build cryptographic agility: Use flexible security systems that can evolve as standards and threats change.
• Governance first: Implement governance and risk frameworks to track sensitive data and encryption usage. This is precisely the approach we advocate with our Pre-Discovery™ methodology—understanding what you're protecting before reaching for technical tools.
• Educate and engage: Communicate clearly with customers about long-term data protection strategies to build trust.

What Questions Should Customers Ask Their Mortgage Lenders?

• How is my personal and financial data being encrypted and stored over the life of my loan?
• What steps are you taking to protect my information from future threats like quantum computing?
• Are your systems prepared to adapt to new encryption standards as technology evolves?
• Do you have policies in place to regularly review and update data protection practices?

Final Thoughts

Protecting customer data is more than a technical challenge. It is a long-term commitment to trust, especially in a time when today's encryption must stand up to tomorrow's breakthroughs. Banks need to act before the risk grows. Even if quantum computing is still developing, encrypted mortgage data collected today is already a target. To maintain trust and ensure lasting security, financial institutions should begin upgrading their cryptographic systems and prepare for a post-quantum future.

Source: Mordor Intelligence: Home Loan Market Size, Forecast, Trends (2025)

Where does quantum computing risk appear in your enterprise risk register? Under which category? With which owner? If your team struggled to answer, you've encountered risk taxonomy blindness.

The Problem: Risks That Don't Fit

Enterprise risk taxonomies evolved to categorise familiar threats: credit risk, market risk, operational risk, cyber risk. These categories reflect historical experience and regulatory expectations. They work well—for risks that fit.

Quantum computing risk doesn't fit. It's:

• Not purely cyber risk (it doesn't exploit vulnerabilities in the traditional sense)
• Not purely technology risk (it's fundamentally about cryptographic assumptions)
• Not purely strategic risk (it has specific technical mitigations)
• Not purely compliance risk (though regulations are emerging)

When risks don't fit existing categories, organisations face a structural problem: nobody owns them.

Why Taxonomy Matters

Enterprise risk management depends on clear ownership. Risk categories define which committees review threats, which budgets fund mitigations, which executives are accountable. When a risk doesn't appear in the taxonomy:

• It doesn't get discussed at the right governance forums
• It doesn't receive dedicated budget allocation
• It doesn't have an accountable owner who tracks progress
• It falls into "somebody else's problem" territory

The SNDL Accounting Challenge

"Store Now, Decrypt Later" (SNDL) attacks create particular taxonomy problems. If adversaries steal encrypted data today for future decryption:

• When did the breach occur? At data exfiltration (perhaps years ago) or at decryption (in the future)?
• Who bears liability? Management at time of theft or management at time of impact?
• What's the current risk exposure? Unknown, since we can't inventory what's already been stolen

Traditional risk registers struggle with threats that span decades between cause and consequence.

How Financial Institutions Are Adapting

Leading organisations are addressing taxonomy blindness through:

1. Creating explicit "Cryptographic Risk" categories that sit alongside (not within) cyber risk
2. Assigning dual ownership between CTO/CISO and CRO/compliance functions
3. Establishing quantum-specific governance forums with board visibility
4. Treating crypto-agility as an operational resilience requirement under DORA frameworks

Questions for Your Risk Committee

Test your organisation's taxonomy health:

• Where does "quantum computing risk" appear in our risk register?
• Who owns this risk and reports to the board?
• What budget exists specifically for PQC readiness?
• How do we measure and track cryptographic risk exposure?
• When did this risk last receive dedicated committee discussion?

If these questions prompt uncomfortable silences, your risk taxonomy needs updating before your cryptographic infrastructure does.

"You cannot manage what you cannot name. And you cannot name what doesn't fit your categories."

Most PQC guidance starts with "deploy a discovery tool." Here's why that advice fails in banking environments—and what works instead.

The Banking Reality

In start-ups, you can scan first and ask questions later. In regulated financial services:

• Network scanning requires change management approval
• Findings require clear escalation paths
• Remediation requires budget allocation cycles
• Accountability requires documented ownership

Discovery without these foundations generates alarming reports that nobody is empowered to act upon.

This groundbreaking 4-part series introduces the "Post-Quantum Negligence" legal framework, analyzing how duty of care, foreseeability, and liability standards are evolving as quantum threats become quantifiable.

The Series

Key Concepts

Mosca's Theorem

Darren applies Mosca's Theorem—a framework for understanding when organisations must begin PQC migration based on: (1) how long data must remain secure, (2) how long migration will take, and (3) when quantum computers will become cryptographically relevant.

The Learned Hand Formula

The classic negligence test (B < P × L) asks whether the burden of precaution is less than the probability of harm multiplied by the magnitude of loss. As quantum timelines compress and regulatory expectations crystallise, the "burden" of PQC preparation becomes increasingly reasonable.

Connect with Darren Bender on LinkedIn for ongoing analysis of legal liability in the quantum era.

Comprehensive answers to the most common questions about post-quantum cryptography.

What is quantum-safe or Post-Quantum Cryptography?

Quantum-safe or post-quantum cryptography refers to new families of encryption and digital signature algorithms designed to remain secure even when attackers have access to large-scale quantum computers. NIST and national agencies are now standardising these algorithms.

What is meant by the term Q-Day?

Q-day is the future point when quantum computers become powerful enough to break widely used public-key cryptographic algorithms like RSA and ECC.

What does "HNDL" mean?

Harvest Now, Decrypt Later (HNDL) refers to a strategy where attackers steal and store encrypted data today, intending to decrypt it once quantum computers become capable.

Why does PQC matter to my business now?

Sensitive data stolen today can be stored and decrypted later. Regulators are signalling that organisations must start planning and migrating well before quantum computers are widely available.

What are regulators expecting?

Guidance now links quantum readiness to good cybersecurity risk management. Examples include NIS2, DORA for financial services, and international roadmaps encouraging phase-out of vulnerable cryptography by the early-to-mid 2030s.

What should boards and executives be asking?

• Where is cryptography currently used to protect sensitive data?
• How long does our sensitive data need to remain confidential?
• What is our roadmap for migrating to quantum-safe cryptography?
• How are our critical suppliers preparing for quantum risk?

The UK's National Cyber Security Centre (NCSC) has unveiled critical guidance outlining a comprehensive roadmap for organisations to migrate to post-quantum cryptography by 2035.

Three-Phase Migration Timeline

• By 2028: Organisations must identify vulnerable cryptographic services and develop migration plans
• 2028-2031: Execute high-priority upgrades
• By 2035: Complete full PQC implementation across all systems

Building UK PQC Capability

The NCSC has launched a pilot scheme running until March 2027 to assure consultancy firms offering PQC discovery, assessment, and planning services.

Key Resources:

• NCSC PQC Migration Timeline Guidance
• Official NCSC Announcement

European and UK organizations face mounting legal obligations to migrate to post-quantum cryptography as data protection regulators formalize quantum threats within existing compliance frameworks.

DORA and NIS2 Mandate Crypto-Agility

The EU's Digital Operational Resilience Act (DORA), effective January 2025, requires financial entities to develop formal cryptographic policies acknowledging quantum threats and implement "cryptographic agility mechanisms." The DORA RTS Recital 9 explicitly references "threats from quantum advancements" and Article 6 mandates cryptographic agility.

GDPR and State-of-the-Art Security Obligations

The ICO warns that organizations must achieve "crypto agility" by keeping encryption under regular review. Under GDPR Article 32, failure to address quantum risks could constitute non-compliance.

Key Resources:

• ICO Quantum Technologies Guidance
• EU PQC Coordinated Roadmap
• DORA RTS Section 4: Encryption and Cryptographic Controls (Articles 6-7)

The Financial Services Information Sharing and Analysis Center (FS-ISAC) has published a critical white paper urging synchronized global action on post-quantum cryptography migration.

Four-Phase Migration Framework

• Initiation: Securing executive buy-in and budget
• Discovery: Cryptographic asset inventory across all systems
• Deployment: Implementing PQC for high-risk systems by 2030
• Exit: Complete removal of quantum-vulnerable algorithms by 2035

Addressing "Crypto-Procrastination" Risk

The paper warns against underestimating migration complexity and treating quantum threats as distant concerns.

Key Resources:

• FS-ISAC White Paper Download
• FS-ISAC PQC Resources Hub

If you've attended a recent cybersecurity conference, you've probably heard something like this: "Step one—deploy a cryptographic discovery tool." It sounds sensible. It's also a recipe for chaos in most banks.

Here's the uncomfortable truth that tool vendors won't tell you: banking isn't a start-up. Your organisation operates within carefully constructed frameworks of policies, procedures, standards, and guidelines—and for very good reason.

Before any discovery tool touches your infrastructure, ask yourself: Who has authorised this? Which systems can it scan? Who will see the results? What happens when it finds something alarming in a production environment at 3am?

This is why we advocate for what we call PQC Pre-Discovery™—the essential groundwork before any scanning begins.

Pre-Discovery means proactively updating your cryptographic policies, standards, guidelines and procedures to address quantum risk. It means training the teams who'll interpret discovery outputs. It means establishing governance frameworks that ensure discoveries lead to decisions, not just dashboards.

Without this foundation, discovery becomes an expensive audit that generates alarming reports nobody is empowered to address.

Pre-Discovery isn't bureaucracy. It's how serious institutions prepare for serious change.

For the past quarter-century, cryptography has been the ultimate "commons" in enterprise IT. Like air conditioning or floor tiles, it simply existed—baked into products, included in subscriptions, rarely requiring its own budget line.

This comfortable arrangement is about to end. Post-quantum cryptography transitions will require visible, accountable expenditure. And here's where it gets interesting: how you account for that expenditure depends significantly on where you operate.

For US banks under GAAP:

Both cryptographic discovery and subsequent upgrades will likely flow through as expenses, hitting your P&L directly. No capitalisation to soften the blow across multiple years.

For European and international banks under IFRS:

You'll still expense discovery activities, but cryptographic upgrades may qualify as capital expenditure—particularly when framed as risk mitigation investments.

This distinction matters enormously for planning. European banks have potential flexibility to treat quantum-ready infrastructure as a strategic asset. US banks face more immediate earnings impact.

The regulatory direction is clear. DORA's Regulatory Technical Standard explicitly requires financial entities to address "threats from quantum advancements" with cryptoagility.

Start conversations with your CFO and CRO now. Map the accounting treatment. Build multi-year budget cases that reflect your jurisdiction's rules.

Quantum threats don't wait for budget cycles. Your planning shouldn't either.

Reference: DORA RTS Recital 9 (quantum threats) and Article 6 (cryptographic agility)

Let's play with an acronym.

In the cryptography world, PQC means "Post-Quantum Cryptography"—the new algorithms designed to resist attacks from future quantum computers. But here's the thing: those quantum computers can't yet break today's encryption. Which means everything we're doing right now isn't really "post" anything.

It's Pre Quantum Computing.

And if we're being honest about Pre Quantum Computing readiness, let's start with an uncomfortable question: have you actually finished the basics?

We still find TLS 1.0 and TLS 1.1 enabled on production banking systems—protocols deprecated years ago. Some organisations haven't even disabled SSL 3.0, which was broken in 2014. We encounter MD5 and SHA-1 still protecting data that really shouldn't be protected by algorithms with known collision vulnerabilities.

This isn't exotic. This is cryptographic housekeeping that authoritative guidance has recommended since at least 2021. Four years on, it should be done.

So before we discuss quantum-resistant algorithms and crypto-agility roadmaps, perhaps we need a more fundamental conversation:

Are you ready for Post-Quantum Cryptography? Or are you still not ready for Pre-Quantum Computing?

One comes before the other. And it's not the one most vendors want to sell you.

References:

• NCSC: Using TLS to protect data
• Mozilla: SSL Configuration Generator

Quantum computers pose an existential threat to the encryption protecting your organization's most sensitive data. Adversaries are already harvesting encrypted data today through "store now, decrypt later" attacks.

Why This Is a Board-Level Issue

Post-quantum cryptography migration is not an IT project—it's a multi-year strategic transformation requiring executive sponsorship, cross-functional governance, and significant capital allocation.

FAQ: Post-Quantum Cryptography for Executives

Q: When will quantum computers threaten current encryption?

Experts point to the 2030s for cryptographically relevant quantum computers. However, the "harvest now, decrypt later" threat is immediate.

Q: What should our organization do first?

Begin with a cryptographic inventory: identify where encryption exists across applications, databases, networks, and third-party systems.

Q: Is this just a CISO responsibility?

No. Successful PQC migration requires the CIO (infrastructure), CTO (applications), CFO (budget allocation), Chief Procurement Officer (vendor roadmaps), and General Counsel (regulatory compliance).

Key Resources:

• NIST Post-Quantum Cryptography Guide
• CSA Practitioner's Guide to PQC

Today, Europol's Quantum Safe Financial Forum (QSFF) published "Prioritising Post-Quantum Cryptography Migration Activities in Financial Services"—a practical methodology for financial institutions to assess migration priority based on Quantum Risk and Migration Time.

The document, developed by contributors from major financial institutions including Banco Santander, Bank of Ireland, Citi, National Bank of Canada, European Investment Bank, and TD Bank, provides exactly what many organisations have been seeking: a structured framework for answering "where do we start?"

The Core Framework

The QSFF methodology assesses each business use case across two dimensions:

Quantum Risk Score evaluates:

• Shelf life of protected data
• Exposure (how accessible data is to potential attackers)
• Severity of potential compromise

Migration Time Score evaluates:

• Solution availability
• Execution cost and complexity
• External dependencies

The combination produces a priority matrix helping organisations identify "low-hanging fruit" for immediate action versus use cases requiring long-term roadmap planning.

What Caught Our Attention

Three aspects of this publication particularly align with ProteQC's Pre-Discovery™ approach:

1. Business use cases first, not systems

The framework explicitly starts with "an inventory of all business use cases that rely on public key cryptography"—not a technical scan of systems. Understanding business context before technical discovery is precisely why we developed Pre-Discovery™.

2. The prioritisation process matters more than the scores

The document states: "The most valuable outcome of the prioritisation exercise is not the individual scores themselves, but the insights gained through the process." This reinforces our view that governance frameworks and stakeholder understanding must precede tool-driven discovery.

3. Cryptographic antipatterns as immediate "no-regret" actions

The guidance on eliminating antipatterns—hard-coded credentials, heterogeneous TLS configurations, manual certificate management—provides actions organisations can take today while awaiting broader PQC standardisation. This pragmatic approach to "no-regret" improvements aligns with our emphasis on cryptographic hygiene as part of readiness.

Practical Implications for Financial Services

For financial institutions subject to DORA Article 6.4 requirements for crypto-agility, this framework provides a defensible methodology for demonstrating structured progress toward quantum readiness.

The two worked examples—Point of Sale systems (high complexity, medium risk) and public websites (low complexity, medium risk)—illustrate how different use cases warrant different timelines and approaches. Notably, the guidance suggests that public-facing websites with hybrid PQC-TLS support represent an opportunity for "early adoption of quantum-safe cryptography" with minimal technical effort.

Industry Alignment

The contributor list includes recognised voices in financial services PQC thought leadership:

• Oscar Covers (Dutch Banking Association)
• Dr. Thibaud Ecarot (National Bank of Canada)
• Rebecca Gibergues (FS-ISAC)
• Jaime Gómez García (Banco Santander)
• Francis Gorman (Bank of Ireland, Host of The Entropy Podcast)
• Imran Khan (BMO)
• Ivan Makarov (TD Bank)
• Sarah McCarthy (Citi)
• Professor Michele Mosca (University of Waterloo)
• Iván Soto (Banco de España)
• Leila Taghizadeh (Allianz)
• Jelena Zelenovic (European Investment Bank)

The endorsement by institutions including Allianz, Euroclear, KBC, LGT, Mizuho, and PostFinance signals growing consensus that structured prioritisation—not reactive discovery—is the path forward.

Our View

We've long advocated that PQC readiness begins with understanding your organisation's risk landscape, updating governance frameworks, and training teams—before investing in discovery tools. Today's QSFF publication validates this approach at an industry level.

Financial institutions now have a practical, peer-developed framework for prioritisation. The question is no longer "should we act?" but "how do we apply this methodology to our specific context?"

That's precisely the work we help organisations accomplish.

Source: Europol QSFF: Prioritising Post-Quantum Cryptography Migration Activities in Financial Services (PDF, January 2026)

The G7 Cyber Expert Group (CEG)—co-chaired by the US Department of the Treasury and the Bank of England—has released a landmark coordinated roadmap for the transition to post-quantum cryptography across the global financial system.

This isn't another compliance checklist. It's a strategic signal that the cryptographic foundations of modern finance are approaching a definitive transition point.

Clear Timeline Targets

The roadmap establishes concrete planning horizons:

• 2030-2032: Critical systems should complete migration to limit downside risk
• 2035: Overall target for complete transition across governmental and private sector systems

These timelines reflect the reality of the "harvest now, decrypt later" threat. Data encrypted today using current algorithms is being intercepted and stored by adversaries—ready to be decrypted once cryptographically relevant quantum computers become available.

Six-Phase Migration Journey

The G7 CEG outlines a structured approach:

1. Awareness & Preparation: Establishing executive-level risk awareness
2. Discovery & Inventory: Comprehensive cryptographic asset mapping
3. Risk Assessment: Prioritising based on exposure and systemic importance
4. Planning & Design: Developing migration strategies
5. Implementation: Phased deployment with testing
6. Validation & Monitoring: Continuous improvement

Cryptographic Agility Emphasised

The roadmap emphasises building the capability to adapt quickly as new standards and threats emerge. This requires not just technical changes but governance structures that can support ongoing recalibration—precisely the Pre-Discovery™ work we advocate.

Vendor Dependencies Are Critical

Financial institutions depend heavily on technology vendors and service providers. The G7 CEG identifies limited transparency into vendor roadmaps—particularly for cloud and cryptographic services—as a potential bottleneck. Active management of these dependencies is essential for meeting proposed timelines.

Our View

The G7 CEG statement reinforces what many security leaders already understand: preparing for post-quantum cryptography is not optional, and the window for orderly transition is finite.

Organisations that have not yet begun a cryptographic inventory should treat this as a priority. Understanding where vulnerable algorithms exist across systems, hardware, firmware, and applications is the foundation for any migration programme.

The roadmap provides exactly the kind of authoritative guidance that boards and regulators will increasingly reference when evaluating cryptographic readiness. Organisations that align their programmes with G7 CEG recommendations will be better positioned to demonstrate reasonable care.

Source: G7 CEG Statement on Advancing a Coordinated Roadmap for the Transition to Post-Quantum Cryptography in the Financial Sector (GOV.UK, January 2026)

A Question We Keep Asking Ourselves

At ProteQC, we spend a lot of time thinking about one question: why is it so hard for banks to respond to cryptographic threats?

The quantum computing threat has been known for over a decade. The algorithms to fix it were finalised in 2024. Regulators are now demanding action. Yet most banks have barely started.

We know part of the answer. The late Professor Ross Anderson—founder of the field of security economics—showed that keeping security systems working over time is surprisingly expensive. His research explained why security updates happen slowly, even when everyone knows they're needed.

But recently, we've found what we think is an even more fundamental cause.

The Problem: Cryptography Has Been "Free"

Here's the uncomfortable truth: nobody has been charging for cryptography.

Think about that for a moment. Every time you log into your bank, encryption protects your password. Every time you transfer money, cryptographic signatures prove you authorised it. Every time the bank stores your data, encryption keeps it safe from thieves.

This protection has enormous value. Yet look at your bank statement. Do you see a line item for "encryption services"? Of course not.

Now look at the software that banks buy. Do vendors charge separately for the cryptographic components that make their systems secure? Almost never. Cryptography is just "included"—invisible, unpriced, and unaccounted for.

No Charges Means No Accounting

This matters because of how organisations work.

When no one charges for something, accountants have no reason to track it. There's no expense line to record, no asset to depreciate, no cost centre to manage.

Without accounting entries, finance teams never think about cryptography. It simply doesn't appear in their systems. They track server costs, software licences, and staff salaries. But cryptographic protection? It's invisible.

No Accounting Means No Budgets

And here's where things get really problematic.

Organisations set budgets based on what they track. If you've tracked server costs for years, you can predict next year's server costs. If you've tracked software maintenance fees, you can budget for them.

But if you've never tracked cryptography costs—because no one ever charged you for cryptography—how do you budget for upgrading it?

The answer, in most banks, is that you don't. Cryptographic maintenance has never had a budget. It's never had an owner. It's never had a maintenance plan.

When something has been "free" for thirty years, asking for millions to upgrade it feels outrageous. Budget committees ask reasonable questions: "We've never paid for this before. Why should we start now?"

Quantum Computing: The Forcing Function

This is why quantum computing matters so much—and not just because of the technical threat.

Yes, quantum computers will eventually break the cryptography that protects banking systems. That's a serious problem. But the bigger shift may be economic, not technical.

For the first time, cryptography is becoming a visible, urgent, budget-level concern.

Regulators are demanding action. The EU's DORA regulation requires banks to demonstrate "cryptographic agility"—the ability to change cryptographic systems when needed. The G7 Cyber Expert Group has set 2035 as the target date for completing the migration. Boards are asking questions.

This regulatory and governance pressure is acting as a "forcing function." It's making banks do something they should have done years ago: figure out where their cryptography is, who owns it, and how much it will cost to maintain.

What Will This Cost?

We'll publish detailed guidance soon on how banks should estimate and budget for post-quantum cryptography migration. For now, we want to share our preliminary view on the "shape" of these costs.

For banks that haven't yet made significant progress, we expect:

This is a significant investment. But it reflects a simple reality: thirty years of "free" cryptography has created a thirty-year maintenance backlog. Paying for that backlog over five years, while also preparing for quantum threats, requires real money.

The good news? This isn't permanent. Once the migration is complete and proper cryptographic governance is established, costs should return closer to normal—though hopefully with proper maintenance budgets in place to prevent the same problem recurring.

What Should You Do?

If you're responsible for preparing your organisation for quantum threats, here's our advice:

Start with governance, not tools. Before you buy discovery software or audit your systems, establish who owns cryptography in your organisation. Create cost centres. Set budgets. Make cryptography visible in your financial systems.

Expect the budget conversation to be difficult. You're asking for money for something that's been "free" for decades. That's a hard sell. Arm yourself with regulatory requirements, board-level risk language, and realistic cost estimates.

Think in terms of five years. This isn't a project with a six-month timeline. It's a multi-year transformation. Plan accordingly.

Watch for our upcoming guidance. We're preparing detailed advice on PQC budgeting and cost estimation. We'll help you build the business case you need.

The Elephant Is Finally Visible

For thirty years, cryptography has been the elephant in the room that nobody talked about—because nobody paid for it. That's about to change.

Quantum computing is forcing organisations to finally acknowledge the true value and cost of cryptographic protection. It's a painful adjustment. But it's also an opportunity to build the governance frameworks, accounting systems, and maintenance budgets that should have existed all along.

The elephant is finally visible. Now we need to figure out how to feed it.

Coming Soon: Budgeting for Post-Quantum Cryptography: A Practical Guide for Financial Institutions—detailed guidance on estimating PQC migration costs and building business cases for board approval.

References:

• Anderson, R. (2007). "The Initial Costs and Maintenance Costs of Protocols" - Security Protocols 2005, LNCS 4631
• Article 6.4, DORA Regulatory Technical Standard for ICT Risk Management
• G7 CEG Statement on PQC Migration Roadmap (January 2026)

Why This Directive Matters

On 7 January 2025, Daniel Hahiashvili, the Supervisor of Banks at the Bank of Israel, issued a directive to all banking corporations and licensed payment service providers on the subject of quantum computing preparedness. The document was addressed directly to the Chairman of the Board and CEO of each institution.

At first glance, this might seem like just another regulator acknowledging the quantum threat. Every major financial regulator has done so by now. What makes the Israeli directive distinctive—and worth studying carefully—is how it tells institutions to respond.

Rather than establishing broad capability requirements and leaving implementation timing to organisational discretion (the EU DORA approach), or setting coordinated but non-binding targets (the G7 CEG approach), the Bank of Israel mandated specific governance actions with explicit deadlines. This is a qualitatively different regulatory model, and financial institutions operating across multiple jurisdictions need to understand the implications.

What the Directive Requires

The directive is structured around three pillars, each with concrete mandates:

Pillar 1: Awareness and Continuous Monitoring

The directive requires institutions to establish mechanisms for ongoing awareness of quantum computing developments. Two requirements stand out. First, boards and senior management must be informed of quantum threats and must discuss organisational preparedness at minimum biennial intervals—not as a one-off briefing, but as a recurring governance obligation. Second, institutions must maintain continuous monitoring of developments in both quantum computing threats and defensive solutions including post-quantum cryptography and quantum key distribution, explicitly including engagement with relevant industry bodies and research institutions.

Pillar 2: Cryptographic Asset Mapping

The mapping requirements are notably comprehensive. Institutions must inventory encrypted data at rest, documenting encryption algorithm type and key length, information ownership, systems and applications involved, the duration for which data must remain protected (explicitly referencing the "harvest now, decrypt later" risk), and the sensitivity and criticality classification of the information.

Beyond data at rest, the directive extends to asymmetrically encrypted data in transit with external entities and—critically—to encrypted data held outside the organisation for any reason, including cloud environments, intentional transfers, backups, and even data exposed through past cyber incidents. This last category is particularly significant: it acknowledges that organisations must map exposure they may not directly control.

Pillar 3: Readiness and Skills Development

The third pillar addresses practical preparation for migration. It requires institutions to assess and plan for employee training, laboratory and testing environments for new cryptographic solutions, infrastructure compatibility assessment for post-quantum algorithms, transition planning that minimises operational disruption, policy and procedure updates for post-quantum compatibility, and contingency planning for cases where systems cannot be converted or the quantum threat materialises earlier than expected.

The directive requires an initial preparedness plan addressing all of these areas, discussed by the board and management, and submitted to the Head of the Technology, Innovation, and Cyber Division at the Banking Supervision Department within one year of the directive's date.

Three Models of PQC Regulation

The Bank of Israel directive is best understood in the context of a regulatory landscape that is converging on the same conclusion—banks must prepare for post-quantum cryptography—while diverging significantly on how prescriptive to be about it.

None of these models is inherently superior. Different regulatory environments have different institutional cultures, enforcement mechanisms, and supervisory capacities. What matters for practitioners is recognising that the direction of travel is toward increasing specificity—and the Israeli directive offers a preview of what more prescriptive regulatory expectations look like in practice.

What Multinational Institutions Should Take from This

For financial institutions operating across jurisdictions—which includes most of the organisations we work with—the Israeli directive has several practical implications.

The governance baseline is rising globally. Whether your primary regulator follows the DORA model, the G7 model, or the Israeli model, all three converge on the same foundational requirements: board-level awareness, cryptographic inventory, supply chain assessment, and documented preparation. Institutions that satisfy the Israeli directive's requirements will be well positioned for any of the three models.

Supply chain requirements deserve particular attention. The directive explicitly requires assessment of third-party quantum readiness and instructs institutions to "avoid reliance on suppliers and manufacturers that are not preparing for the quantum era or that may pose a technological risk." This language creates a contractual and procurement obligation that extends PQC preparation beyond the institution's own systems. We expect similar language to appear in other regulators' guidance over the coming year.

The mapping requirements set a high-water mark. Requiring inventory of encrypted data held outside the organisation—including data exposed through past cyber incidents—goes beyond what most cryptographic discovery frameworks currently address. This represents the most comprehensive mapping scope we have seen in any regulatory instrument to date.

Biennial board discussions as a minimum cadence. The requirement for recurring board discussions at minimum two-year intervals establishes governance continuity that one-off briefings cannot provide. For institutions that have treated PQC as a single awareness presentation, this signals an expectation of ongoing executive engagement.

The Pre-Discovery™ Alignment

Readers familiar with our methodology will recognise the directive's governance sequencing. The Bank of Israel effectively mandates what we call Pre-Discovery™: establishing awareness, mapping assets, assessing supply chains, updating policies, and building readiness before deploying technical migration solutions.

This is not coincidental. The governance challenges that the Israeli regulator is addressing—institutions that know they should prepare but haven't begun, boards that haven't been briefed, supply chains that haven't been assessed—are precisely the challenges we encounter in every engagement. The directive validates the principle that governance readiness must precede technical discovery, and provides regulatory authority for a sequencing that many institutions still resist.

One Year On

The twelve-month deadline for preparedness plan submissions has now passed. The Bank of Israel has not yet published aggregate findings on compliance, and we would expect supervisory follow-up to occur through bilateral examination rather than public reporting.

What we can observe is the broader trajectory. In the twelve months since the directive was issued, the G7 CEG published its coordinated roadmap, Europol's QSFF published its prioritisation framework, NIST finalised its post-quantum algorithm standards, and the regulatory consensus has hardened significantly. The Bank of Israel was ahead of the curve in January 2025. A year later, the curve has moved toward its position.

For institutions that have not yet begun structured preparation, the question is no longer whether prescriptive regulatory requirements will arrive in their jurisdiction—it is when.

Source: Bank of Israel: Banking System Preparedness for Cyber Risks Arising from Quantum Computing Capabilities (PDF, January 2025)

Related Reading:

• DORA Regulatory Technical Standard, Article 6: Encryption and Cryptographic Controls
• G7 CEG Statement on PQC Migration Roadmap (January 2026)
• Europol QSFF: Prioritising Post-Quantum Cryptography Migration Activities in Financial Services (January 2026)

In elite sport, you can always spot the people looking for a shortcut. There isn't one. You can't cram for an Olympic final, and you can't sprint your way through a multi-year cryptographic transformation either.

I'm not a cryptographer, and I don't have a PhD. What I do have is an Olympic gold medal, an MBA, a few decades in software and cybersecurity, and a front-row seat to how organizations handle hard, systemic change. ProteQC is where those threads come together.

Before quantum, my world was Agile.

At Rally Software, watching legends like Jean Tabaka and Ryan Martens, I saw what a truly Agile environment could feel like: work flowing faster, less waste, and, most importantly, work that actually mattered instead of feature sets nobody used. People lit back up. They remembered why they got into software in the first place, before requirements documents got bloated and stopped sounding like real customers at all.

Post-quantum cryptography (PQC) feels eerily similar.

The Righteousness Problem

In both Agile and PQC, there are purists.

In Agile, it sounded like: "If you're not doing framework X exactly like the book, you're not really Agile." In PQC, it's a new chorus: just adopt this algorithm, just buy this discovery tool, just follow this reference architecture, then you're "really" quantum-safe.

Right now, the space is full of strong opinions. Some are grounded in decades of research. Some are grounded in fear. Some are grounded in the very human observation that this decade will be disruptive and there is money to be made.

You see vendors promising one scanner that will "tell you everything that's vulnerable," commentators declaring that if you're not already migrated you're already behind, and people implying that if you don't understand the math you shouldn't be in the room.

There are brilliant PhDs who've carried this field for years and are finally seeing it commercialize. There are well-meaning sellers repeating what they've been told without understanding the nuance. And there are a lot of executives quietly thinking, "I hear the noise, but I still don't know what I'm supposed to actually do with my environment."

As someone who has lived through more than one transformation wave, I'm wary of certainty this early.

What We Actually Know

Here's what we're pretty sure of:

It's highly probable that quantum computing will break today's widely deployed public key cryptography over the coming years, putting at risk the digital certificates and key exchanges that underpin banking, payments, and identity. Long-lived financial data is vulnerable to "harvest now, decrypt later" attacks, where adversaries can capture encrypted traffic today to decrypt once they have the capability. Regulators in the UK, EU and US are already moving, and NIST and others have now named concrete PQC algorithms and deprecation timelines for old ones.

We also know there isn't a single algorithm, tool, or vendor that will "fix" this for you.

That's why, at ProteQC, we talk about cryptographic resilience rather than just the quantum threat: the ability of your organization to see its cryptography, govern it, and change it as threats and standards evolve.

If you grew up in software, this terrain is familiar. "If you can dream it, you can build it" has always cut both ways. Quantum just makes the upside and downside bigger.

Agile, Olympics, and PQC: The Same Pattern

When I look at PQC through Agile and Olympic lenses, three parallels jump out.

First, it's enterprise-wide. You're not just changing a library. Cryptography is woven through identity, payments, customer channels, APIs, mainframes, cloud workloads, archives, vendors and partners. Any meaningful change touches risk, compliance, architecture, engineering, procurement, and legal. That's a transformation, not a feature request.

Second, it depends on people and governance, not just tools.

Successful Agile transformations didn't start with a tool rollout. They started with a clear "why," leadership alignment, and changes to how teams planned, prioritized, and shipped. PQC is the same. Buying a cryptographic discovery tool before you have policy, ownership, and a view of what "good" looks like is like buying a fancy stopwatch before you've written a training plan.

That's why at ProteQC we start with governance, policy, and people — not scanning tools. We call this Pre-Discovery™: the work you do before you scan anything, so that when you do turn tools on, they're answering questions that actually matter to your business.

Third, it's a long game.

Olympic campaigns are built in years of cycles: plan, train, test, adjust. You build systems and habits that hold under pressure. Cryptographic transformation is the same. Regulators and standards bodies are pointing to a 2025—2035 horizon for PQC transition. This is not a three-week project; it's a decade of sequencing, learning, and iteration.

So when I hear, "We'll just wait until the tools mature and then migrate," I hear the athlete who wants to start serious training six months out. You might still show up to the race, but you miss the hard miles that actually make you resilient enough to finish it.

From Tools to Transformation

If you're a CRO, CISO, CIO or CEO, a sane PQC journey doesn't start with a shopping list; it starts with your people and posture. Who actually owns cryptography in your organization? How does it tie into your risk appetite, your regulatory obligations, your customer promises? Getting clear on those basics — and educating your leadership so they understand "harvest now, decrypt later" and the regulatory timelines — is the heart of Pre-Discovery™. It's the work of agreeing why this matters to you before you unleash any tools on your environment.

Only then does discovery make sense. At that point, you're not scanning for the sake of a heatmap; you're using cryptographic inventories and risk evaluations to answer specific questions: Where are our longest-lived secrets? Which systems fall under the tightest regulations? Which vendors sit in the most critical paths? Discovery becomes a way to prioritize and to inform design and change, not a science project.

And because this isn't a one-and-done exercise, you have to think in terms of continuous assurance. That means accepting that your cryptographic posture will change many times between now and 2035 — as standards shift, implementations mature, and your own business evolves — and building lightweight ways to check, prove, and adjust as you go. Tools matter in this story. They just aren't the story.

Why I'm Here, and Why ProteQC Exists

When I retired from swimming, I learned something important about dreams: the moment you touch the wall and see the world record next to your name, the dream is real and over at the same time. Twenty-five years ago, that chapter closed. Since then, I've chased different kinds of dreams in tech.

The pattern I look for now is simple: Does this matter? Does this help people do work that means something again?

PQC checks both boxes.

Companies are being forced, by physics and regulation, into a period of deep structural change. The cryptographic assumptions they've relied on for decades are expiring. That's painful. It's also an opportunity to clean up, modernize, and make security more honest, transparent, and human in the process.

ProteQC exists for the teams in the middle of that.

We're vendor-neutral, services-first, and focused on mid-market financial institutions because that's where the risk is real, the budgets are finite, and the "just call a global consultancy" play often doesn't fit. Our job is not to sell you a box. It's to help you build the cryptographic equivalent of a high-performance program: clear goals, a long-term plan, disciplined execution, and the confidence that when the next algorithm is deprecated, you're ready.

I don't have all the answers. No one does. What I do have is a track record of helping organizations navigate messy transformations, a team of deep cryptography and compliance experts, and an Olympic-sized bias toward doing the hard work instead of looking for shortcuts.

If Agile taught us anything, it's that you don't need perfect information to start. You need a clear why, a small first step, and partners you trust.

Quantum will be no different.