Crypto-Agility at Money20/20 USA 2026: What Banks and Payment Providers Should Know Before Las Vegas

Walk the floor at Money20/20 USA 2026 in Las Vegas (October 18-21) and nearly every demo, from instant payouts to new wallets, quietly depends on encryption that a large quantum computer could someday break. Crypto-agility is the ability to swap cryptographic algorithms, keys, and protocols across systems without rewriting applications or interrupting service, and it’s how you build quantum-safe payments on your own timeline. It’s also the piece that most payments roadmaps still leave out. Here’s what it means for you, where it hides in your stack, and what to ask before you fly home with a plan.

‍

What Is Crypto-Agility?

Crypto-agility is your ability to change your cryptography quickly, without breaking anything. Swap an algorithm, a key length, a protocol, or a certificate, and your apps keep running. That’s the whole idea.

It isn’t a product you can buy, and it isn’t a single algorithm. It’s an architecture choice. You build and manage your systems so that change feels routine instead of like a fire drill. Teams that make that choice can respond to a new threat in weeks. Teams that don’t can spend years on the same fix. That gap is exactly the quantum risk payment providers face today.

Crypto-Agility in Plain Terms

Picture a big office building with thousands of doors. One morning you learn that a new tool can pick every lock of the old type. Now you have to change every lock, and you can’t close the building to do it.

If each lock was installed by a different person, with different parts and no written record, you’re in for a rough year. If every lock is on one master list and uses a standard fit, you can swap them door by door while everyone keeps working. Crypto-agility is that second building.

It covers five things:

• Algorithms: the math that locks and unlocks your data.

• Key lengths: how long, and how strong, each key is.

• Protocols: the rules systems follow to talk securely, such as Transport Layer Security (TLS).

• Certificates: the digital IDs that prove who’s who.

• Key management: how you create, store, rotate, and retire keys.

For your board, the message is simple. A clear cryptographic inventory plus the ability to change turns a scary, open-ended project into a managed process with an owner, a schedule, and a budget.

Crypto-Agility vs. Post-Quantum Cryptography

Post-Quantum Cryptography (PQC) is the destination: a new set of algorithms built to stand up to quantum attacks. Crypto-agility is the road that gets you there. It also lets you turn around if you have to.

That last part matters more than it sounds. While the National Institute of Standards and Technology (NIST) was testing candidate algorithms, one promising entry was broken with an ordinary computer. It happened before the algorithm was ever made a standard. So, no algorithm comes with a lifetime guarantee, and if your systems can’t switch, you’re stuck with whatever you picked first.

Want the deeper background on the algorithms, including ML-KEM? Our post-quantum cryptography page covers it. For engineers, the takeaway is this: treat the algorithm as a setting, not as code.

‍

Why Crypto-Agility Belongs on Your Money20/20 USA 2026 Agenda

The event is where a lot of payments leaders lock in next year’s priorities. Quantum computing will reshape the trust layer behind every transaction, and the fix takes years. That puts crypto-agility, and a plan for Q-Day banking scenarios, on the 2027 list.

How Will Quantum Computing Affect Banking?

A large, error-corrected quantum computer running Shor’s algorithm could break Rivest-Shamir-Adleman (RSA) and Elliptic Curve Cryptography (ECC). Those two families of algorithms protect card authentication, payment Application Programming Interface (API) calls, online banking sessions, and interbank messaging. Break them, and an attacker can read protected data or forge digital signatures.

How close are we? Honestly, nobody knows. But the estimates keep shrinking. In 2025, researchers at Google Quantum AI published work that cut the estimated resources needed to break RSA-2048 to fewer than one million noisy qubits. Earlier estimates ran into tens of millions. The day this becomes real is often called Q-Day. Any Q-Day banking plan has to work without a firm date.

Here’s one technical detail worth remembering. A quantum computer doesn’t just speed up attacks on RSA and ECC. It turns a nearly impossible math problem into a solvable one. Bigger keys won’t save you. New algorithms will.

The business point: you don’t need the exact date. You only need to accept that your migration takes longer than your warning. That makes quantum security for financial services a planning job, not a prediction game.

The Harvest Now, Decrypt Later Problem for Financial Data

Here’s what makes this urgent today. Attackers don’t have to wait for a quantum computer to start stealing. In a Harvest Now, Decrypt Later (HNDL) attack, an adversary copies your encrypted data now and parks it. Years later, when quantum capability shows up, they unlock it. That’s the core of HNDL risk for financial services.

