Solution Quantum readiness
Attackers are already harvesting encrypted data to break once quantum computers arrive. OnData helps you find what's at risk, prioritize what must stay secret longest, and protect it now: SecureDB, SecureFile and SecureAI use ML-KEM, NIST's post-quantum standard, so harvested data stays sealed.
Mosca's theorem
X + Y > Z
0 yrs late to spare
<1M qubits
Latest estimate to break RSA-2048, down from about 20 million in 2019.
2030
NIST target to deprecate RSA and elliptic-curve keys for new systems.
2035
NIST target to disallow quantum-vulnerable algorithms entirely.
Aug 2024
NIST published the first post-quantum cryptography standards.
Harvest now, decrypt later
Adversaries don't need a quantum computer yet. They only need to copy your encrypted traffic, backups and archives now, and wait. Any data that must stay secret past Q-Day is already exposed.
Today
Encrypted traffic, VPN sessions and backups are captured.
Captured 2026
TLS_ECDHE_RSA_WITH_AES_256_GCM
9f3a…c41e 7b2d…e08f
2.4 TB · 18,402 sessions2026 → Q-Day
Ciphertext sits in attacker storage. Nothing looks breached.
Stored
archive_2026.tar.enc
status: waitingQ-Day
Shor's algorithm breaks the RSA or ECC key exchange. The records open.
Decrypted at Q-Day
name: J. Doe
ssn: 000-00-0000
dx: Case notesWhat breaks, what holds
Broken by Shor's algorithm
Used for key exchange, signatures and identity. Bigger keys don't fix it.
| Algorithm | Used for | Status |
|---|---|---|
| RSA | Key exchange, certificates, signatures | Broken |
| ECDSA | Signatures, code signing, identity | Broken |
| ECDH | TLS and VPN key agreement | Broken |
| DH / DSA | Legacy key exchange and signatures | Broken |
Moving from RSA-2048 to RSA-4096 only buys time. It doesn't make the algorithm quantum-safe.
Holds with the right key size
Used to encrypt the data itself. Grover's algorithm weakens it, but larger keys compensate.
| Algorithm | Used for | Status |
|---|---|---|
| AES-256 | Data at rest and in use | Holds |
| AES-128 | Move to AES-256 for long-lived data | Upgrade |
| SHA-256 / SHA-3 | Integrity and hashing | Holds |
| bcrypt / Argon2 | Password storage | Holds |
Why this matters: data encrypted with strong symmetric keys survives, as long as those keys aren't exchanged or wrapped with RSA or ECC.
Prioritize by lifespan
Not all data needs the same urgency. Rank it by how many years it must stay confidential, then migrate in that order.
10+ years
Health records, SSNs, classified and CUI data, trade secrets and long-term contracts.
Migrate first. Already at risk.
5–10 years
Financial records, customer PII, legal files and IP in development.
Pilot hybrid encryption now.
1–5 years
Internal reports, operational data and short-term contracts.
Plan it into the roadmap.
<1 year
Session data, public content and short-lived tokens.
Migrate with standard refreshes.
Where you're exposed
No cryptographic inventory
Nobody knows where RSA and ECC are used.
Hard-coded algorithms
Crypto built into apps can't be swapped quickly.
Long-lived signatures
Documents and firmware are signed to last for decades.
Vendor dependence
Your crypto moves only as fast as your vendors.
Slow upgrade cycles
Systems replaced every 10+ years miss the deadline.
PKI
Certificates and CAs
TLS & VPN
Data in transit
Identity & SSO
Tokens and federation
Code signing
Software supply chain
Payments
Cards and transactions
IoT & OT
Long-lived devices
Backups
Prime harvest targets
Databases
Keys wrapped with RSA
The replacements
Formerly CRYSTALS-Kyber
Key encapsulation for establishing shared keys.
Formerly CRYSTALS-Dilithium
General-purpose digital signatures.
Formerly SPHINCS+
Hash-based signatures as a conservative alternative.
Selected as a backup KEM
A different mathematical basis, in case ML-KEM is weakened.
Major browsers and cloud providers already combine classical and post-quantum key exchange, so you stay protected even if one algorithm fails.
A practical roadmap
Months 0–6
Appoint an owner and fund it
Make it a business program with a named leader.
Inventory your cryptography
Find every use of RSA, ECC and other quantum-vulnerable keys.
Classify data and rank systems
Apply the four tiers and Mosca's X + Y > Z.
Months 6–18
Press vendors for roadmaps
Get post-quantum commitments and dates in writing.
Build crypto-agility and pilot hybrid
Centralize keys and policy, then pilot hybrid encryption on Tier 1 data.
Months 18–36
Migrate in verified waves
Move system by system, and test each before the next.
Retire vulnerable crypto and stay agile
Get ahead of NIST's 2030 deprecation date, and be ready to swap again as standards evolve.
Avoid these
By then, harvested data is already exposed.
Shor's algorithm doesn't care about key size.
Migrate in waves you can verify and roll back.
Ask for roadmaps and dates in writing.
It's a business risk that needs board-level ownership.
Where OnData fits
When encryption and policy live at the data layer instead of inside every application, you can find what's at risk, protect it now and change algorithms without rewriting your apps.
ML-KEM is available now in SecureDB, SecureFile and SecureAI. Talk to our team about rolling it out in your environment.
Discovery and classification show where Tier 1 and Tier 2 data lives across databases and files.
SecureDB, SecureFile and SecureAI protect keys with ML-KEM and data with strong symmetric encryption, so harvested copies can't be decrypted later.
One place to manage keys and policies means algorithms can change without touching every application.
Audit trails and reporting show auditors and boards which data is protected and how migration is going.
FAQ
Have another question? Talk to our team →
No one knows exactly. Expert forecasts range from about 2030 to the mid-2030s, and NIST plans to deprecate RSA and ECC for new systems by 2030. Because of harvest now, decrypt later, data that must stay secret past that point is at risk today.
AES-256 is expected to hold. Grover's algorithm roughly halves its effective strength, which still leaves a wide margin. AES-128 should move to AES-256 for data that must stay secret for years.
It's the ability to swap cryptographic algorithms without rewriting applications. Teams get there by centralizing keys and encryption policy instead of hard-coding algorithms into every system.
Yes. SecureDB, SecureFile and SecureAI use ML-KEM, the NIST post-quantum key encapsulation standard (FIPS 203), to protect encryption keys, which closes the door on harvest now, decrypt later. Because OnData keeps keys and policy central at the data layer, your applications don't change. Talk to our team about rolling it out in your environment.
Start with an inventory of where RSA and ECC are used, then classify your data by how long it must stay secret. Protect Tier 1 data first.