Banking Law and Post-Quantum Cryptography Regulation in Spain

Post-quantum cryptography (PQC) concerns cryptographic systems designed to remain secure against attacks from sufficiently capable quantum computers. In Spanish banking, PQC is not currently a standalone field governed by a single “Post-Quantum Banking Act.” It is better understood through existing rules on ICT risk, cybersecurity, operational resilience, payment security, data protection, outsourcing, electronic identification and prudential governance.

For Spanish banks, the central legal question is:

How must a regulated financial institution prepare its cryptographic infrastructure for technological risks—including future quantum-capable attacks—while maintaining confidentiality, integrity, authentication, availability and operational continuity?

The principal framework comes from DORA, CRR/CRD, PSD2/payment-services rules, GDPR, NIS2-related cybersecurity law, eIDAS/electronic-signature rules and ECB/EBA supervisory expectations.

Because PQC-specific banking litigation is still extremely limited, the cases below are mainly authorities on cybersecurity, payment authentication, data security, technological neutrality, electronic identification and regulatory responsibility. They should not be misrepresented as cases directly deciding which post-quantum algorithm Spanish banks must use.

1. Why Quantum Computing Matters to Banks

Modern banking relies heavily on cryptography.

It protects:

• online banking;
• payment authentication;
• card infrastructure;
• interbank communications;
• APIs;
• customer databases;
• digital signatures;
• TLS connections;
• mobile applications;
• cloud services;
• identity systems.

Many existing systems depend on public-key cryptography.

A sufficiently powerful future quantum computer could threaten some widely used public-key cryptographic methods.

2. The Main Quantum Threat

A major concern is Shor's algorithm, which theoretically enables sufficiently capable quantum computers to solve mathematical problems underlying important public-key systems much more efficiently than conventional computers.

This creates concern for technologies based on:

• RSA;
• elliptic-curve cryptography;
• related public-key schemes.

Symmetric cryptography is affected differently; the security implications are not identical.

3. “Harvest Now, Decrypt Later”

Banks must also consider a long-term confidentiality problem commonly described as:

Harvest Now, Decrypt Later

An attacker may:

1. intercept encrypted information today;
2. store it;
3. wait for sufficiently capable quantum technology;
4. attempt to decrypt it later.

This matters particularly for information requiring long confidentiality periods.

For example:

Bank data in 2026      ↓ Encrypted using current cryptography      ↓ Attacker copies encrypted data      ↓ Stores it for years      ↓ Future cryptographic capability      ↓ Potential confidentiality problem

Therefore, migration planning can become relevant before a cryptographically relevant quantum computer actually exists.

4. Is PQC Mandatory for Spanish Banks?

There is no simple Spanish banking rule stating:

“Every Spanish bank must use Algorithm X for all systems from Date Y.”

The legal framework is largely risk-based and technology-neutral.

Banks instead face broader duties concerning:

• ICT risk;
• security;
• operational resilience;
• data protection;
• authentication;
• business continuity;
• third-party risk.

As quantum risk becomes sufficiently material and technically actionable, these existing obligations can support expectations for cryptographic migration.

5. DORA

The most important modern framework is:

Regulation (EU) 2022/2554

the Digital Operational Resilience Act — DORA.

DORA applies directly across the EU and has applied since 17 January 2025.

It covers many financial entities, including credit institutions.

Its core areas include:

• ICT risk management;
• ICT incident management and reporting;
• resilience testing;
• ICT third-party risk;
• information sharing;
• oversight of critical ICT third-party providers.

PQC migration fits naturally within this operational-resilience framework.

6. DORA and Cryptographic Risk

DORA does not create a bank-specific list saying:

RSA prohibited; PQC algorithm required.

Instead, a bank must maintain an ICT risk-management framework proportionate to its risks.

Cryptographic weaknesses can become relevant because compromised encryption could affect:

• confidentiality;
• integrity;
• authentication;
• communications;
• transaction security.

Therefore, quantum risk can be treated as a forward-looking ICT risk.

7. Crypto-Agility

One of the most important practical concepts is:

Cryptographic agility

This means designing systems so cryptographic components can be replaced or upgraded without rebuilding the entire banking infrastructure.

A bank with crypto-agility can move:

current cryptography → hybrid cryptography → PQC

more easily than a bank with hard-coded legacy algorithms.

From a regulatory perspective, crypto-agility can support operational resilience and technology-risk management.

8. Cryptographic Inventory

A bank cannot migrate effectively if it does not know where cryptography is used.

A migration programme therefore normally starts by identifying:

