Quantum computing can sound like a problem for a decade from now, but for data security it's already a planning problem. A large enough quantum computer will be able to break the public-key encryption behind nearly every secure transaction, login and software update. Nobody knows exactly when that machine will exist. That uncertainty is a reason to start now, because moving an organization to new cryptography takes years. Your data may also be exposed already.
Why act now
The main reason to act today is a tactic called "harvest now, decrypt later." Attackers, especially well-funded nation-states, are recording encrypted traffic and stealing encrypted backups now, so they can decrypt them once quantum computers are powerful enough. Any information that has to stay confidential for years is already at risk.
The timeline is also getting shorter. In 2019, researchers estimated that breaking RSA-2048, one of the most common encryption standards, would take about 20 million qubits. A 2025 paper from Google researcher Craig Gidney cut that to under one million, a twentyfold drop, and research in 2026 claims further reductions. Expert forecasts for when encryption actually breaks range from about 2029 to the mid-2030s.
Regulators are already acting on that timeline. NIST, the U.S. standards body, plans to deprecate RSA and elliptic-curve cryptography for new systems by 2030 and disallow them entirely by 2035. These deadlines formally apply to U.S. federal systems, but they will set expectations for vendors, auditors and regulators everywhere.
What breaks and what holds
Not all encryption is equally exposed. Quantum computers running Shor's algorithm break public-key cryptography outright: RSA, elliptic-curve algorithms (ECDSA, ECDH) and Diffie-Hellman. These are used for key exchange, digital signatures and certificates. Larger keys don't fix this, because RSA-4096 falls to the same attack with only modestly more effort.
Symmetric encryption holds up much better. Grover's algorithm only halves its effective strength, so AES-256, SHA-256 and modern password-hashing methods such as bcrypt and Argon2 remain safe. AES-128 should move to AES-256. This means the migration is concentrated on how keys are exchanged and how things are signed. You don't need to re-encrypt everything.
Where businesses are exposed today
Even before a quantum computer exists, most organizations have six weak spots:
• Harvest-now exposure. Traffic and backups captured today can be decrypted later.
• No cryptographic inventory. Few companies know where RSA and ECC are used across their applications, devices and vendors.
• Hard-coded algorithms. Cryptography built into legacy applications, firmware and operational technology often can't be changed without rebuilding the system.
• Long-lived signatures. Firmware, code-signing keys and signed records may need to stay trustworthy for 10 to 20 years or more.
• Vendor dependency. SaaS, cloud, payment and hardware providers control much of your cryptography and when it gets upgraded.
• Slow upgrade cycles. Certificate infrastructure, hardware security modules and embedded devices can take years to replace.
A simple test for urgency
Mathematician Michele Mosca offers a clear way to judge risk. Let X be how many years your data must stay secret, Y how many years your migration will take, and Z how many years until quantum computers can break today's encryption. If X plus Y is greater than Z, you're already late.
Take health records that must stay confidential for 10 years, with a five-year migration. If quantum capability arrives in about 10 years, that data is already five years behind. You can't control Z. You can control how well you understand X and how quickly you shrink Y.
Deciding what to protect first
The most useful question for prioritizing is how long a piece of data needs to stay secret. A four-tier model works well:
• Tier 1, critical (10+ years): trade secrets, some PII data, R&D, merger plans, health and genetic data, biometrics and root keys. Start now with hybrid post-quantum protection for data in transit, and re-protect archives.
• Tier 2, high (5–10 years): customer personal data, financial records, contracts and legal files. These go in the first migration wave, within one to two years.
• Tier 3, moderate (1–5 years): internal operations, HR records and transaction logs. Migrate these during normal refresh cycles.
• Tier 4, low (under a year): public content and short-lived session data. Follow vendor defaults.
For each system that touches this data, ask three questions. How long must the data stay trusted? Does it cross the internet or a third party, where it could be captured? Is the fix a configuration change, a vendor update or new hardware? Systems with a long shelf life, high exposure and the hardest fixes should start first.
The systems most affected
Public-key cryptography is built into the core of most enterprise technology. The most affected areas are:
- certificates and public-key infrastructure
- TLS, HTTPS and VPN connections
- identity and single sign-on
- code signing
- payment systems and hardware security modules
- IoT and operational technology devices
- encrypted email
- backups and archives
- digital assets such as blockchain wallets
Some of these risks are about eavesdropping. Others, like code signing and identity, are about forgery: someone who can forge signatures can impersonate users or push malicious software updates.
The replacements already exist
You don't need to wait for new technology. In August 2024, NIST published its first post-quantum standards: ML-KEM for key exchange, and ML-DSA and SLH-DSA for digital signatures. HQC was chosen as a backup in 2025. Major browsers and cloud providers already use hybrid key exchange, which combines classical and ML-KEM algorithms, by default. Keeping your software and SDKs up to date gets you some of that protection automatically.
A seven-step plan
1. Appoint an owner and fund the work. This effort spans security, IT, engineering, procurement and legal, so it needs an executive sponsor and a budget.
2. Inventory your cryptography. Map every algorithm, key, certificate and library.
3. Classify data and rank systems using the tiers and the three questions above.
4. Press your vendors. Ask for dated post-quantum roadmaps and write them into contracts.
5. Build crypto-agility. Route encryption through central libraries and services, so future algorithm changes are configuration changes rather than rebuilds.
6. Pilot hybrid post-quantum encryption on Tier 1 data flows first.
7. Migrate in waves and verify, retiring RSA and ECC in priority order.
In practice, the first six months are about visibility: approve the sponsor, inventory the top systems and define the data tiers. Months 6 to 18 cover building and piloting. Months 18 to 36 are the large-scale migration, which should finish well before the 2030 deadline.
Mistakes to avoid
Don't wait for "Q-Day" headlines, because harvested data is already exposed. Don't rely on bigger RSA keys. Avoid a single big-bang cutover; migrate gradually and test. Don't assume your vendors have it handled. And don't treat this as only an IT project. It's a business / organization risk that belongs in front of the board.
Where to start
Leadership can start this quarter with three decisions: name an owner and fund a cryptographic inventory, approve the data tiers and the priority systems, and require post-quantum roadmaps from critical vendors. None of these takes major spending, and each one shortens the migration time that decides whether you finish before the deadline.
OnData’s Take
There are many ways to approach preparing for the Quantum era. One of the reasons that OnData has pursued its various product strategies is to operationalize these approaches. This means they endure the test of time … organizations can change, people can change, but the need to protect the data continues.
