Most quantum-readiness plans inventory the wrong layer.
Everyone's auditing certificates and TLS. Your real exposure is the data itself, sitting in files encrypted with algorithms that won't survive the decade. PKWARE finds that data across endpoint, server, M365, and mainframe, then protects what's most exposed first.
Quantum won't break your encryption once. It'll break it on a schedule.
You probably already know quantum is coming. The harder question is what comes after the first migration. Most of the cryptography in your environment was built to sit still. It can't. Once the first post-quantum algorithm gets retired, the next one follows faster, and the one after that faster still. Neven's Law, the observation that quantum capability scales doubly exponentially, means the gap between breaks keeps tightening. The encryption you deploy this year isn't the encryption you'll need in three.
And the clock already started for your data. Adversaries don't need a working quantum computer to hurt you. They need a hard drive and patience. Capture encrypted data now, store it, decrypt it when the math catches up. It's called harvest now, decrypt later, and the data most at risk is the data you encrypted years ago and stopped thinking about: customer records, financial files, anything with a retention policy that outlives its encryption.
Anyone selling a one-time migration is selling a vault door for a vault that has to keep changing.
Not all of your encryption is at risk. Knowing which part is, is the point.
Quantum computers don't threaten everything equally. The danger is concentrated in public-key cryptography, the algorithms behind key exchange and digital signatures. Symmetric encryption and hashing hold up fine at the right key sizes. So the work isn't replace all your encryption. It's find the public-key cryptography and the long-lived data protecting it, and move that first.
| Today | What it does | Quantum status | Move to |
|---|---|---|---|
| RSA | Key exchange, digital signatures | Breakable by Shor's algorithm | ML-KEM (FIPS 203), ML-DSA (FIPS 204) |
| ECDH / ECDSA (elliptic curve) | Key exchange, signatures | Breakable by Shor's algorithm | ML-KEM (FIPS 203), ML-DSA (FIPS 204) |
| AES-256 | Bulk data encryption | Holds at 256-bit | Keep |
| SHA-384 / SHA-512 | Integrity, hashing | Holds | Keep |
NIST finalized ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) in August 2024. SLH-DSA is the hash-based signature backup.
A post-quantum program looks endless. It comes down to three moves.
The reason most organizations haven't started isn't budget. It's that the program reads as a multi-year transformation with no obvious first step. It isn't. Strip it down and there are three moves, and the first two are things PKWARE already does every day.
See where your cryptography lives
You can't migrate what you can't see, and you can't see your cryptography until you can see your data. Most teams that have started post-quantum planning inventoried the obvious layer first: certificates, TLS, code-signing. The blind spot is the data itself, the encrypted files scattered across endpoints, file shares, M365, databases, and the mainframe. PKWARE's discovery scans every one of those surfaces and gives you a map of your own environment, not a lecture about inventory.
Understand what's actually exposed
Breadth tells you where the encrypted data is. Depth tells you what it is. Two files can sit side by side and carry completely different risk. One's a marketing PDF. The other is twenty years of customer records with a retention policy that outlives its encryption. Depth is the context that separates them, and it's what surfaces the harvest-now, decrypt-later targets you forgot you had.
Protect what's exposed now
A board doesn't fund a five-year plan with nothing to show this quarter. So don't bring them one. Once depth has ranked the risk, protect the top of that list now, with today's encryption, and you've defended your most exposed data against harvest-now, decrypt-later while the broader program runs in parallel. That's the quantum win you can show your board in 90 days.
>Every vendor will ship post-quantum algorithms. Almost none were built for what happens after the first migration.
Adding algorithm support is the easy part. The hard part is being built to change again, and again, without a new project each time. That's where the field narrows.
Coverage
One vendor across endpoint, server, M365, IBM Z (z/OS), and IBM i on Power, with one key-management layer underneath all of it. One decision, one operational cadence, instead of stitching separate vendors together for separate environments.
Architecture
Other vendors are adding algorithms to platforms built for stable algorithm sets. PKWARE rebuilt the key-management layer for continuous change. Algorithm updates ship through the same agent-update mechanism as any other release. An update, not a project.
Hybrid by default
Classical and post-quantum run on the same file at the same time. Legacy partners decrypt with RSA. Post-quantum-capable systems get full quantum protection. As partners catch up, you move to pure post-quantum on your own schedule. No cutover.
Foundation
PKWARE has owned the .zip format since creating it in 1989, four decades into protecting some of the most regulated data on earth. Protection runs on the data's native format. No parallel infrastructure, no new agent per environment. The encryption upgrades in place.
Do this once, and you don't do it from scratch again.
Here's where crypto agility actually earns its place. Not as the thing you have to fund up front, but as what you get once the first three moves are done. When the next algorithm gets retired, and it will, you're not starting another inventory and another migration project. The architecture that protected your data this year updates to whatever protects it next, in place, through the same mechanism you already run. That's the difference between a one-time fix and a posture that holds.
Trusted where the data is most regulated.
"Data privacy is going to continue to be important. And given that we operate at a global scale, we have to stay on top of that. This is why we are making investments in technology and working with partners like PKWARE."
"PKWare is great to work with, support is very responsive and remediates issues in a timely manner."
Gartner and Peer Insights™ are trademarks of Gartner, Inc. and/or its affiliates. All rights reserved. Gartner Peer Insights content consists of the opinions of individual end users based on their own experiences, and should not be construed as statements of fact, nor do they represent the views of Gartner or its affiliates. Gartner does not endorse any vendor, product or service depicted in this content nor makes any warranties, expressed or implied, with respect to this content, about its accuracy or completeness, including any warranties of merchantability or fitness for a particular purpose.
The full architecture is in the brief.
This page makes the case. The brief shows the build. It's a short read that walks through how PKWARE re-architected key management for continuous algorithm change, how hybrid classical and post-quantum protection runs on a single file, and the full algorithm and environment coverage behind it. Fill out the short form and it's yours.
- The architecture behind crypto agility at the file layer, and why an update beats a migration project
- How hybrid mode keeps legacy partners and post-quantum systems on the same file, with no cutover
- The full algorithm and five-environment coverage map, including IBM Z and IBM i
- Four decades of proof, from inventing the .zip format to protecting some of the most regulated data on earth
Post-quantum, answered
Post-quantum cryptography is a set of encryption and digital-signature algorithms designed to resist attacks from quantum computers while running on the classical hardware you already own. It replaces public-key algorithms like RSA and elliptic curve, which a large quantum computer could break. NIST finalized the first three standards (FIPS 203, 204, 205) in August 2024.
Harvest now, decrypt later is an attack where an adversary captures encrypted data today and stores it to decrypt once quantum computers mature. It means data with long-term value is already exposed, even without a working quantum computer. The longer your data must stay confidential, the more urgent the risk.
No one can name the exact date, and that's the point. Credible estimates have moved up fast: most now cluster around 2030, and the most aggressive roadmaps point at 2028 to 2029. Google has committed to migrating its own infrastructure by 2029, and many enterprises are drawing the line at 2029 to 2030. Because harvested data is already exposed and migration takes years, waiting for a confirmed date means starting too late.
The NIST standards are ML-KEM (FIPS 203) for key exchange, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a hash-based signature backup. Symmetric encryption like AES-256 and hashing like SHA-384 stay secure at the right key sizes. The urgent replacements are in public-key cryptography.
ML-KEM comes in three security levels, categories 1, 3, and 5. Category 1 is the floor and leaves too little margin for long-lived data. PKWARE defaults to category 3, a strong balance of security and performance for most enterprise data, and supports category 5 for the longest protection horizons and for environments under CNSA 2.0, which calls for the category 5 parameter set. The point is matching the level to the data, not defaulting to the minimum.
Start by finding where your encrypted data and aging cryptography live, across every environment, not just certificates and TLS. Rank that data by sensitivity and how long it has to stay secure. Then protect the most exposed data now with current encryption to defeat harvest-now, decrypt-later, and stage post-quantum algorithms as they're validated.
Yes. PKWARE supports ML-KEM, ML-DSA, and SLH-DSA, with hybrid classical-and-post-quantum mode by default, across endpoint, server, M365, IBM Z (z/OS), and IBM i on Power. Algorithm updates ship through the same agent-update mechanism as any other release, so adopting new standards is an update, not a replatforming project.
No. AES-256 stays quantum-resistant at its current key size, and quantum computing only weakens it modestly. The real exposure is in public-key algorithms (RSA, elliptic curve) and in long-lived sensitive data encrypted with them. That's where migration effort belongs.
Crypto agility is the ability to swap cryptographic algorithms without re-architecting your systems each time. You don't need to fund it as a separate program up front. It's the payoff of building protection the right way: once your most exposed data is covered, agility is what keeps you from running this same migration again in five years. And the standards are still moving. In 2026 NIST advanced nine more signature candidates to a third evaluation round, so locking into a single fixed algorithm set is a bet against where this is going.
See where your exposed data lives. Then protect it.
It starts with the brief. See how PKWARE protects your most exposed data now, and keeps protecting it as the standards change.