• algorithms;
• certificates;
• keys;
• protocols;
• applications;
• hardware security modules;
• APIs;
• databases;
• cloud services;
• third-party dependencies.

This can be called a cryptographic inventory.

9. Why Inventory Matters Legally

Suppose a Spanish bank uses an outdated cryptographic method in 2,000 systems but management knows about only 1,500.

The remaining systems create unmanaged ICT risk.

That can become a governance problem under regulatory frameworks requiring institutions to:

• identify assets;
• assess vulnerabilities;
• manage ICT risks;
• maintain controls.

Thus PQC readiness begins with governance, not merely algorithm selection.

10. CRR and CRD

Spanish banks are also subject to the EU prudential framework established through the:

Capital Requirements Regulation — CRR

and

Capital Requirements Directive — CRD.

Operational and ICT risks form part of prudential governance.

A serious cryptographic weakness could potentially produce:

• operational losses;
• fraud;
• service interruption;
• data breaches;
• legal liability.

Consequently, cybersecurity can become a prudential issue.

11. Law 10/2014

Spain's:

Law 10/2014

on the organisation, supervision and solvency of credit institutions forms part of the national banking framework.

Spanish institutions must maintain appropriate:

• governance;
• internal controls;
• risk management.

Cryptographic transition should therefore be viewed as part of the institution's broader technology-risk governance rather than as an isolated IT project.

12. ECB Supervision

Significant Spanish banks are directly supervised by the European Central Bank within the Single Supervisory Mechanism.

Less significant institutions remain principally under national supervision within the SSM framework.

Cybersecurity and operational resilience can be examined through:

• governance assessment;
• operational-risk management;
• SREP;
• outsourcing supervision;
• ICT risk.

Quantum-related cryptographic risk could become relevant where sufficiently material.

13. PSD2 and Payment Security

Payment systems require particularly strong security.

The relevant framework includes:

Directive (EU) 2015/2366 — PSD2

implemented in Spain principally through:

Royal Decree-Law 19/2018.

Payment services rely heavily on:

• authentication;
• confidentiality;
• transaction integrity;
• secure communication.

Weak cryptography could undermine these functions.

14. Strong Customer Authentication

PSD2 introduced extensive requirements concerning:

Strong Customer Authentication — SCA

Authentication generally relies on independent elements from categories such as:

• knowledge;
• possession;
• inherence.

Cryptography supports the secure operation of many authentication mechanisms.

If underlying cryptography becomes vulnerable, authentication design may also require upgrading.

15. GDPR

Banks hold extremely sensitive personal information.

The:

General Data Protection Regulation

Regulation (EU) 2016/679

therefore plays a major role.

Article 32 GDPR

requires controllers and processors to implement appropriate technical and organisational measures taking into account factors including:

• state of the art;
• implementation costs;
• nature and scope of processing;
• risks to individuals.

Encryption is expressly recognised as one possible security measure.

16. “State of the Art”

This concept is highly relevant to PQC.

A bank cannot necessarily defend insecure technology forever by saying:

“This encryption used to be industry standard.”

Security measures need to remain appropriate to:

• current risks;
• technological development;
• sensitivity of information.

However, “state of the art” does not mean that every experimental technology must immediately be deployed.

The appropriate response remains risk-based.

17. Quantum Risk and GDPR

Consider customer records that must remain confidential for decades.

The bank should consider:

How long must the information remain confidential?

versus:

How long will the current cryptography remain sufficiently secure?

If the required confidentiality period exceeds the realistic security lifetime of the cryptographic method, migration risk becomes increasingly important.

18. Data Protection by Design

Article 25 GDPR

establishes data-protection-by-design and by-default requirements.

For new banking platforms, this can encourage architecture capable of adapting to future security risks.

For example:

New banking platform        ↓ Modular cryptographic layer        ↓ Algorithms replaceable        ↓ Crypto-agility        ↓ Lower migration risk

Building replaceability into systems can be much easier than replacing embedded cryptography decades later.

19. NIS2

The broader EU cybersecurity framework also includes:

Directive (EU) 2022/2555 — NIS2

NIS2 strengthens cybersecurity obligations across important sectors.

For financial entities covered by DORA, the relationship between sector-specific DORA requirements and horizontal cybersecurity legislation must be carefully distinguished.

DORA functions as the specialised financial-sector operational-resilience framework.

20. eIDAS and Digital Signatures

Banks rely extensively on:

• electronic signatures;
• electronic seals;
• certificates;
• trust services;
• digital identity.

The EU's eIDAS framework, including its later evolution toward the European Digital Identity framework, is therefore relevant.

Quantum risk matters because some digital-signature systems depend on public-key cryptography that could eventually require replacement.

