Arryaan Bhandari - TechStoriess.com

I want to talk about post-quantum cryptography, because it is, without much competition, the most consequential deadline most of you reading this haven't put on a calendar yet. Other tech articles will give you predictions and vibes. This one is going to give you a checklist. These are just my findings from digging through a stack of vendor FAQs, government mandates, and academic papers, but they add up to something worth your attention. Let's start with a couple of things you already know, even if you have never said them out loud: Your organization's cryptography works. Nobody at your company has ever said, "I don't care if someone decrypts our customer database in 2031," or "Not my problem if our firmware gets tampered with." The encryption you have is doing its job, right now, today. Some of that cryptography has an expiry date, and it's earlier than you think. You have heard "quantum computing will break encryption" as background noise for years - the kind of sentence that sounds like science fiction until, suddenly, it's a line item in a government procurement document. So what? Is this actually urgent, or just interesting? The honest answer is: it depends on what you're protecting, and for how long. Here's the thing that changes the calculation entirely - attackers don't need a working quantum computer today to hurt you. They just need to be patient. Security researchers call this "harvest now, decrypt later," and it means exactly what it sounds like: someone intercepts your encrypted data today, sits on it, and decrypts it the moment a cryptographically relevant quantum computer exists. If that data is a lunch order, fine, nobody cares. If it's a medical record, a government file, a patent application, or a firmware signature meant to outlive the device it protects - that data has a shelf life measured in decades, not months. The risk isn't hypothetical because the computer doesn't exist yet. The risk is live right now, sitting in transit, waiting. And the timeline just got shorter. In March 2026, two separate research papers landed with a fairly unwelcome finding: breaking today's elliptic curve cryptography would take roughly twenty times fewer qubits than everyone had assumed. Google didn't wait around to see if that number held up under scrutiny - within weeks it had set a firm 2029 deadline for full post-quantum migration across its own infrastructure. Cloudflare followed within days, moving its own deadline three years earlier to match, and - this detail matters - shifting its priority from encrypting data to authenticating it first. When the companies closest to the research start rearranging their own roadmaps that fast, that's not marketing. That's people who read the paper and got nervous. Recognizing which layer you're actually looking at Here's where I think most coverage of this topic goes wrong: it treats "post-quantum security" as one race with one finish line. It isn't. It's several separate races happening on different tracks, at different speeds, defended by different companies, and confusing them is how you end up either panicking about the wrong thing or ignoring the right one. Let me walk you through the tracks, because - much like accessibility guidelines or usability heuristics - there's simply too much here to hold in your head all at once without a framework. Track one: the device itself, before anything gets sent anywhere. This is HP's territory, and I want to be precise about why. In 2024, HP built what it called the world's first business PCs designed to resist quantum-based firmware attacks - an upgraded Endpoint Security Controller chip that checks a device's firmware before the processor or operating system even wakes up. It does this with a dual-signature system: both a classical RSA signature and a new quantum-resistant LMS signature have to check out, or the device simply won't boot. Miss one, and nothing happens. HP extended the same logic to its printer line in 2025. As of this writing, no other major manufacturer has shipped a comparable hardware-level solution - HP's own FAQ says as much, and nobody's disputing it. This isn't a small distinction. Firmware, once compromised, is brutal to fix and tends to outlive an entire device refresh cycle - three to five years, sometimes longer. The U.S. government has already decided this matters enough to write it into procurement rules: starting in 2027, National Security Systems will only buy devices using quantum-resistant code signing for firmware and software, with a full migration deadline in 2030. If your organization is locking into a multi-year PC or print contract today, you're already making a decision about a threat that won't fully arrive for years. Track two: everything in transit. This is a much more crowded field, and none of it competes with what HP is doing, because it's solving an entirely different problem. Cloudflare has offered post-quantum key exchange across all customer sites and APIs since 2022, and now reports over 65% of human-initiated traffic on its network uses post-quantum encryption. Google made itself the first major browser vendor to switch on hybrid post-quantum key agreement by default in Chromium - meaning billions of Chrome sessions are protected without a single website operator lifting a finger. AWS rolled hybrid post-quantum TLS into its Key Management Service in 2024, and expanded it to Certificate Manager and Secrets Manager in early 2026. Microsoft's Quantum Safe Program is working through a longer runway - full transition by 2033 - weaving the NIST-standardized ML-KEM and ML-DSA algorithms into SymCrypt, the cryptographic engine behind Windows and Azure. Apple got there early on the consumer side, folding its PQ3 protocol into iMessage back in iOS 17.4. All of that is real, meaningful work. None of it touches a device's firmware before that device even connects to a network. Two different problems, two different tracks, both worth running. The places nobody's finished the job yet I promised you this article wouldn't just be good news, and here's where it gets less tidy. Routers still don't quite fit. NIST has published cybersecurity recommendations for consumer routers as part of the broader post-quantum push, and providers like Akamai, Fastly, and NGINX have started shipping post-quantum support at the web-serving layer. But there's a genuinely awkward technical snag underneath all of it: the new TLS 1.3 handshake using ML-KEM and ML-DSA produces a message bigger than a standard internet packet, which means it has to be split across multiple packets - something a lot of existing routers, proxies, and firewalls simply weren't built to handle cleanly. Nobody has announced a "world's first quantum-resistant router" the way HP announced its PCs. This one's still a standards conversation, not a product on a shelf. IoT devices have a harder problem: math is heavy, and hardware is small. Quantum-resistant algorithms cost more computational overhead than the classical cryptography they're replacing, and most IoT hardware simply doesn't have the headroom. There's promising research chipping away at this - a March 2026 academic framework called Q-EDGE-OS squeezed a full post-quantum cryptographic stack, mesh networking included, onto microcontrollers with as little as 256 KB of flash memory, tested on smart meters and railway sensors. GSMA published its own roadmap for crypto-agility across IoT networks in mid-2026. But research and standards-track work is not the same thing as HP walking into a boardroom with a shipping product. This one's still a few steps behind. And infrared? Nobody's even started. I looked. There's no meaningful commercial or academic work on quantum-resistant security for infrared communication - the short-range, line-of-sight protocol still quietly running your TV remote and a handful of industrial sensors. I don't think this is negligence so much as triage: infrared's short range and low bandwidth make it a genuinely bad target for "harvest now, decrypt later" attacks. Still worth naming, if only so nobody mistakes silence for safety. The question that comes before all of the other questions Here's something I didn't expect to find, and it might be the most practically useful part of this whole piece. Every fix I have described so far - HP's chip, Cloudflare's key exchange, Microsoft's cryptographic libraries - has a hidden assumption baked into it: that your organization already knows exactly where its vulnerable cryptography lives. Most organizations don't. Cryptography in a typical enterprise is scattered across decades of applications, APIs, internal tools, and cloud services - undocumented, half-forgotten, occasionally written by someone who left the company before some of your current employees were hired. Before any chip or protocol upgrade means anything, somebody has to answer an unglamorous question: where, precisely, are we still relying on cryptography that a quantum computer will eventually break? This is the gap that discovery platforms are starting to fill. PQStation, out of Singapore, is one example - it scans applications, networks, APIs, and cloud environments to build an inventory of what cryptography you actually have, flag what's vulnerable, and map a migration path toward hybrid and quantum-resistant algorithms. Its companion tool, QVision, layers real-time visibility and compliance reporting on top of that - aimed squarely at the sectors with the messiest, highest-stakes legacy cryptography: banking, telecom, government. It's a fundamentally different contribution than a chip or a library. HP and Cloudflare protect what you have already identified as needing protection. A platform like this exists to answer the question that comes before that one - and for most organizations, that discovery step, not the fix itself, may be the actual bottleneck between "we know quantum is a threat" and "we have actually done something about it." Your homework I told you at the start I'd give you homework, and I wasn't joking. Here it is, in the order I'd actually do it: 1. Find out what you don't know Before you evaluate a single vendor, figure out whether your organization has any real inventory of where its cryptography lives. If the honest answer is "no idea," that's your starting point, not your last step. 2. Separate the tracks. Don't let a vendor pitch you device-level firmware protection as a substitute for transport-layer encryption, or vice versa. They solve different problems. You may need both. 3. Check your procurement contracts against the calendar. If you're signing a multi-year PC, printer, router, or IoT hardware contract this year, ask the vendor directly what their post-quantum roadmap looks like - not someday, but with a date attached. 4. Watch the gaps, not just the wins. Routers, IoT, and infrared aren't finished stories. If any of those categories touch your infrastructure, that's precisely where you shouldn't assume the problem is already solved just because you have read a press release about PCs. Quantum computers capable of breaking today's encryption are probably still years away. That's not the comforting sentence it sounds like. The organizations getting caught out won't be the ones who ignored the threat - they'll be the ones who assumed someone else had already mapped it for them. …… and a bonus I thought I had wrapped this section. Then, right before publishing, I ran it by a connection in this space - and he proposed an addition worth building the whole point around. Credit here is entirely his. I thought I would wrapped this section. Then, right before publishing, I ran it by a connection in this space - and he proposed an addition worth building the whole point around. Credit here is entirely his. "The instinct here is to treat this migration as a one-time task: find the inventory, swap in the new algorithms, done," says Arryaan Bhandari, co-founder and COO of PQStation - the discovery platform mentioned earlier in this piece. "But quantum won't be the last thing that forces this conversation. Standards get revised. An algorithm that looks solid today can get quietly narrowed by next year's paper, the way ECC just did." "Treat this as a single project," he warns, "and you will be redoing the same discovery work in a few years. Build the ability to find your own cryptography and swap it out on demand instead - next time, it's just a setting you change, not a new inventory." That capability, he says, already has a name: crypto-agility. So, check if your system is crypto agile? Go check. That's the whole assignment. Article Contributed by Arryaan Bhandari, Co-Founder & COO at PQStation

Tag: Arryaan Bhandari

Your Encryption Has an Expiry Date, and Nobody Told You

Your Encryption Has an Expiry Date, and Nobody Told You

Join Us!