Post-quantum cryptography (PQC) is cryptography designed to resist attacks from quantum computers, the category of threat that will render most of today’s asymmetric encryption obsolete once a cryptographically relevant quantum computer arrives. Consider a scenario familiar to many security leaders.
A CISO conducts a readiness review and asks the team to report on the organization’s PQC migration status. The responses are encouraging: the VPN vendor has PQC support on its roadmap for the coming year, the cloud provider has already implemented hybrid key exchange, and the certificate management platform has announced ML-DSA support in an upcoming release. The review concludes with a sense of progress.
Yet none of these developments address the organization’s internal certificate authority hierarchy, its code signing pipeline, or the internal applications still authenticating with RSA keys generated years ago without automated rotation. Vendor roadmap progress represents meaningful advancement on vendor-managed surfaces. It does not mean the organization’s own cryptographic infrastructure is any more secure.
This distinction defines the central gap in most PQC migration programs today. Gartner’s cybersecurity trends report for 2026, published in February 2026, identified PQC as one of six top cybersecurity trends for 2026, predicting advances in quantum computing will render today’s asymmetric cryptography unsafe by 2030.
NSM-10, OMB M-23-02, CNSA 2.0 v2.1, NIST IR 8547, and the newly signed Executive Order 14412 each place the responsibility for cryptographic inventory and migration on the organization itself, not on its technology suppliers. Organizations that are positioned to meet these deadlines are those that treat quantum readiness as an internal program priority first, and a vendor procurement consideration second.
This blog walks through what that internal program looks like in practice, where most organizations currently stand, and what concrete steps security teams can take to close the gap before deadlines arrive.
Why Are Vendor PQC Updates Not Enough
Most security teams have encountered some version of this reasoning: once vendors ship updates, organizations can migrate by applying patches. Cryptography lives in products. Products get updated. Problem solved.
It does not work that way. A vendor patch updates the cryptography inside that vendor’s product. It does not reach the custom applications your team built, the certificate infrastructure your PKI team manages, the HSMs in your data center, the internal APIs that authenticate across your environment, or the signed firmware artifacts that devices will continue to trust for the next ten years. That surface belongs to your organization. Its quantum vulnerability belongs to your organization.
Most IT organizations are not aware of what cryptography they are using, which applications depend on it, or where cryptographic dependencies sit in their environment. Developers are often unaware of library-level cryptographic dependencies, and hardware security modules are frequently overlooked entirely. If your team cannot answer those questions, vendor updates solve the easy part and leave the hard part untouched.
NIST’s National Cybersecurity Center of Excellence (NCCoE) addressed this directly in NIST SP 1800-38B, a preliminary draft published December 19, 2023, on cryptographic discovery. It documented that automated scanning tools alone cannot reliably surface the full cryptographic attack surface, because many cryptographic calls are embedded in application code, firmware, and embedded systems that tools do not reach. Manual code review and stakeholder interviews are necessary components of any credible inventory. Vendors cannot run that process inside your organization. Only you can.
Understanding why vendor updates fall short naturally leads to the question of what regulations actually require organizations to do themselves.
Understanding the Regulatory Requirements
The compliance obligations for internal action are explicit and layered across multiple frameworks. None of them delegates the inventory or migration work to vendors.
NSM-10 and OMB M-23-02
National Security Memorandum 10, signed by President Biden on May 4, 2022, directed all federal agencies to prioritize transitioning their cryptographic systems to quantum-resistant alternatives, mitigating as much quantum risk as feasible by 2035. OMB M-23-02, issued November 18, 2022, under NSM-10, required agencies to begin submitting annual inventories of quantum-vulnerable systems starting in May 2023 and continuing annually until 2035. Both directives place the inventory and migration obligation on the organization, not on technology vendors.
CNSA 2.0 v2.1
NSA’s Commercial National Security Algorithm Suite 2.0, updated to version 2.1 in December 2024 following NIST’s publication of the final FIPS standards, mandates ML-KEM-1024 (FIPS 203) for key establishment and ML-DSA-87 (FIPS 204) for digital signatures in National Security Systems. These are specific parameter sets at the highest NIST security level; lower parameter sets, such as ML-KEM-768, do not satisfy CNSA 2.0 for NSS use.
Note: SLH-DSA (FIPS 205) is a finalized NIST standard but is excluded from CNSA 2.0; the NSA has not included it in the approved suite for national security use. Any new NSS acquisition after January 1, 2027, must support ML-KEM-1024 and ML-DSA-87. That procurement deadline applies to decisions organizations make now, not to product roadmaps vendors choose to publish. Exclusive use of CNSA 2.0 algorithms is required by 2030 to 2033, depending on application type.
NIST IR 8547
Published as an Initial Public Draft on November 12, 2024, with a public comment period that closed in January 2025, NIST IR 8547 sets the planned deprecation timeline for quantum-vulnerable algorithms in federal systems. Algorithms providing approximately 112 bits of security, including RSA-2048 and ECC P-256, are targeted for deprecation after 2030, meaning they should no longer be used for new deployments from that point.
All quantum-vulnerable public-key algorithms, including larger key sizes such as RSA-3072 and P-384, are targeted for full disallowance after 2035. As of mid-2026, this document remains at initial public draft status; a revised draft is expected but has not yet been published. The 2030 and 2035 dates represent NIST’s considered technical guidance and are widely treated by compliance and procurement teams as the operative planning horizon regardless of the final version’s timing.
EO 14412
On June 22, 2026, President Trump signed Executive Order 14412, the most significant binding US PQC mandate to date. It requires all federal civilian agencies to transition high-value assets and high-impact systems to PQC for key establishment by December 31, 2030, and for digital signatures by December 31, 2031. Covered federal contractors face the same 2030 key establishment deadline via a forthcoming Federal Acquisition Regulation rule. National Security Systems remain under CNSA 2.0 separately. Every agency must designate a PQC migration lead within 30 days and maintain a cryptographic inventory.
The following is a snapshot of the key federal mandates and standards driving PQC migration, with organizational obligations, deadlines, and current enforcement status.
| Framework | Issued | Organizational Obligation | Deadline | Status |
|---|---|---|---|---|
| NSM-10 | May 4, 2022 | Inventory cryptographic systems; plan and execute PQC migration across all federal systems | 2035 | Active; not rescinded |
| OMB M-23-02 | November 18, 2022 | Annual inventory submissions of quantum-vulnerable systems; designate migration leads; funding assessments | Annual through 2035 | Active; not rescinded |
| CNSA 2.0 v2.1 | December 2024 | New NSS acquisitions must support ML-KEM-1024 and ML-DSA-87 (not just any PQC); exclusive use by 2030-2033 | January 1, 2027 (new acquisitions) | Binding for NSS |
| NIST IR 8547 (IPD) | November 12, 2024 | RSA and ECC are deprecated after 2030; all quantum-vulnerable algorithms are disallowed after 2035 in NIST standards | 2030 / 2035 | Initial Public Draft; comment period closed January 2025 |
| EO 14412 | June 22, 2026 | Federal civilian agencies and covered contractors must complete PQC for key establishment by Dec 31, 2030, and digital signatures by Dec 31, 2031 | 2030 / 2031 | Binding executive action (federal civilian agencies); contractor compliance pending FAR rulemaking |
None of these frameworks assigns the inventory or migration work to vendors. All of them require the organization to act directly.
With these regulatory obligations established, the question of who within an organization owns them becomes unavoidable.
Boards Own This Risk
Regulators increasingly treat cryptographic risk as a board-level matter, not a technical one. The Bank for International Settlements published BIS Papers No. 158, “Quantum-readiness for the financial system: a roadmap,” on July 7, 2025. The paper, which emphasizes that cryptographic inventory is a critical foundation for migration, recommends that financial institutions assign an executive sponsor to own the quantum-safe transition and cautions explicitly against treating the change as a simple algorithm replacement.
The BIS framing reflects broader regulatory direction: a migration spanning five to ten years, touching every system in the organization, and carrying binding deadlines, is a business transformation program.
Boards should be asking specific, answerable questions. What percentage of our systems protecting long-lived sensitive data still use quantum-vulnerable key exchange? What is our current migration velocity against the pace required to meet the 2030 deprecation target in NIST IR 8547 and the 2030 key establishment deadline in EO 14412? Have we built PQC readiness requirements into vendor selection criteria? Which HSMs in our environment need hardware replacement rather than a firmware update, and has that been budgeted?
None of these questions has an answer without an internal program. ISACA’s 2025 survey of technology professionals found that 62% were worried quantum computing would break current encryption, but only 5% of organizations had made it a high-priority near-term issue, and only 5% had a defined quantum computing strategy or roadmap in place. Those figures together describe the problem precisely: broad awareness of the risk has not translated into organized action.
The CISO’s role is to close that gap by translating quantum risk into board language, framing which specific data classes face Harvest Now, Decrypt Later (HNDL) exposure today, what their confidentiality lifetime is, and what a compliance failure under EO 14412 or CNSA 2.0 would cost.
The starting point for answering any of these board-level questions is the same place every credible migration framework begins: the cryptographic inventory.
The Inventory Is the Foundation
Every credible migration framework, from NSM-10 to NIST SP 1800-38B to the BIS quantum roadmap, starts in the same place: a comprehensive cryptographic inventory. You cannot prioritize what you have not mapped. You cannot estimate migration timelines without knowing the scope. You cannot engage vendors as an informed buyer without knowing which dependencies are vendor-managed and which are internal.
NIST SP 1800-38B, the NCCoE’s preliminary draft practice guide on cryptographic discovery, published December 19, 2023, outlines a blended discovery approach. It covers automated scanning of certificates, cryptographic libraries, and protocols across endpoints, applications, APIs, and embedded systems, combined with manual code review for dependencies that automated scanners cannot reliably reach.
The output is a Cryptographic Bill of Materials (CBOM): a structured record of every algorithm, key, certificate, and protocol in the environment, classified by system tier, risk level, and migration complexity.
Building that inventory reliably surfaces four findings that surprise most organizations the first time they do it.
- The actual number of cryptographic dependencies is almost always larger than any prior estimate, often by a significant margin.
- Many of these dependencies appear in systems not typically associated with cryptography, such as monitoring agents, logging pipelines, and backup infrastructure.
- HSM and hardware constraints bind the migration timeline in ways that were invisible before the inventory existed.
- The systems protecting the most sensitive long-lived data often have the most complex migration paths.
None of this is visible until the work is done. They only surface when your own teams map your own systems. With the inventory as its foundation, an effective internal program is built around three parallel workstreams running simultaneously.
What an Internal Program Looks Like
Starting a quantum readiness program does not require a complete migration plan from day one. It requires three parallel workstreams: an inventory program to build visibility, a governance structure to sustain momentum, and a prioritization framework to determine what moves first.
Inventory Program
Run automated discovery across your full environment, covering certificates, keys, algorithms, libraries, protocols, and embedded systems. Treat this as a continuous process rather than a one-time exercise. Cryptographic drift, where new systems deploy with classical algorithms after migration begins, is a real operational risk. The NCCoE’s SP 1800-38B methodology is a practical reference for tooling selection and scope definition.
Governance Structure
Assign an executive sponsor with budget authority, as both EO 14412 and the BIS roadmap explicitly recommend. Build a cross-functional steering committee including security architecture, application development, network operations, procurement, and legal.
Set quarterly milestones and report board-level progress using a small set of meaningful metrics: percentage of inventory complete, percentage of high-risk systems migrated, and days of buffer remaining against the nearest regulatory deadline, which is now the EO 14412 key establishment deadline of December 31, 2030, for federal civilian agencies and their contractors.
Prioritization Framework
Not everything migrates simultaneously. Systems protecting data with confidentiality lifetimes extending past 2030 are the highest priority for key exchange migration, because HNDL attacks are collecting that data today. Systems used for code signing and firmware distribution are the highest priority for authentication migration, because long-lived signed artifacts may remain trusted past the point where a cryptographically relevant quantum computer can forge signatures. This prioritization logic is consistent with both CNSA 2.0 guidance and NIST IR 8547.
Vendor engagement belongs inside this program rather than replacing it. Once the inventory exists, you know exactly which systems depend on vendor-supplied cryptography and which use internal code. For vendor-dependent systems, you can request PQC roadmaps, include quantum-safe requirements in new procurement criteria, and test hybrid configurations before any vendor finalizes a release timeline. That is informed buyer engagement, and it is very different from waiting for vendors to fix things without knowing what needs fixing.
Encryption Consulting exists precisely to help organizations build this internal capability before the 2030 window closes.
How Encryption Consulting Can Help
If you are wondering where and how to begin your post-quantum journey, Encryption Consulting is here to support you through our PQC Advisory Services. We will guide you through every step with clarity, confidence, and real-world expertise.
We begin with Cryptographic Discovery and Inventory, scanning your entire environment to identify certificates, keys, algorithms, and protocols across endpoints, applications, APIs, and infrastructure. This builds the CBOM baseline you need before any migration can begin.
From there, we conduct a PQC Assessment to evaluate your exposure to quantum threats, identify RSA and ECC-dependent systems, and deliver a prioritized report of vulnerable assets with risk severity ratings.
With that clarity, we develop a PQC Strategy and Roadmap, a phased migration plan aligned to your risk appetite, regulatory requirements, and long-term security goals, including cryptographic agility so your systems can adapt as standards evolve.
We then support Vendor Evaluation and Pilot Testing, helping you select the right tools, run proof-of-concept tests, and validate interoperability before any full-scale rollout.
Finally, we manage Full Implementation, deploying hybrid classical and quantum-safe models, rolling out PQC across your PKI and infrastructure, and setting up monitoring for long-term cryptographic health.
CBOM Secure
Encryption Consulting’s CBOM Secure tool plays a key role in helping organizations prepare. Instead of dealing with spreadsheets, manual OpenSSL outputs, or scattered configuration files, CBOM Secure gives a clear view of cryptographic usage across your environment. It shows which algorithms are in use, what needs to change for post-quantum security, and whether systems meet your security goals.
CBOM Secure automates cryptographic inventories, checks TLS configurations, validates algorithms, and aligns policies, so teams can move from discovery to action without guessing.
For the three internal surfaces this blog identified as beyond vendor reach, Encryption Consulting has purpose-built offerings for each.
For the three internal surfaces where commercial vendors typically fall short, Encryption Consulting offers purpose-built solutions that meet organizations where the gaps actually are.
- Code-signing pipeline: CodeSign Secure ships native support for ML-DSA and LMS, integrates with HSMs from Thales, Entrust, Utimaco, and Securosys, and connects to CI/CD pipelines including Jenkins, GitLab, and Azure DevOps. Private signing keys never leave the HSM boundary.
- Internal CA hierarchy: PKI-as-a-Service provides a fully managed, crypto-agile certificate authority with FIPS 140-3 Level 3 HSM-protected root keys, hybrid certificate issuance, and automated enrollment via SCEP, EST, ACME, and WSTEP. It is built to support PQC migration without requiring a CA rebuild from scratch.
- HSM hardware replacement: HSM-as-a-Service manages the transition to PQC-capable hardware across on-premises, cloud, and hybrid environments. It natively supports ML-KEM and ML-DSA, handles deployment and key lifecycle management, and removes the procurement and operational overhead of running HSM infrastructure internally.
Conclusion
The belief that vendors will handle post-quantum migration is understandable. Much of enterprise cryptography is embedded in third-party systems, and vendor updates will address a real portion of the exposure. But vendor progress does not touch internal certificate authorities, HSMs, code signing infrastructure, or the applications your organization built and owns. That portion of the migration belongs entirely to you.
The regulatory landscape has crystallized through 2026. NSM-10 and OMB M-23-02 have required federal agencies to inventory and plan since 2022. CNSA 2.0 v2.1 sets binding algorithm and parameter requirements for new NSS acquisitions starting January 2027. NIST IR 8547 establishes 2030 as the deprecation target and 2035 as the disallowance date for quantum-vulnerable algorithms.
And EO 14412, signed June 22, 2026, makes PQC migration for key establishment a binding legal obligation for all federal civilian agencies and their covered contractors by December 31, 2030. Boards and CISOs that treat PQC as a vendor procurement matter rather than an internal program risk will arrive at that deadline without the inventory, governance, or migration progress needed to demonstrate compliance.
Quantum readiness is an inside job. Organizations that act early will migrate on their terms. Organizations that wait will migrate under pressure.