21. Long-Term Digital Signatures

Consider a digitally signed banking document intended to remain legally verifiable for 25 years.

If its signature algorithm later becomes cryptographically weak, questions can arise concerning long-term verification.

Therefore, banks may need mechanisms such as:

• renewed signatures;
• trusted timestamps;
• archival validation;
• algorithm migration.

PQC migration is therefore not only about encrypted communications.

It also affects long-term authenticity.

22. NIST Post-Quantum Standards

Although NIST is a United States standards body rather than a Spanish regulator, its PQC standardisation programme is globally influential.

In 2024, NIST finalised its first major PQC standards, including standards based on:

• ML-KEM for key establishment;
• ML-DSA for digital signatures;
• SLH-DSA for digital signatures.

These standards are technologically important to European financial institutions.

However:

Publication by NIST does not automatically make a particular algorithm legally mandatory for every Spanish bank.

EU and Spanish regulatory requirements must still be considered.

23. Hybrid Cryptography

During migration, banks may use hybrid approaches combining:

• conventional cryptography;
• post-quantum cryptography.

The objective is to avoid relying entirely on an immature migration path while gaining protection from new algorithm families.

But hybrid systems can also create:

• implementation complexity;
• interoperability problems;
• performance costs;
• configuration risks.

Regulators therefore care about safe implementation, not merely the presence of the word “quantum.”

24. Third-Party Providers

Banks rarely control their entire technology stack.

Dependencies can include:

• cloud providers;
• payment processors;
• HSM vendors;
• certificate authorities;
• telecommunications providers;
• software vendors;
• API platforms.

Therefore:

Bank PQC readiness      ≠ Bank software alone

The entire critical technology ecosystem may need to be assessed.

25. DORA Third-Party Risk

DORA is especially important here.

Financial institutions must manage ICT third-party risks through measures including appropriate:

• due diligence;
• contractual arrangements;
• monitoring;
• concentration-risk assessment;
• exit strategies.

A bank cannot simply say:

“Our cloud provider handles cryptography, therefore quantum risk is not our problem.”

Outsourcing technology does not automatically outsource regulatory responsibility.

26. Cloud Migration Example

Suppose a Spanish bank stores encrypted customer archives with a cloud provider.

The bank discovers that:

• archives must remain confidential for 20 years;
• current encryption relies on vulnerable-to-future-quantum public-key mechanisms for key exchange;
• vendor PQC support will not arrive for several years.

The bank should assess:

1. confidentiality period;
2. threat horizon;
3. data sensitivity;
4. vendor roadmap;
5. migration options;
6. contractual rights;
7. alternative providers.

This is a classic ICT third-party risk-management problem.

27. Incident Reporting

If cryptographic compromise produces a major ICT incident, DORA's incident-management and reporting framework may become relevant.

A bank therefore needs capabilities to:

• detect incidents;
• classify them;
• contain them;
• recover;
• document them;
• report qualifying incidents.

Quantum attacks would not exist outside ordinary incident law merely because the attack technique was technologically novel.

28. Algorithm Failure and Liability

Imagine that an algorithm previously regarded as secure becomes practically breakable.

A bank's liability would not automatically arise merely because cryptographic science advanced.

The legal questions would include:

• When was the vulnerability known?
• Was exploitation realistically possible?
• What did regulators recommend?
• What did comparable institutions do?
• Did the bank assess the risk?
• Was migration technically feasible?
• Did management delay without justification?

Thus the central issue would often be reasonable risk management, not hindsight.

29. Case Law — Deutsche Wohnen

CJEU, Case C-807/21

Deutsche Wohnen SE

The case concerned GDPR administrative fines and the conditions for imposing liability on a legal person.

The Court clarified important aspects of corporate responsibility under the GDPR.

PQC relevance

If weak cryptographic governance contributes to a personal-data security violation, GDPR enforcement principles become relevant.

The case does not establish any PQC algorithm requirement.

30. Case Law — VB v Natsionalna agentsia za prihodite

CJEU, Case C-340/21

This important cybersecurity/data-protection case arose after a cyberattack on the Bulgarian revenue authority.

The CJEU addressed issues including:

• security measures under GDPR;
• cyberattacks by third parties;
• burden of proof;
• compensation.

A third-party cyberattack does not automatically establish that security measures were inadequate.

But the controller's measures must still satisfy GDPR requirements.

PQC significance

This is highly relevant conceptually:

A future quantum attack would not automatically prove bank negligence, but the bank's security measures would still be assessed for legal adequacy.

31. Case Law — Österreichische Post

CJEU, Case C-300/21

UI v Österreichische Post AG

