Explainer

Post-quantum: what actually changes for payments

Quantum computing has moved from a research topic to a planning item. In August 2024 NIST published its first post-quantum cryptography standards, including ML-KEM for establishing keys and ML-DSA for digital signatures. NIST's draft transition plan proposes deprecating today's widely used public-key algorithms, RSA and elliptic-curve cryptography, from 2030 and disallowing them from 2035.

What is at risk

A sufficiently capable quantum computer would break the public-key algorithms that set up secure connections and sign transactions. Symmetric encryption such as AES-256, which protects the data itself once keys are agreed, is considered far more resilient.

So the exposure in payments is less "all encryption fails" and more "the way we exchange keys and prove identity has to change". That touches TLS connections, API authentication, card and wallet provisioning, and code signing.

What does not change

  • Data that is decrypted in the wrong place is still exposed, quantum or not.
  • Weak access control is still weak access control.
  • Logs, backups and test copies holding plaintext are still a problem today.

The property that matters most

The lesson of every cryptographic transition is that it takes longer than planned. Systems that hard-wire one algorithm take years to change. Systems designed for crypto-agility can swap algorithms through policy, without redesigning the applications around them.

The goal is not to pick the algorithm that lasts forever. It is to build systems that can change algorithms without drama.

A useful first step: list where your organisation uses public-key cryptography today, and ask how long each would take to change.

More insights

News

Introducing Urrora

Why we are building a company around one idea: your customers should have to trust fewer systems with their data, not more.

  • Company
  • Our purpose
Point of view

Where your customers' data is exposed today

Encrypted in transit, encrypted at rest. Follow one piece of customer data through your stack and count how often it is neither.

  • Data exposure
  • Architecture
Point of view

The breach that starts somewhere boring

Serious incidents rarely begin with a movie-style hack. They begin with a debug log, a forgotten test database or an over-privileged service account.

  • Breaches
  • Containment

Contact

Get in touch.

Whether you’re exploring how to protect your clients’ data, interested in CCL, or want to work with us, we’d like to hear from you.

Email usinfo@urrora.com