Why We Adopted Post-Quantum Cryptography a Decade Before Quantum Computers Arrive

*This is the English version of a previously published article.

Hello, Toss Tech readers. I'm Tae-ho Ha, Head of Technology at Toss Payments.

Ever since we started the Legacy Overhaul Series, one question has followed us everywhere:

"What was the biggest challenge in overhauling a 20-year-old legacy system?"

Most people expect a story about some deep technical problem.

And yes, there were plenty of tough moments along the way. But the engineers brought real depth and commitment to every challenge, and that's what made the impossible possible.

The real challenge, though, was something else: raising our security standards while keeping tens of thousands of merchants on board every step of the way.

Today, I'd like to share our years-long journey of updating the security protocol, and where it ultimately led us: the adoption of Post-Quantum Cryptography.

Breaking Old Habits

When you've been running a mission-critical payment service for a long time, an unspoken rule tends to take hold across the team:

"If it ain't broke, don't fix it. We can't afford downtime."

It's a conservative principle built to ensure stability. But it doesn't apply the same to everything. Small, reversible changes are implemented all the time. But when a change is far-reaching and hard to undo, a different instinct kicks in: "Do we really need to touch this right now?"

In fact, security protocols are where that instinct hits strongest. Upgrading the TLS version, removing weak cipher suites, introducing new encryption schemes are all obviously the right calls. But touch any of it, and tens of thousands of merchants are directly affected. And when something goes wrong, troubleshooting is never straightforward. This is exactly where the reluctance comes from.

Here's an example to give you a sense of what we're up against. Toss Payments still works with merchants who have been integrated with our PG system for decades. The older the integration, the more likely their server stack is running on outdated technology. Web browsers silently update themselves and stay current with the latest security standards, but the clients calling our API are mostly server-side programs. Applying modern security policies to software running on aging infrastructure is a lot harder than it sounds.

And getting the word out is its own challenge. Security isn't most developers' strong suit, and even when we provided well-written technical documents, it often took merchants a long time to fully understand what was being asked of them and act on it. Many of our merchants are small businesses run by a single owner with no dedicated dev team, and asking them to respond to a security upgrade request filled with technical jargon is genuinely a big ask.

A PG system is connected to tens of thousands of merchants through SDKs and API integrations. Every touchpoint, every API call, every payment window, every server communication, represents a security boundary. No matter how advanced your security stack is, if even a handful of merchants are still running on legacy environments, those connections are only half-protected.

That's why improving our security protocols was never something Toss Payments could solve on its own. It's a burden for us and for our merchants alike, which makes it all too easy to keep putting it off.

Why We Had to Change Anyway

But security is one area where "it's fine for now, so it's fine" just doesn't hold up. And right now, we're at a point where the very foundations of encryption we've taken for granted are starting to crack.

And this is where quantum computers come in.

You've probably come across the term in the news at some point. Quantum computers work on fundamentally different computational logic than the computers we use today. A regular computer processes combinations of 0s and 1s sequentially, one at a time. A quantum computer, by contrast, uses the principles of quantum mechanics to explore many possibilities simultaneously. Problems that would take a conventional computer tens of thousands of years to solve are expected to be crackable by a quantum computer in a matter of hours.

That kind of computational power poses a fundamental threat to the encryption systems that we rely on today.

Why Today's Encryption Can Be Broken

The encryption we use every day, in banking apps, payment windows, and HTTPs, mostly runs on public-key algorithms like RSA and ECDSA. The reason these algorithms are considered secure is actually pretty simple. They rely on one core assumption: factoring a very large number, or working backwards to find a specific value on an elliptic curve, is computationally infeasible for a conventional computer. The math has an answer, but it would take modern computers an extraordinarily long time to find it. So we've treated them as "practically secure."

However, the problem is that algorithms capable of solving these exact problems on a quantum computer have already been mathematically proven to exist. The moment a sufficiently powerful quantum computer is built, RSA and ECDSA, locks that once required an astronomical amount of time to crack, become locks that can be opened with ease. This isn't just a shift in the technology landscape. It's an event that shakes the very foundation of digital security built up over the past several decades.

Q-Day and "Harvest Now, Decrypt Later"

IBM, Google, IonQ, and other major players are actively working toward practical quantum computers, with 2030 as a key target. Security experts refer to the moment when today's encryption breaks down as "Q-Day."