The Court examined compensation under Article 82 GDPR.

It held that infringement of GDPR alone is not sufficient for compensation; there must be:

• infringement;
• damage;
• causal link.

Banking relevance

If cryptographic failure causes a banking data breach, compensation claims still require the applicable legal elements.

A technical vulnerability alone does not automatically establish compensable damage.

32. Case Law — Scalable Capital

CJEU, Joined Cases C-182/22 and C-189/22

Scalable Capital

These cases concerned compensation following misuse of personal data.

They further developed the interpretation of GDPR compensation.

Relevance to banking

Scalable Capital operates in the financial-services environment, making the cases especially useful when considering customer claims following financial-data security incidents.

Again, they do not establish PQC technical standards.

33. Case Law — DenizBank

CJEU, Case C-287/19

DenizBank AG v Verein für Konsumenteninformation

The case concerned payment services and contactless functionality.

It examined issues involving payment instruments and PSD2 rules.

PQC relevance

The case demonstrates that technological innovations in payments remain subject to existing payment-services law.

Similarly:

Introducing quantum-safe payment technology will not remove PSD2/payment-law obligations.

34. Case Law — Bundesverband der Verbraucherzentralen v Deutsche Apotheker- und Ärztebank

CJEU, Case C-616/11

This payment-services litigation addressed interpretation of EU payment rules.

Its broader relevance is that technological payment arrangements are interpreted within mandatory EU payment-law protections.

For PQC migration, cryptographic changes cannot be implemented in ways that undermine mandatory customer protections.

35. Case Law — Schrems II

CJEU, Case C-311/18

Data Protection Commissioner v Facebook Ireland and Maximillian Schrems

The Court invalidated the EU-US Privacy Shield and addressed safeguards surrounding international data transfers.

PQC significance

The case demonstrates the importance of evaluating the actual level of protection surrounding data rather than relying only on formal contractual structures.

Spanish banks using global cloud and technology providers must therefore consider both:

• legal safeguards;
• technical safeguards.

Strong encryption can be one important technical measure.

36. Case Law — La Quadrature du Net

CJEU, Joined Cases C-511/18, C-512/18 and C-520/18

These cases concerned electronic communications, data retention and fundamental rights.

The Court examined the importance of safeguards protecting confidential information.

PQC relevance

Although not banking cases, they reinforce the broader EU legal importance of:

• confidentiality;
• security;
• proportionality;
• protection of communications.

These principles provide constitutional context for strong cryptographic protection.

37. Case Law — Digital Rights Ireland

CJEU, Joined Cases C-293/12 and C-594/12

The Court invalidated the Data Retention Directive because of fundamental-rights concerns.

Banking relevance

It demonstrates the high importance EU law attaches to protecting large collections of sensitive personal information.

Banking datasets can be exceptionally revealing.

Cryptographic security therefore contributes to protection of rights under:

• Article 7 EU Charter;
• Article 8 EU Charter.

38. Case Law — Landeskreditbank v ECB

General Court T-122/15

CJEU C-450/17 P

This case concerned the SSM's supervisory structure.

It is not a cybersecurity case.

Its relevance is institutional: significant Spanish banks operate within an integrated ECB-led prudential-supervision framework.

Consequently, major ICT and cryptographic risks can become supervisory issues at European rather than merely national level.

39. Why There Are Few Direct PQC Banking Cases

Post-quantum cryptography is still an emerging regulatory field.

Consequently, there is currently no mature body of Spanish jurisprudence saying:

“Bank X violated Spanish banking law because it failed to deploy ML-KEM.”

Current case law instead provides general legal principles concerning:

• cybersecurity;
• reasonable security measures;
• payment security;
• data breaches;
• liability;
• regulatory responsibility.

Future PQC litigation will likely apply these established principles to new technology.

40. Case-Law Map

These are analogical or framework authorities, not direct judicial mandates for specific PQC algorithms.

41. Suggested PQC Governance Model

For a Spanish bank, the regulatory logic can be represented as:

Quantum Threat Assessment          │          ▼ Cryptographic Inventory          │          ▼ Classify Critical Systems          │          ├── Payments          ├── Customer Data          ├── Digital Signatures          ├── APIs          ├── Interbank Systems          └── Cloud Infrastructure          │          ▼ Migration Risk Assessment          │          ▼ Crypto-Agile Architecture          │          ▼ Hybrid / PQC Transition          │          ▼ Testing + Monitoring          │          ▼ DORA / GDPR / Prudential Governance

42. Migration Priorities

A bank would generally need to prioritise systems according to risk rather than replace everything simultaneously.

A sensible risk hierarchy considers:

Data sensitivity

How damaging would disclosure be?

Confidentiality lifetime

How long must the data remain secret?

System criticality

Would failure disrupt essential banking services?

Migration difficulty

How long will replacement take?

Third-party dependency

Does the bank control the technology?

This produces a defensible risk-based migration strategy.

43. Board Responsibility

PQC cannot remain solely an engineering issue.

DORA places strong emphasis on the financial entity's management body's responsibility for the ICT risk-management framework.

For material cryptographic transition, senior management should therefore understand:

• quantum-risk exposure;
• critical cryptographic dependencies;
• investment requirements;
• third-party dependencies;
• migration timelines.

The board does not need to become a cryptography laboratory.

But it must exercise appropriate governance over material ICT risks.

44. Legacy Systems

Legacy infrastructure may be the most difficult problem.

Banks often operate systems that are:

• decades old;
• difficult to modify;
• connected to critical services;
• dependent on proprietary vendors.

A bank cannot assume that upgrading the mobile app makes the entire organisation quantum-ready.

Cryptographic dependencies can exist deep within:

• mainframes;
• payment switches;
• certificate systems;
• backup archives;
• hardware devices.

45. Interoperability

Banks communicate with:

• other banks;
• central banks;
• payment networks;
• card networks;
• fintechs;
• public authorities.

Therefore, PQC migration cannot always occur independently.

If Bank A adopts a new protocol that Bank B cannot understand, payments may fail.

Migration therefore requires:

security + standardisation + interoperability.

46. Operational Risk During Migration

Ironically, migrating to stronger cryptography can itself create risk.

Possible failures include:

• broken certificates;
• unavailable applications;
• incompatible APIs;
• signature-validation failures;
• increased latency;
• incorrect key management.

DORA therefore supports controlled migration involving:

• testing;
• change management;
• fallback mechanisms;
• business continuity.

47. PQC and Banking Supervision

The regulatory chain is:

Quantum Computing Development          ↓ Cryptographic Vulnerability          ↓ ICT / Cyber Risk          ↓ Payments + Data + Operations          ↓ Financial Loss / Service Failure          ↓ Operational & Prudential Risk          ↓ DORA + CRR/CRD + GDPR          ↓ ECB / Banco de España / Other Competent Authorities

This is how post-quantum cryptography becomes a banking-law issue even without a dedicated Spanish PQC statute.

48. Main Legal Principles

Several principles are particularly important.

First, technology neutrality. Spanish/EU banking law generally regulates required outcomes—security, resilience and risk management—rather than prescribing one permanent cryptographic algorithm.

Second, proportionality. Migration decisions should reflect actual risk, system importance and technological maturity.

Third, state of the art. Under GDPR and cybersecurity frameworks, banks cannot indefinitely rely on obsolete protections.

Fourth, crypto-agility. The ability to replace cryptography can itself be an important component of resilience.

Fifth, third-party accountability. Outsourcing cryptographic infrastructure does not automatically remove the bank's regulatory responsibilities.

Sixth, long-term confidentiality. Banks must consider whether today's encrypted information may remain sensitive when future decryption technology becomes available.

Seventh, evidence and governance. Banks should be capable of demonstrating why their cryptographic strategy is appropriate.

Conclusion

Post-quantum cryptography regulation in Spanish banking is currently best understood as an emerging application of existing cybersecurity and operational-resilience law rather than a separate statutory regime.

The principal legal foundations are DORA, GDPR Articles 25 and 32, CRR/CRD, Law 10/2014, PSD2 and Royal Decree-Law 19/2018, together with electronic-identification, cybersecurity and supervisory frameworks.

Spanish banks are not simply required to install one legally prescribed “quantum-safe” algorithm. The more important regulatory duties are to identify cryptographic dependencies, assess quantum-related risks, protect long-lived sensitive data, maintain crypto-agility, manage third-party providers, test migration carefully and integrate cryptographic risk into ICT and prudential governance.

The strongest existing case-law analogies include VB (C-340/21) on cybersecurity measures after an external attack, Deutsche Wohnen (C-807/21) on corporate GDPR responsibility, Österreichische Post (C-300/21) and Scalable Capital (C-182/22 and C-189/22) on data-related compensation, DenizBank (C-287/19) on payment technology, and Schrems II (C-311/18) on effective data safeguards.

The future legal question is therefore unlikely to be simply “Did the bank use post-quantum cryptography?” It will more likely be:

Given the state of technology, sensitivity and lifetime of the data, regulatory guidance, available standards and foreseeable risks at the relevant time, did the Spanish bank take appropriate and proportionate measures to manage its cryptographic risk?