Financial data makes a great target because it stays valuable for so long. Think about:

• Account records and transaction histories

• Customer identity data

• Loan and mortgage files

• Anything you must keep for years to meet record-keeping rules

A card number might expire in three years. A customer’s identity doesn’t. A mortgage file can stay sensitive for 30 years.

So, ask yourself one question about each data set: how long does this need to stay secret? If the answer is longer than the time left before Q-Day, that data is already at risk. Leaders can treat it as a data-lifespan problem. Engineers should treat it as a key-exchange problem, because traffic in transit is what gets harvested. Either way, a cryptographic inventory shows you which data sets are exposed.

‍Why Payments Move Slowly and Why That Matters

Payments run on gear that lasts. Hardware Security Module (HSM) fleets stay in service for years. Point-of-sale terminals sit in shops for a decade or more. And every card, terminal, and HSM connects to partners with their own timelines.

Past cryptographic changes in financial services took many years to finish. Retiring older protocols and key sizes dragged on well after the first warnings. This time the change touches more systems at once.

Here’s the squeeze in one line: your migration window is shorter than your replacement cycle. You can’t wait for hardware to age out. You need a way to change cryptography on the systems you already own, and a plan for the ones you can’t change quickly. That’s the real quantum risk payment providers have to manage.

‍

Is PCI DSS Ready for Quantum? The Standards and Regulatory Picture

Not quite. The Payment Card Industry Data Security Standard (PCI DSS) doesn’t mention quantum computing by name, but the PCI DSS cryptography requirements already nudge you toward agility. Other rules add pressure from different directions.

NIST Post-Quantum Standards: ML-KEM, ML-DSA, and SLH-DSA

In August 2024, NIST finalized its first three post-quantum standards:

• Federal Information Processing Standard (FIPS) 203: the Module-Lattice-Based Key-Encapsulation Mechanism, or ML-KEM. It sets up shared secret keys between two parties, so it replaces the key-exchange job RSA and ECC do today.

• FIPS 204: the Module-Lattice-Based Digital Signature Algorithm, or ML-DSA. It’s the main pick for digital signatures.

• FIPS 205: the Stateless Hash-Based Digital Signature Algorithm, or SLH-DSA. It’s a backup signature method built on different math, which adds variety if the lattice approach ever runs into trouble.

NIST also published a draft planning document, NIST Internal Report (IR) 8547. It proposes deprecating RSA and ECC after 2030 and disallowing them after 2035. Treat those years as a planning signal, and check NIST’s latest publications before you put them in a board paper.

For engineers, these standards give you something solid to test against, including hybrid cryptography setups. For leaders, they mean “wait and see” has stopped being a safe answer. The target algorithms are known.

PCI DSS v4.0.1 Requirement 12.3.3

PCI DSS never uses the phrase “crypto-agility.” Requirement 12.3.3 gets close, though. Since its March 2025 effective date, it asks you to do three things:

1. Document and review the cipher suites and protocols you use at least once every 12 months.

2. Keep an eye on industry news about whether those suites and protocols are still strong.

3. Have a plan for the changes you expect.

Read that again. You must know what cryptography you run. You must watch for trouble. You must be ready to act. That’s a built-in call for a cryptographic inventory and for the ability to change.

If your cryptographic inventory is a spreadsheet someone updates once a year, you might pass the review and still be unprepared. A living inventory does better, and we’ll get to that below.

DORA, Federal Expectations, and Global Coordination

The European Union’s Digital Operational Resilience Act (DORA) has applied since January 2025. It sets information and communication technology risk rules for financial entities, including firm expectations around encryption and key management. If you’re a U.S. provider with European Union operations or clients, DORA probably touches you. Together with the PCI DSS cryptography requirements, it points at one habit: know what you run and be able to change it.

Other signals point the same way:

• The U.S. Government Accountability Office (GAO) has reported on federal quantum readiness and the hurdles agencies face.

• The Bank for International Settlements (BIS) has published work on making financial systems quantum-safe.

• The Accredited Standards Committee X9 (ASC X9) is working on guidance for the financial industry.

• If you serve federal agencies, the National Security Agency’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) sets its own timeline for national security systems.

See the pattern? Supervisors are heading toward one question for payment providers like you: do you know what cryptography you use, and can you change it? You’ll want a good answer ready.

From Money20/20 USA 2026 to Q-Day: A Timeline

