Navigate the Post-Quantum 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

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