Most organizations starting a post-quantum cryptography (PQC) migration do not stall on algorithms. They stall on PQC governance: who owns the program, who has authority to act, and who is accountable for results. Security teams wait for IT to act. IT waits for budget clarity. Legal watches from the sidelines. In many organizations, the challenge is not a lack of expertise but a lack of clearly assigned ownership, with responsibility split across security, infrastructure, application teams, and executive leadership.
The result is that progress stalls because no one is clearly responsible for driving the program forward.
Post-quantum migration is a cryptographic infrastructure problem. It requires inventorying every system that depends on RSA, Elliptic Curve Diffie-Hellman (ECDH), or Elliptic Curve Digital Signature Algorithm (ECDSA), assessing what gets replaced first, sequencing migrations to avoid operational disruption, and validating the results against a set of standards that are now finalized.
That work lives in the same domain the security team already occupies: public key infrastructure (PKI) operations, key management, certificate lifecycle, vendor security assessments, and regulatory compliance. Assigning it elsewhere does not make the program run better. It moves the problem to someone with less context.
The National Institute of Standards and Technology (NIST), the Cybersecurity and Infrastructure Security Agency (CISA), and the National Security Agency (NSA) have all issued guidance that treats PQC migration as a cybersecurity risk management and technology modernization challenge, placing it squarely within existing security governance processes. The regulatory signal is consistent. Understanding why that alignment matters, and how to structure a program that delivers against it, is what this blog covers.
Where PQC Governance Sits in Regulatory Frameworks
When NIST published Federal Information Processing Standard (FIPS) 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024, it transformed PQC migration from a research and planning exercise into an implementation challenge with growing regulatory and procurement implications. The Quantum Computing Cybersecurity Preparedness Act, signed into law on December 21, 2022, requires the Office of Management and Budget (OMB) to direct federal agencies to establish and maintain inventories of IT systems vulnerable to quantum decryption, with agency reporting to OMB, CISA, and the National Cyber Director.
NIST IR 8547, currently published as an Initial Public Draft and released in November 2024, proposes deprecating quantum-vulnerable public-key algorithms and parameter sets providing lower security strengths after 2030, with RSA-based and elliptic-curve-based public-key cryptography targeted for disallowance after 2035. None of these documents treats quantum risk as something separate from cybersecurity risk management.
NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), issued in September 2022 and updated through December 2024, is the most operationally specific of the major guidance documents. From January 1, 2027, all new acquisitions for National Security Systems (NSS) must support CNSA 2.0-compliant algorithms. The required suite includes ML-KEM-1024 (FIPS 203) for key establishment, ML-DSA-87 (FIPS 204) for digital signatures, LMS or XMSS per NIST SP 800-208 for software and firmware signing, and AES-256 for symmetric encryption.
Only the highest parameter sets are approved for NSS use. Although CNSA 2.0 applies specifically to NSS, many organizations use its timelines and algorithm selections as a reference point when planning long-term PQC migration strategies.
OMB Memorandum M-23-02, issued on November 18, 2022, requires each federal agency to inventory its quantum-vulnerable cryptographic systems and report annually to the Office of the National Cyber Director and CISA. CISA, NIST, and NSA guidance recommend establishing dedicated quantum-readiness project teams and conducting cryptographic discovery and inventory activities as foundational migration steps.
These directives are generally implemented through existing cybersecurity and risk management governance structures rather than as standalone IT modernization initiatives. The governance model for PQC migration should follow that same chain of accountability.
The Program Structure That Works
Effective PQC migration programs share a consistent structure: one accountable executive, a cross-functional steering committee, a dedicated program office, and specialized execution teams. In most enterprises, the accountable executive role belongs to the CISO or a direct report with delegated authority.
In most enterprises, the CISO is the natural fit because the adjacent domains already sit there: PKI operations, key and certificate management, vendor security requirements, cryptographic policy, and regulatory compliance.
Assigning these responsibilities to the CTO or CIO is not wrong if the organization structures it that way, but dividing ownership across all three simultaneously, without naming one of them accountable, means shared accountability for delay. The steering committee gives cross-functional stakeholders a voice in major decisions without diffusing execution authority. It should include the CIO, CTO, General Counsel, a CFO delegate, and business unit heads with significant cryptographic dependencies.
This committee approves budget allocation, scope, and major vendor commitments. It does not manage technical sequencing or library selection. When every migration decision requires committee sign-off, the program moves at the pace of the most reluctant participant.
The program office coordinates the actual work. At a large enterprise scale, organizations often establish dedicated program management resources rather than treating PQC migration as a part-time responsibility. The program office owns the integrated master schedule, dependency mapping, status reporting to the board, and vendor coordination. A program lead who is simultaneously managing security operations or vulnerability remediation will not have the time the program requires.
Below the program office, four execution functions do the technical work. A cryptographic engineering team owns algorithm selection and hybrid deployment architecture for FIPS 203, 204, and 205 implementations. Federated migration teams within business units handle system-level migrations against standards set by the engineering team. The procurement team manages third-party readiness assessments. Internal audit maintains an independent reporting line to the audit committee.
What the Program Lead Needs
Naming an accountable executive is the first step. Giving that executive what they need to succeed is where most organizations fall short. Three requirements are consistently underprovided.
First, a board-level mandate that authorizes the program explicitly and ties it to specific regulatory deadlines: the CNSA 2.0 January 2027 procurement gate for NSS-adjacent organizations, the NIST IR 8547 draft deprecation timeline targeting 2030, and the OMB M-23-02 annual reporting obligations.
Second, a ring-fenced budget with both capital and operational components. Some organizations may need to upgrade or replace Hardware Security Modules (HSMs) if existing platforms cannot support post-quantum algorithms or the larger keys and signatures associated with them. PKI modernization, root hierarchy changes, and extended periods of hybrid operation can also require significant investment that may not fit within a routine security operations budget without creating competing priorities.
Third, real cross-functional authority backed by the steering committee charter: the ability to get a change window from infrastructure, a contract modification from procurement, or an application freeze for migration validation, without revisiting the mandate each time. Without this authority, every dependency becomes a negotiation.
Common Failure Patterns
Treating the migration as a vendor problem is the most common and most expensive mistake. No vendor has complete visibility into your cryptographic estate. No vendor can sequence your migrations against your operational constraints. Vendors can provide products, services, and migration support, but they cannot replace an organization’s responsibility for understanding its own cryptographic dependencies, business priorities, and migration sequencing.
Organizations that wait for vendors to make them quantum-safe will accumulate cryptographic debt while their regulatory exposure grows.
Underfunding the program while approving the mandate produces a program that completes its discovery phase and then stalls. Inventory generates a list of everything that needs to change. Executing those changes requires budget and engineering capacity that discovery did not consume. A program funded through inventory but not through remediation is a risk assessment with no path to risk reduction.
Governance by committee, where the CIO, CTO, and CISO share responsibility without clear primary ownership, is the structural version of the same problem. Each executive has competing priorities. When a decision requires all three to align, it gets deferred. When a budget request requires all three to sponsor it, one of them declines. The program sits in a meeting while deadlines approach. In practice, when everyone is responsible, no one is truly accountable for keeping the program on track.
How Encryption Consulting Can Help
Organizations that begin a PQC migration quickly discover that the challenge extends beyond algorithm selection. Success depends on understanding where cryptography exists, assessing the impact of quantum-vulnerable systems, coordinating with vendors, modernizing PKI infrastructure, and building the operational capabilities required to support future cryptographic transitions.
PQC Advisory Service
Encryption Consulting supports organizations throughout this journey with end-to-end PQC migration services covering discovery, assessment, planning, validation, and deployment. Our PQC Advisory Services help organizations identify certificates, keys, algorithms, protocols, and cryptographic dependencies across cloud environments, applications, infrastructure, HSMs, source code repositories, containers, APIs, and CI/CD pipelines.
Using this visibility, we assess exposure to quantum-vulnerable cryptography, identify high-priority remediation areas, and develop risk-based migration roadmaps aligned with NIST standards, regulatory requirements, and business objectives.
Beyond planning, Encryption Consulting assists with vendor readiness assessments, proof-of-concept validation, interoperability testing, hybrid cryptography deployments, crypto-agile PKI architecture design, and enterprise-scale implementation programs. This structured approach enables organizations to move from fragmented cryptographic visibility to a governed, measurable, and sustainable PQC migration program.
CBOM Secure
A successful post-quantum transition begins with visibility. Encryption Consulting’s CBOM Secure provides continuous discovery and inventory of cryptographic assets across enterprise infrastructure, cloud environments, applications, and cryptographic services.
Unlike a point-in-time inventory, CBOM Secure continuously generates and consumes Cryptographic Bills of Materials (CBOMs) while tracking certificates, keys, algorithms, and cryptographic dependencies across the environment. It provides visibility into what is deployed, where it is running, and how cryptographic dependencies evolve over time.
The platform also supports policy-driven governance by validating cryptographic configurations against organizational standards, identifying deviations, and helping organizations address security, operational, and compliance risks.
For PQC readiness, CBOM Secure helps identify systems that rely on quantum-vulnerable algorithms, prioritize remediation activities, and establish the continuous cryptographic governance required to achieve long-term crypto-agility.
If your organization is working to establish a PQC governance model, assess cryptographic exposure, or build a migration roadmap against NIST and CNSA 2.0 timelines, reach out to us at [email protected].
Conclusion
Post-quantum migration is fundamentally a cybersecurity governance challenge. Regulatory frameworks consistently treat it as part of broader cyber risk management, even though individual organizations may assign ownership differently. The technical dependencies support that view, as do the existing ownership structures for adjacent domains such as PKI, key management, cryptographic policy, and compliance. For many enterprises, the CISO is the executive best positioned to provide that accountability.
What requires deliberate design is giving that executive a board mandate, a dedicated budget with capital and operating components, cross-functional authority through the steering committee, and the cryptographic engineering resources needed to execute the technical work. Programs that get these elements right are far better positioned to deliver successful outcomes.
With the NIST IR 8547 deprecation timeline targeting 2030 and the CNSA 2.0 procurement gate arriving in January 2027, delay is not a neutral outcome. Every month spent on the governance question is a month not spent on cryptographic inventory, and inventory is where every migration starts.