• August 2024: NIST finalizes FIPS 203, 204, and 205.

• January 2025: DORA begins to apply.

• March 2025: PCI DSS Requirement 12.3.3 becomes mandatory.

• October 2026: Money20/20 USA in Las Vegas.

• After 2030: NIST proposes to deprecate RSA and ECC.

• After 2035: NIST proposes to disallow RSA and ECC.

• Q-Day: unknown. Treat the window as uncertain, and plan as if it could arrive before the NIST dates.

‍

Where Does Cryptography Live in a Payment Stack?

The honest answer is everywhere. It sits in cards, chips, servers, networks, apps, and archives, and most of it is RSA or ECC. That’s why post-quantum cryptography for payments starts with a map. This table shows the main places to look.

Let’s walk through the big ones.

Card Issuance, HSMs, and Key Management

HSMs create, store, and guard the keys behind card issuance and PIN handling. They often use RSA or ECC to wrap and swap keys, and many run for years on fixed firmware. Ask your HSM provider what the upgrade path looks like, and whether post-quantum algorithms can be added to units you already own.

Payment APIs, Open Banking, and TLS

Every API call between your app, a processor, and a partner rides on TLS. Today, that usually means RSA or ECC sets up the session. This is the prime target for HNDL, because the traffic crosses networks you don’t control. The good news is that TLS is also where hybrid key exchange is most mature, so it’s a natural place to start with hybrid cryptography.

Mobile Wallets, Tokenization, and Digital Identity

Wallets use device keys and signatures to prove a tap is real. Tokenization swaps card numbers for stand-ins, but the systems that issue and check those tokens still rely on public-key cryptography. Identity checks lean on certificates, too. Every link in that chain needs a plan for quantum-safe payments.

Interbank and Cross-Border Messaging

Messages that move money between institutions are signed and sent over secure channels. The trust chains here can be long, with many parties on different schedules. One slow link holds everyone back, which is why industry coordination matters so much in this corner of the stack, and why it belongs in any Q-Day banking plan.

Archived Transaction and Customer Data

Backups and archives can hold years of records. If they were encrypted or transferred with RSA or ECC, they’re prime targets for HNDL attacks. Rank them by how long they need to stay private and start with the files that must stay secret the longest.

Here’s the hard truth. Most organizations don’t have a full map of this cryptography. Some of it lives in old code. Some sits inside third-party tools. Some was set up by people who left years ago. That’s why discovery comes first. A cryptographic inventory shows you what you have, where it lives, and how exposed it is. Without one, you can’t rank, budget, or report. With one, you can act.

‍

What Does Crypto-Agility Look Like in Practice?

Crypto-agility in banking comes down to four building blocks: a living inventory, a layer that hides the algorithm from the application, a way to run old and new algorithms side by side, and strong keys. None of them are exotic. The trick is having all four working together.

A Living Cryptographic Inventory

A one-time spreadsheet goes stale fast. A living cryptographic inventory uses tools that scan code, networks, certificates, and key stores on a regular basis. It flags weak algorithms, expiring certificates, and new assets as they show up.

This ties straight back to PCI DSS Requirement 12.3.3. Instead of scrambling once a year, you’ve got current data every day, and your annual review becomes a report instead of a project.

Cryptographic Abstraction and Policy-Driven Control

In many systems, the algorithm is baked right into the code. To change it, you edit, test, and ship every application. That’s slow, and it’s risky.

A better design puts a layer between your apps and your cryptography. Your app asks for “protection” for a piece of data. A central policy engine decides which algorithm and key size to use. When the policy changes, the change flows out to every system that follows it.

The flow looks like this: applications → cryptographic abstraction layer → policy engine → algorithm options (classical, hybrid, or post-quantum), with strong keys feeding in from the key layer.

The payoff for the business: an algorithm change happens in one place, on one schedule, with one audit trail. That keeps your quantum-safe payments work on track.

Hybrid Cryptography as the Bridge

You don’t have to jump from old to new overnight. Hybrid cryptography pairs a classical algorithm with a post-quantum one. For example, you can run ML-KEM alongside an elliptic-curve key exchange. An attacker has to break both to get the key, so if either one holds, you’re covered.

That gives you two wins. You get protection against HNDL right away. And you stay safe if a new algorithm turns out to have a flaw nobody’s found yet.

There’s a cost, and engineers should test for it. Post-quantum keys and signatures are bigger than the ones you use now, which can add latency and eat more bandwidth. On a high-volume transaction path, small delays add up fast. Measure before you roll out.

