You've probably heard about the quantum threat. Maybe you've even started planning. But if you think migrating to post-quantum cryptography (PQC) is just a cryptographic upgrade, you're in for an expensive lesson.
These myths persist because they're comfortable. They let you treat PQC as another infrastructure refresh, something you can scope, budget, and hand off to your crypto team. The reality is messier. Experts who've led these migrations say the work spans governance, vendor contracts, regulatory reporting, and organizational literacy in ways most enterprises don't discover until they're already committed.
Let's dismantle the myths that are quietly sabotaging PQC readiness programs.
Myth 1: This Is Mostly a Cryptography Project
Reality: In large-scale PQC migration programs, cryptographic work represents roughly 25% of the total task count.
Marin Ivezic, who has led PQC migration programs with more than 120,000 tasks, found that only 30,000 involved cryptography directly. The remaining 90,000 covered inventory management, vendor coordination, regulatory reporting, team upskilling, and governance workflows.
You're not just rotating keys. You're discovering every place cryptography lives in your environment, renegotiating vendor contracts, rewriting procurement standards, training teams on algorithm agility, and documenting decisions for auditors who don't yet have PQC assessment frameworks.
If you've scoped this as a crypto team project, multiply your timeline by three and your budget by four. Then add governance overhead.
Myth 2: Cryptographic Discovery Is a Phase You Complete
Reality: Cryptographic discovery never finishes. You need a defensible starting point, not perfect visibility.
Your CMDB doesn't know about the TLS library compiled into that legacy application from 2014. It doesn't track the cryptographic dependencies in third-party SaaS tools your marketing team adopted last quarter. And it definitely doesn't flag the hardware security modules running outdated firmware.
The question isn't "When will we finish discovery?" It's "What constitutes a defensible scope for phase one?"
Start with systems that handle regulated data, authenticate critical transactions, or connect to external parties. Document your discovery methodology to demonstrate to auditors that you applied a risk-based approach. Then build continuous discovery into your configuration management process, because every new integration or vendor adds cryptographic dependencies you'll need to inventory.
Treating discovery as a project phase guarantees you'll miss the systems that matter most when quantum-capable adversaries arrive.
Myth 3: Vendors Will Handle Their Own PQC Readiness
Reality: Vendor PQC readiness becomes your problem the moment you sign a multi-year contract with a vendor who hasn't started planning.
Your SaaS identity provider, your payment processor, your cloud infrastructure provider, they all use cryptography that will need migration. If they're not ready when you are, you're stuck choosing between delaying your own timeline or accepting quantum-vulnerable dependencies in critical paths.
This isn't a checkbox exercise. "Are you PQC-ready?" gets you a marketing answer. You need to integrate specific questions into your vendor risk assessments: What's their cryptographic inventory process? Who owns their PQC roadmap? What's their timeline for hybrid implementations? How will they handle algorithm updates when NIST revises standards?
Then build PQC readiness requirements into new procurement contracts now, before you're trying to renegotiate terms with a vendor who knows you're locked in. Your vendor management team should track PQC readiness as a third-party risk metric alongside security certifications and financial stability.
Treating vendor PQC as someone else's problem just outsources your quantum vulnerability.
Myth 4: You Can Start PQC Once You Finish Your Current Security Projects
Reality: Competing priorities are exactly why enterprises are falling behind on PQC preparation.
Gregory Skulmoski noted that enterprises are slow to migrate due to competing priorities like AI governance and zero trust implementations. There's always a near-term crisis. There's always a project with more visible ROI. But quantum-capable systems aren't waiting for your roadmap to clear.
You don't need to pause everything else. You need to integrate PQC readiness into work you're already doing. When you're updating authentication systems for zero trust, evaluate PQC-ready options. When you're reviewing AI model security, include cryptographic dependencies in your risk assessment. When you're negotiating cloud contracts, add PQC timeline requirements.
The organizations that succeed won't be the ones who dedicate 100% of their security budget to PQC. They'll be the ones who embed PQC considerations into every infrastructure decision starting in 2024, not 2027.
Waiting for the perfect moment to start means you're starting too late.
Myth 5: Your CISO Can Own This Program
Reality: PQC migration requires governance structures that don't report to IT.
Who approves a vendor contract renegotiation that adds cost but no visible functionality? Who allocates budget for cryptographic inventory tooling that competes with your SOC modernization project? Who decides which business units migrate first when everyone claims they're too critical to risk?
These aren't CISO decisions. They're enterprise risk management decisions that require executive sponsorship, cross-functional steering committees, and governance frameworks that treat PQC as business resilience, not just IT hygiene.
Your CISO should lead the technical program. But the organizational program needs ownership from someone who can say no to competing priorities, reallocate resources across business units, and make risk acceptance decisions that affect regulatory reporting. In most organizations, that's your Chief Risk Officer or your COO, not your IT leadership.
If your PQC program reports through IT, you're setting up a governance failure that will surface when you need executive decisions and discover no one has authority to make them.
What to Do Instead
Stop treating PQC as a future cryptography project. Start treating it as an ongoing governance program that touches every part of your enterprise.
Build cryptographic discovery into your configuration management process now. Add PQC readiness clauses to your standard vendor contracts today. Identify the executive sponsor who can make cross-functional resource decisions. Create a steering committee that includes legal, procurement, risk management, and business unit leadership, not just IT and security.
And document your decision framework, because when auditors start asking about your PQC readiness in 18 months, "we're working on it" won't satisfy anyone. You need to demonstrate that you understood the scope, allocated appropriate governance, and made risk-informed decisions about priorities.
The quantum threat is technical. But your response needs to be organizational. Recognize that now, or discover it the expensive way.