It might feel like a distant future, but the threat has already begun. In fact, the most well-known attack scenario is called "Harvest Now, Decrypt Later."

[Now] A hacker collects encrypted payment data
			↓ (Can't decrypt it yet, but saves it anyway)
[2030s] Uses a quantum computer to decrypt the stored data
			↓
[Result] Payment data from 2026 gets exposed

The attack works like this: someone quietly intercepts and stores encrypted communications today, then decrypts everything in bulk once quantum computers become available. Payment data is a prime target, since it stays valuable for years. Data that's in transit today in 2026 could be sitting exposed in 2033.

What's secure today isn't necessarily secure tomorrow. Leaving a potential vulnerability unaddressed today is the same as ignoring a live threat tomorrow.

Four Years of Security Protocol Advancement

Toss Payments has worked on upgrading the security protocol in phases since 2022. Instead of overhauling everything at once, we approached it step-by-step, implementing upgrades over the course of four years.

What may look like a simple list of technical upgrades is anything but. Behind each of these four bullet points was a constant tension: respecting the time merchants need to adapt, but never compromising on security. Every step was a tightrope walk between the drive to adopt new security technologies quickly and the weight of knowing that any misstep could lead to a disruption in payments for merchants.

Let's look at what each phase means, and why we approached it in this order.

Implementing HTTP/3 (2022): Starting with the Easiest, Obvious Step

The journey began with the adoption of HTTP/3. HTTP/3 is the latest protocol for transferring data over the web. It's designed to be faster and more stable even in poor network conditions. More importantly, HTTP/3 is designed to mandate the use of TLS 1.3. Meaning, the latest security protocol applies automatically simply by enabling HTTP/3.

In 2022, Toss Payments adopted HTTP/3, making it the first in the PG industry to do so. It served faster payment window response times and elevated security as well. The best part for merchants was that no additional work was needed on their end. As web browsers (Chrome, Safari, Edge etc.) used by buyers automatically opt for the latest protocols, merchants didn't have to do anything. The upgrade would apply itself through their existing Toss Payments integration.

HTTP/3 required nothing from merchants, making it the right first step for this journey. It laid the groundwork for the more demanding work that would follow.

Removing Weak TLS Cipher Suites (2022–2025): The Longest 3 Years

This second phase was the longest and most difficult out of the four. Let's look at what a cipher suite is to understand why it was so complex.

What is a cipher suite? A cipher suite is a set of cryptographic algorithms used to decide an encryption method when the server and client communicate over an encrypted connection. Think of it as preparing several different types of locks, and choosing the strongest one that both sides have. But as time passes, flaws may be found in some of these locks, which means that algorithms once deemed secure can become breachable by experts. This happens regularly, at which point the corresponding cipher suite is classified as a weak combination and must be removed.

The real problem, however, lies in the merchant's server. Some merchants run old legacy servers that don't support the latest cipher suites, and happen to only support the "weak combinations."

# Case Scenario
Merchant Server: Supports only TLS_RSA_WITH_AES_128_CBC_SHA (weak)
Toss Payments: Planning to remove such cipher suite
→ Removing the cipher suite means halting payments for that merchant
→ Leaving the cipher suite means exposing all merchants to risks

There were two obvious options we could choose:

Neither option was acceptable. So we carved out our own third path.

The answer we found was phased removal + individual support. We first looked into which cipher suite each merchant was using, and began notifying the merchants with weak combinations six months to a year ahead of the removal. We prepared technical support documentation, provided specific guidance on how to update based on each merchant's environment, and offered direct technical consultations where needed. Only after a sufficient grace period did we actually remove the corresponding cipher suites.

At the forefront of this third phase was the TAM (Technical Account Manager) Team. The team reached out to each merchant to assess their technical status, explain the situation in plain terms for store owners unfamiliar with security, and even walk the merchants with tech teams through specific configuration settings. This would not have been achievable with just engineering efforts alone. The TAM team quietly kept up this work at the front lines with merchants for over three years, allowing us to remove weak combinations one by one without ever bringing payments to a stop.

Full Rollout of TLS 1.3 (2022–2025): A Stronger Channel, Silently Set as Default

TLS is the key protocol responsible for internet communications encryption. With each version, it gets safer and faster. The current industry baseline for what is considered "safe" is TLS 1.2 or above, and Toss Payments operates on that same baseline.

That said, the 1.2 baseline is no reason to hold off on 1.3. In fact, the best call is to actually support both versions. Both TLS 1.2 and 1.3 can be served from one endpoint, and any client that supports TLS 1.3 will automatically default to this safer channel. Old clients can continue using TLS 1.2 as before, meaning we raised the overall security standard without forcing any changes on our merchants.

Starting in 2022, we began enabling TLS 1.3 endpoint by endpoint and by 2025, TLS 1.3 was fully rolled out for all endpoints. Merchants and buyers running the latest environments were automatically upgraded to a stronger security channel without any action required on their end.

After years of removing cipher suites and implementing TLS 1.3, there was one clear lesson learned. Raising the security standard across tens of thousands of merchants at once is far more involved than one might expect. The bottleneck wasn't applying the technology to servers itself, but the time spent helping merchants transition and waiting for them to do so at their own pace. That taught us that we need to start security protocol improvements as early as possible, to give merchants enough time to make the switch.

Implementing Post-quantum Cryptography (PQC) (2026): A Future Built Now

The lesson we learned sparked another question: "Do we need to implement PQC in advance?"

"If there's another opportunity for security improvement, let's start even earlier."

That was the answer we found from our three years of experience. And as if on cue, the next opportunity arrived in the form of post-quantum cryptography. Quantum computers have yet to be commercialized, but as with the "Harvest Now, Decrypt Later" attacks mentioned earlier, the threats are already there. Preparing for the threats that lie a decade ahead means starting preparations today.

Toss Payments began laying the groundwork for PQC implementation in 2025 and completed the full rollout in April 2026. It was the final step of the four-year security protocol modernization effort, and at the same time, the first step toward the decade ahead.

As with TLS 1.3, clients that support stronger security communications default to the latest, safest channel.

Nothing changes for the merchants. No configurations or updates are needed. It minimizes the pressure for merchants while serving the highest level of security by default.

It Was Built Together

Getting this architecture stably into production was never something a single team could pull off alone. It took multiple teams working in sync, each bringing their piece to the table.

Toss Payments shares the vision behind the government's "National Post-Quantum Cryptography Transition Master Plan (양자내성암호 전환 마스터플랜)." Thanks to the outstanding collaboration across these three teams, we've completed a proactive technical proof-of-concept to help secure the private payments ecosystem. This is especially meaningful because it means we've already validated interoperability and established security guidelines at the private sector level, well ahead of the national transition target set for 2035.

Why Look Ten Years Ahead?

If you've made it this far, you most likely have one question on your mind: "Quantum computers aren't in the market yet, so why the rush?"

The answer to that question lies in our four-year journey itself.

Keeping Every Merchant on Board

Toss Payments serves not only web browsers that buyers use, but also API integrations with merchants that have been built up for decades. The server environments merchants use to call this API are more varied than one might expect, and many are legacy systems that cannot be easily updated. The three-year process of streamlining cipher suites and adopting TLS 1.3 made that abundantly clear.

Getting Ahead on Security Buys Merchants' Time

That's the conclusion we arrived at from four years of experience.

When security issues are addressed only as they become urgent, merchants are left with no choice but to hear, "you need to update immediately." That disrupts the merchants' development roadmaps and puts the entire payments ecosystem at risk. But when we look a decade ahead and start preparing now, the story changes completely.

What the 4-year Journey Taught Us

Let's take a look at the past 4 years.

Proactive adoption of HTTP/3 → Phase out of weak Cipher Suites → Full TLS 1.3 rollout → Adoption of post-quantum cryptography

Each stage was never just a technical upgrade. It was the Infrastructure, Server Platform, and TAM team working together, quietly laying the groundwork today for a safer decade ahead. All to serve the tens of thousands of merchants and the tens of millions of consumers behind them.

Just as we declared with the launch of the Legacy Overhaul Series, we are challenging the assumption that payments are "inherently inconvenient and complex." We want to challenge the convention once again. But this time, in the area of security: a world where the highest level of security is already the default, without merchants ever having to think about it, that's the world we're working to create.

New threats will come. They always do. When that day arrives, we will be ready. For PGs, that work is already underway in the form of communication security.

On April 3, 2026, Toss Payments became the first company in Korea's financial & IT industry to implement NIST-standard post-quantum cryptography (PQC) in a payment service. (Related article)