RSA/ECC vs. Post-Quantum Cryptography for Payments

The business point: bigger keys are a manageable engineering cost. A broken trust layer isn’t.

High-Entropy Keys and Quantum Randomness

Even the strongest algorithm needs a strong key, and a strong key has to be unpredictable. If the random numbers that make your keys follow a hidden pattern, an attacker may be able to guess them. That would turn the best algorithm into a weak one.

Many systems use software random number generators. They’re fast, but they rely on math and on the quality of their starting values. Quantum Random Number Generation (QRNG) draws on the physics of quantum events to produce numbers that are truly unpredictable. That gives you a high-quality source for key generation, and it’s the core of quantum randomness security.

Think of it as a pair. PQC protects the design of the lock. Quantum randomness security protects the key you cut for it.

Questions to Ask at Money20/20 USA 2026

You’ll talk to a lot of people in Las Vegas. This vendor-neutral list helps you get real answers about post-quantum cryptography for payments from processors, HSM providers, wallet platforms, and fintech partners.

10 Questions to Ask at Money20/20 USA 2026

1. What is your post-quantum roadmap, and what are the dates?

2. Which NIST FIPS 203, 204, and 205 algorithms, including ML-KEM, do you support today?

3. Can you change algorithms through an update or a policy, or do I need to replace the product?

4. How do you handle hybrid cryptography during the transition?

5. How will you support our review of PCI DSS cryptography requirements, including Requirement 12.3.3?

6. How are algorithms set: in code or by central policy?

7. What’s the measured impact on transaction latency and bandwidth?

8. How are keys generated, and what’s the source of randomness?

9. How do you protect long-retention data from HNDL risk?

10. What will you need from us, and what will it cost to migrate?

Questions for Leaders to Ask Partners and Vendors

Your focus is risk, timing, and cost. Questions 1, 3, 4, 5, 9, and 10 are written for you. Listen for clear dates and plain answers. If a partner can’t say when they’ll support post-quantum standards, write that down as a risk. If they say, “we’ll replace the product,” ask who pays and how long it takes.

Also ask how their plan fits with yours. Your cryptography is only as strong as the weakest link in your chain of providers. That’s how payment providers really measure quantum risk.

Questions for Engineers to Ask About Architecture

Your focus is mechanics. Questions 2, 6, 7, and 8 are yours. Ask for test data, not slide decks. Which parameter sets are supported? Is hybrid cryptography available in the TLS stack? Can the HSM firmware be updated in the field? Where does the entropy come from?

The business point: clear technical answers now save you from expensive surprises later.

‍

How to Prepare for Q-Day: A 90-Day Post-Event Action Plan

You won’t finish a migration in 90 days, and nobody expects you to. But you can start. This plan gets you moving the week you get back from Las Vegas.

Days 1-30: Identify

Run cryptographic discovery across your payment systems to build your first cryptographic inventory. Find every place that uses RSA or ECC. List your certificates, key stores, HSMs, and third-party connections. Mark the data that has to stay private for many years.

Engineers, aim for a first map, not a perfect one. Leaders, name an owner and set a date for the first report.

Days 31-60: Prioritize and Plan

Rank each system on three things:

• Data lifespan: how long the data has to stay secret.

• Exposure: how easy it is for an attacker to reach or capture.

• Replacement difficulty: how hard and slow it is to change.

High lifespan, high exposure, and hard to change go to the top. Then line up your plan with your PCI DSS cryptography requirements and DORA duties and build the business case. Keep the numbers plain: systems at risk, cost to fix, and cost of delay.

Days 61-90: Protect and Govern

Pick one non-critical transaction path and try hybrid cryptography there. Measure latency, error rates, and bandwidth, then share what you learn.

At the same time, set up governance. Decide who owns cryptographic policy and how changes get approved. Add monitoring so you’ll know when something drifts. Good governance keeps the work moving after the pilot ends.

After 90 days, keep discovery running so you can adapt as standards evolve.

And about waiting: it feels cheaper today, but it isn’t. Start late and the work gets squeezed into a shorter window. You pay more for rush projects, you lose the chance to test slowly, and you take on more compliance risk, because regulators are already asking about readiness. Teams that start now will reach quantum-safe payments on their own schedule. Everyone else will make changes on someone else’s.

‍

How enQase Helps Banks and Payment Providers Become Crypto-Agile

