Getting ahead of ‘harvest-now-decrypt-later’: Post-quantum cryptography planning

Run that comparison against your own data instead of against an industry average. A retail transaction log with a two-year retention window carries a different risk profile than genomic data, merger documentation or infrastructure design specs that need to stay confidential for thirty years. For a good number of organizations, that confidentiality window runs well into the 2030s and beyond — healthcare records, financial data and classified information can need protection for fifty years or more. If any of your data fits that description, “quantum computers are a decade away” stops being a reason to wait and starts being the reason you’re already behind.

What migration requires

Treating this like a patch cycle is the mistake I see most often — swap an algorithm, ship an update, move on. That framing misses the scale of what’s involved. Migrating to post-quantum cryptography means locating every algorithm in every protocol, on every device, across every product in your supply chain and replacing each one without breaking interoperability with everyone else going through the same transition on their own timeline.

Start with discovery, because it’s the piece every client underestimates going in. You need a real inventory of where RSA, ECC and other quantum-vulnerable algorithms are running — in TLS configurations, code signing processes, VPN tunnels, embedded firmware and third-party libraries you didn’t write and may not fully control. Almost every discovery project I’ve been part of has turned up cryptography the client had forgotten existed.