You're probably getting questions about post-quantum cryptography (PQC) from your board, your audit team, or that one engineer who reads every NIST publication. The questions sound different depending on who's asking, but they're all circling the same uncertainty: what does this transition actually look like when you're the one building the migration plan?
I've compiled the questions that come up most often when security teams start planning for quantum-resistant cryptography. These aren't the sanitized versions you'd see in a vendor FAQ. They're the real ones, the kind you'd ask in a working session when you're trying to figure out if you can hit a 2030 deadline without breaking production.
The Source of These Questions
These questions surfaced across planning sessions with teams facing the same NIST IR 8547 timeline: RSA-2048 and ECC P-256 deprecated by 2030, completely removed from standards by 2035. Some teams are in regulated industries with NSA requirements kicking in for new acquisitions in 2027. Others are commercial organizations trying to figure out whether "harvest now, decrypt later" is a real threat to their data or just a conference talking point.
What they all share: nobody's done a cryptographic migration at this scale before, and the playbooks are being written in real time.
Do We Really Need to Care About This if We're Not a Defense Contractor?
Yes, but your timeline calculation is different.
The NSA's 2027 requirement for national security systems doesn't apply to you. NIST's 2030 deprecation date does. The question isn't whether you're a target, it's whether your data has a confidentiality window that extends past the point when a cryptographically relevant quantum computer is likely to exist.
Run Mosca's theorem against your own data retention requirements. If your migration will take X years, your data needs to stay confidential for Y years, and a quantum computer capable of breaking current encryption arrives in Z years, you're exposed when X + Y exceeds Z. For healthcare records, financial archives, or trade secrets with multi-decade confidentiality windows, that math puts you in scope whether you hold a clearance or not.
The "harvest now, decrypt later" threat model assumes an adversary is already capturing your encrypted traffic and storing it. They don't need a quantum computer today. They need patience and storage capacity, both of which are cheap.
What's the First Step?
Cryptographic discovery. Not a strategy deck, not a vendor evaluation, an inventory of every place you're running RSA, ECC, or other quantum-vulnerable algorithms.
This sounds mechanical until you try it. You'll find cryptography in TLS configurations, code signing processes, VPN tunnels, embedded firmware, and third-party libraries you didn't write. Every discovery project I've seen has turned up cryptography the client forgot existed or didn't realize they controlled.
CISA, NSA, and NIST published a joint migration playbook with six steps. Cryptographic discovery is step one, and it's the only step you can start without waiting for vendor roadmaps, budget approvals, or standards finalization. NIST finalized three FIPS standards in August 2024: ML-KEM for key encapsulation, ML-DSA and SLH-DSA for digital signatures. A fourth standard (FN-DSA, based on FALCON) is due out later this year. The standards exist. Your inventory doesn't.
Start the discovery project this quarter. It'll take longer than you think.
How Do We Know if a Vendor is Ready?
Ask for their PQC roadmap with dates, not intentions.
Specifically: when will they support ML-KEM, ML-DSA, and SLH-DSA in production? What's their testing timeline for hybrid modes that run classical and post-quantum algorithms in parallel? Which products will migrate first, and which ones are waiting on upstream dependencies they don't control?
If the vendor can't answer those questions with specifics, they're not ready, and you need to know that now, not in 2029 when you're trying to meet a deprecation deadline and discover you're blocked on a library that hasn't been updated in three years.
Vendor coordination is where migrations lose months. Your readiness only extends as far as the least-ready vendor in your dependency chain.
What is Crypto-Agility?
Crypto-agility means building systems where you can swap cryptographic algorithms without rebuilding the infrastructure around them.
The goal isn't to migrate once and hope the next transition goes smoother. There will be a next transition, either because a post-quantum algorithm gets broken, or because NIST updates its recommendations, or because a new attack model changes the threat landscape. If swapping an algorithm requires rewriting application logic, recompiling binaries, or renegotiating vendor contracts, you don't have crypto-agility.
In practice, this means abstracting cryptographic operations behind interfaces that don't hard-code RSA or ECC. It means key management infrastructure that can run classical and post-quantum algorithms side by side during the overlap period. It means testing your rollback procedures before you're in production with a broken migration.
Crypto-agility is the difference between treating this as a one-time project and treating it as an operational capability you'll need for the next twenty years.
Should We Prioritize Public-Facing Systems or Internal Ones First?
Prioritize based on data sensitivity and exposure time, not network topology.
Public-facing TLS endpoints are already exposed to harvest-now-decrypt-later attacks, that's traffic an adversary can capture today and decrypt later. But an internal database holding thirty-year retention data is just as exposed if it's using RSA-2048 for encryption at rest.
The systems that need to move first are the ones holding data with long confidentiality windows. Patient records, financial archives, merger documentation, source code for products you'll still be selling in 2040, anything where the sensitivity timeline runs past the point when you expect quantum computers to be cryptographically relevant.
Ease of implementation is a valid tiebreaker, but it shouldn't be the primary filter. Migrating your blog's TLS config before your customer database because the blog was easier doesn't reduce your actual risk.
What Happens if We Don't Finish by 2030?
You're running deprecated cryptography in systems that may need to pass audits, meet compliance frameworks, or interoperate with partners who've already migrated.
NIST IR 8547 sets 2030 as the deprecation date and 2035 as full removal from standards. Deprecation doesn't mean your RSA keys stop working on January 1, 2030. It means NIST is signaling that continued use carries increasing risk, and organizations relying on NIST guidance for compliance will start treating RSA-2048 as non-compliant.
If you're in a regulated industry, your auditors will ask why you're still running deprecated cryptography. If you're in a supply chain that requires FIPS compliance, your customers will ask the same question. The technical risk and the compliance risk move on different timelines, but both matter.
The organizations struggling in 2030 won't be the ones running the most complicated environments. They'll be the ones who spent 2026 waiting for a board mandate or a vendor to move first, even though the standards were already published and the guidance was already public.
Next Steps
NIST IR 8547 is the authoritative source for the transition timeline. CISA's PQC microsite has the joint migration playbook and vendor coordination guidance. Your cryptographic discovery project is the deliverable that turns those documents into a migration plan you can actually execute.
Start the inventory. Ask your vendors for roadmaps. Map your data retention windows against Mosca's theorem. You don't need permission to do any of that, and all of it shortens the timeline when you do get budget to move.