enQase gives banks and payment networks one platform to see, fix, and prove the state of their cryptography, working alongside the systems they already run. It follows four stages: Identify, Protect, Govern, and Adapt.

Identify. Discover and map every cryptographic asset across your environment, including algorithms, keys, certificates, and dependencies. You get a living cryptographic inventory that supports your PCI DSS Requirement 12.3.3 review and shows your actual risk before you are asked to prove it. Learn more about quantum risk assessment.

Protect. Encrypt data in transit without new hardware dependencies, and upgrade key establishment and digital signatures to post-quantum standards such as ML-KEM and ML-DSA without replacing or re-certifying your existing HSMs. Hybrid cryptography keeps payment flows running during the transition, and quantum-generated randomness strengthens the keys behind them.

Govern. Enforce cryptographic policy centrally, with the audit trail regulators and boards will ask for.

Adapt. Manage cryptographic risk as standards evolve, so the next change is a configuration update, not another multiyear migration.

‍

Frequently Asked Questions (FAQ)

1. What is crypto-agility in banking?

Crypto-agility in banking is the ability to change encryption algorithms, keys, and protocols without rebuilding systems or stopping service. It lets a bank respond to new threats, like quantum computing, by updating cryptography through policy and tooling instead of long, risky, system-by-system rewrites.

2. How will quantum computing affect banking and payments?

A large quantum computer could break RSA and ECC, which protect card data, payment APIs, online banking sessions, and interbank messages. Attackers can also collect encrypted data today and unlock it later. Banks should plan for Q-Day banking risk now, since migrating payment systems takes years, not months.

3. When and where is Money20/20 USA 2026?

Money20/20 USA 2026 takes place October 18-21, 2026, in Las Vegas. It brings together banks, card issuers, acquirers, payment providers, and fintech teams. Check the official event website for the venue and schedule before you travel, since details can change.

4. Does PCI DSS require crypto-agility?

PCI DSS cryptography requirements don’t name crypto-agility. But PCI DSS v4.0.1 Requirement 12.3.3 asks you to document and review your cipher suites and protocols at least every 12 months, watch industry trends, and keep a plan for expected changes. In practice, that calls for a cryptographic inventory and the ability to adapt.

5. What is the difference between crypto-agility and post-quantum cryptography?

Post-quantum cryptography is a set of new algorithms built to resist quantum attacks. Crypto-agility is the ability to switch algorithms easily. You need both to reach quantum-safe payments. PQC is where you’re going, and crypto-agility gets you there today and lets you change again if an algorithm is ever weakened.

6. Will post-quantum cryptography slow down payment transactions?

Possibly, a little. Post-quantum keys and signatures are larger, which can add latency and use more bandwidth. The math itself is often fast. Test hybrid cryptography setups on your busiest transaction paths, measure real results, and tune before you roll out widely.

7. What is a Harvest Now, Decrypt Later attack?

In a Harvest Now, Decrypt Later attack, someone copies your encrypted data today and stores it until a quantum computer can unlock it. Long-lived records, like mortgage files and customer identity data, are the biggest targets. That makes HNDL risk a board-level topic for financial services.

8. What is a cryptographic inventory, and why does it matter?

A cryptographic inventory is a list of every algorithm, key, certificate, and protocol your systems use, and where each one lives. It matters because you can’t replace what you can’t find. It also supports your annual PCI DSS review and helps you rank quantum risk.

9. Which NIST standards should payment teams start testing?

Start with the three finalized in August 2024: FIPS 203 (ML-KEM) for key exchange, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA) as a backup signature method. Test them in hybrid mode on a non-critical path first and watch latency and message size.

10. How does enQase help banks and payment providers prepare?

enQase helps you identify where cryptography lives, protect payment flows with post-quantum and hybrid cryptography, govern policy centrally with a clear audit trail, and adapt as standards evolve, without ripping and replacing existing systems.

‍

Leave Las Vegas with a Crypto-Agility Plan

Every payments idea you hear about at Money20/20 USA 2026 will rely on cryptography. New wallets, new rails, and new APIs all need trust, and that trust rests on math that has to change. Crypto-agility is how you change it without stopping your business.

You don’t need to solve everything at once. Start with a cryptographic inventory, ask sharp questions, and pilot a hybrid path. Then keep going on your own schedule, before someone else sets it for you.

Ready to start? Visit enQase at Pod SU7 at Money20/20 USA, or book a crypto-agility readiness session to map your payment cryptography and begin transition planning.

‍