Applying Post-Quantum Cryptography for the Quantum Computing Era: Why Implement It 10 Years Early?
Toss Payments’ hardest legacy-modernization challenge was not replacing old systems, but improving security across tens of thousands of merchants with diverse, outdated environments. Over four years, it gradually introduced HTTP/3, removed vulnerable cipher suites, deployed TLS 1.3, and ultimately adopted post-quantum cryptography (PQC) in April 2026. The central lesson is that security upgrades must begin early and be introduced gradually, with merchant support and backward compatibility built in. ## Breaking the Inertia of Legacy Systems - Mission-critical payment services tend to follow the principle: “If it works, don’t touch it.” - Security protocol changes are particularly difficult because they can affect every merchant integration and may be hard to troubleshoot or roll back. - Many merchants still operate decades-old server-side systems that cannot support modern security policies. - Documentation alone is often insufficient, especially for merchants without dedicated development teams. - Because every API, SDK, payment window, and server connection is part of the security boundary, Toss Payments could not improve security independently of its merchants. ## Why Existing Encryption Must Evolve - Modern HTTPS, banking, and payment systems rely heavily on RSA and ECDSA. - These algorithms are considered secure because factoring large numbers and solving elliptic-curve problems is impractical for classical computers. - Quantum computers could solve these problems efficiently, making current public-key cryptography vulnerable. - The anticipated point at which quantum computers can break these systems is often called “Q-Day.” - The “Harvest Now, Decrypt Later” threat means attackers can collect encrypted payment data today and decrypt it years later when quantum computers become practical. ## A Four-Year Security Upgrade Program Toss Payments chose a gradual migration strategy to improve security without abruptly disrupting merchant payments: - **2022:** Introduced HTTP/3, which requires TLS 1.3. - **2022–2025:** Removed vulnerable TLS cipher suites. - **2022–2025:** Enabled TLS 1.3 across all endpoints. - **April 2026:** Introduced post-quantum cryptography. ## HTTP/3 as a Low-Impact Starting Point - HTTP/3 improves speed and reliability on unstable networks. - Because it requires TLS 1.3, enabling HTTP/3 also raised security standards. - Modern browsers automatically select HTTP/3, so merchants required no configuration changes. - This made HTTP/3 an effective first step with minimal migration risk. ## Gradual Cipher Suite Removal - A cipher suite defines the algorithms used by a client and server to establish encrypted communication. - Some legacy merchant servers supported only vulnerable suites, such as `TLS_RSA_WITH_AES_128_CBC_SHA`. - Removing them immediately could stop payments for affected merchants, while delaying removal would leave the wider ecosystem exposed. - Toss Payments used: - Merchant-by-merchant compatibility analysis - Individual notifications six months to a year in advance - Environment-specific documentation and configuration guidance - Technical consulting where necessary - The Technical Account Manager team was essential in coordinating these changes and communicating with merchants in accessible language. ## TLS 1.3 Deployment - TLS 1.2 remained the minimum supported version, while TLS 1.3 was added alongside it. - Clients capable of TLS 1.3 automatically use the stronger protocol. - Older clients continue using TLS 1.2 without forced changes. - TLS 1.3 was enabled endpoint by endpoint from 2022 and supported across all endpoints by 2025. - The process demonstrated that ecosystem-wide security improvements require more time helping merchants migrate than technically changing the servers. ## Post-Quantum Cryptography - Toss Payments began preparing for PQC in 2025 and completed deployment in April 2026. - Modern browsers and clients that support PQC automatically use stronger quantum-resistant channels. - Unsupported environments continue using established encryption methods, preserving compatibility. - Merchants do not need to change configurations or update their integrations. - The approach provides stronger protection against future quantum attacks while minimizing present-day disruption. ## Cross-Team Collaboration - **Infra Team:** Applied PQC within Toss Payments’ private data-center infrastructure and physical hardware. - **Server Platform Team:** Integrated PQC into live traffic paths in AWS. - **TAM Team:** Used its experience from the cipher-suite migration to guide merchants and assess integration environments. - The result was a large-scale, proactive security deployment across the private payment ecosystem. Toss Payments’ experience suggests that organizations should start security migrations well before threats become immediate. Compatibility layers, staged enforcement, and sustained technical support allow legacy ecosystems to adopt stronger security without sacrificing availability.
Read original(opens in new tab)