Why PQC Migration Effort Varies So Much
Two organizations of similar size can face wildly different post-quantum migration timelines. The deciding factors are rarely the cryptography itself — ML-KEM and ML-DSA are drop-in replacements at the algorithm level — and almost always the surrounding system: how many places RSA or ECDSA is hardcoded rather than abstracted behind an interface, whether hardware security modules and third-party vendors already support PQC, and how much of the stack falls under a compliance regime with its own migration deadlines (such as CNSA 2.0 for U.S. national security systems).
What Drives the Score
| Factor | Why It Matters |
|---|---|
| Crypto-agility level | Hardcoded algorithm calls scattered through a codebase take far longer to change than a single abstraction layer |
| Direct classical crypto usage | More call sites means more code to find, test, and migrate |
| Language/stack diversity | Each language needs its own PQC library support and testing |
| HSM usage | Hardware with unclear or unsupported PQC roadmaps can block a migration entirely until replaced |
| Compliance obligations | Regulated environments add audit, documentation and sign-off overhead on top of the technical work |
| Team size | A larger dedicated security team parallelizes migration work that a small team must serialize |
| Data sensitivity | High-value data retained for years raises the urgency for "harvest now, decrypt later" risk, even if the technical lift is otherwise moderate |
Once you've scoped the rough effort tier, the next step is usually a concrete inventory: see the CBOM Generator to find exactly where classical algorithms are used in your code, or the PQ Readiness Checker for a broader organizational assessment.