Marin Ivezic
The question arrives in the first month of every post-quantum cryptography (PQC) migration program: who owns this? By then the deadlines are usually clear enough. Financial entities in Europe have been subject to DORA since 17 January 2025, and the regulation requires them to keep cryptographic controls current against developments in cryptanalysis. Australia’s Signals Directorate has set 2030 for the transition away from current asymmetric algorithms in the systems its Information Security Manual governs. What most organizations do not have, six weeks in, is a name attached to the program.
What happens instead is familiar. The CIO, the CTO, and the CISO each hold a legitimate piece of the work, so responsibility gets shared. Shared responsibility reads well in a steering pack. It produces very little, because every decision then needs consensus among peers with competing quarterly targets, and the program moves at the pace of the most reluctant participant. Half a year later the organization has a governance debate rather than a cryptographic inventory.
This post sets out the ownership decision as we teach it: where regulators have already placed PQC, four tests for identifying the one accountable executive, the mandate and resources that role needs to function, how a board oversees the work without cryptographic expertise, and the four ways ownership breaks in practice.
Where Regulators Have Already Placed PQC
Before designing anything, look at where the obligation already sits. Across every major jurisdiction, quantum-driven cryptographic risk is treated as a subset of cybersecurity and ICT risk, not as a new governance domain.
In the United States, the Quantum Computing Cybersecurity Preparedness Act of 2022 is a cybersecurity statute by title and content, directing federal agencies to inventory cryptographic systems and prioritize migration. The joint CISA–NSA quantum-readiness guidance assigns cryptographic discovery and roadmap development to security leadership. NIST’s own migration and crypto-agility work frames the ability to swap cryptographic algorithms as an enterprise cybersecurity capability, managed alongside every other control.
In the European Union, DORA locates cryptographic controls inside the ICT risk management framework that financial entities must maintain, and the supporting technical standards require firms to monitor cryptanalytic developments and update their cryptographic technology in response. Singapore’s Monetary Authority places quantum-related cryptographic risk inside technology risk management. Australia handles the same question through the Security of Critical Infrastructure framework administered by the Department of Home Affairs, together with ASD guidance, rather than through a single universal cutoff.
No regulator has created a separate quantum risk category with its own reporting line. That has a practical consequence for you. If you build a bespoke PQC governance structure outside the cybersecurity risk framework, your auditors, your regulator, and your insurance underwriters will still look for the evidence inside the cybersecurity risk register, and the structure will have to be unwound and re-mapped. Aligning at the start costs nothing. Realigning in year two costs a quarter.
Four Tests for the Accountable Executive
We teach the ownership question as a test rather than an assertion, because the right answer depends on how your organization is actually built. Apply four questions to each candidate.
Does this executive already answer for cryptographic risk? Someone in the organization already reports on key management weaknesses, certificate expiries, and deprecated protocol use. PQC migration is a continuation of that reporting, at larger scale and against a deadline.
Does this executive already operate the cryptographic infrastructure? PKI, the public key infrastructure of certificate authorities, certificates, and keys that lets systems authenticate one another, sits somewhere. So do the hardware security modules, the tamper-resistant devices that generate and hold private keys. Whoever runs that estate today will run its replacement.
Can this executive hold a capital budget? Migration is not a licensing renewal. It buys hardware, replaces infrastructure, and funds engineering work across years. An owner without a capital line is a coordinator.
Can this executive convene the functions that hold the systems? Application development, network engineering, cloud platform teams, procurement, legal, and in many organizations operational technology all hold cryptography that has to change. The owner needs the standing to call those teams into a decision without renegotiating the program’s mandate each time.
In most enterprises, the one person who passes all four is the CISO or a direct report: a deputy CISO, the head of security architecture, or the head of security risk. In organizations where platform engineering is genuinely consolidated under a CTO, a CTO-sponsored program with the CISO as delivery lead works well. Titles vary across industries and jurisdictions. Accountability cannot: exactly one person answers to the board for the outcome, controls the program budget, and holds the convening authority.
Where a candidate fails test three or test four, you’ve found the gap to close. Grant the budget line and the convening authority. Do not move the accountability to whoever happens to have them already.
The Second-Line Objection
One objection comes up reliably, usually from colleagues with strong risk governance backgrounds. Under the Three Lines of Defense model, which separates the business that owns risk from the functions that oversee it and from internal audit, the CISO is often positioned in the second line. Putting an oversight function in charge of a multi-year delivery program looks like a loss of independence.
The model is sound. The objection assumes a single CISO archetype that doesn’t exist in practice. Some CISOs sit in the second line under a chief risk officer, with no operational teams at all. Others sit in the first line under the CIO and run security engineering directly. Some report to the board. And in many organizations the reporting line understates the real authority, because the CISO holds standing access to a board committee regardless of who signs the appraisal.
The test is functional rather than structural. A CISO who runs PKI operations, manages the HSM estate, and owns certificate lifecycle management is already first line for cryptographic infrastructure. Asking that CISO to lead the migration of the same infrastructure extends an operational responsibility they already carry.
Where independence remains a genuine concern, the answer is the third line, not a split in the second. Internal audit keeps its reporting line to the audit committee and independently verifies what the program claims about inventory coverage, migration status, and residual risk. That preserves the control without fragmenting accountability.
There is a decade of precedent for expanding the mandate rather than inventing a parallel structure. When enterprises moved to public cloud, misconfiguration and data exposure became the dominant loss driver. The response was not a Chief Cloud Risk Officer sitting outside security. It was a wider CISO mandate, a seat in platform decisions, and cloud security engineering teams built inside the security organization. Operational technology followed the same route. So did secure software delivery, and so did the technical side of GDPR compliance. In each case the mandate, the budget, and the specialist headcount grew to match a new domain, because standing up a second security governance function creates more coordination cost than it removes. PQC is the same pattern with a fixed deadline attached.
What Ownership Needs to Be Real
Naming an owner is the start. Four things determine whether the name means anything.
A board mandate on the record
The accountable executive needs explicit board or risk committee authorization to run migration as a multi-year transformation, with a standing reporting slot. Without it, the program is one budget cycle away from being deferred by whatever incident happens next. Write the mandate against dated obligations that apply to your organization, so the board is approving a compliance trajectory rather than a technology preference.
A budget structured for the work
Most cybersecurity spending is operating expenditure: licenses, monitoring, staff, patch cycles. Migration is heavier on capital. It replaces hardware security modules, rebuilds public key infrastructure, refactors applications around larger keys and signatures, and funds a period of parallel hybrid operation where both classical and post-quantum algorithms run together. Running that from the security operations line does not work, and the failure looks like a discovery phase that never ends. Ring-fence the budget, separate the capital and operating components, and have the steering committee approve the split.
Convening authority that holds
When the program needs a change window, a contract amendment, or an application freeze for migration testing, the owner has to obtain it without relitigating the mandate. This authority flows through the steering committee rather than by unilateral command, but it has to be real. A useful boundary to write down: the steering committee approves scope, funding allocation, risk acceptance, and vendor strategy. The accountable executive decides technical strategy, sequencing, and operational mandates inside that envelope. If the committee is voting on which TLS termination points migrate first, you have consensus governance, and consensus governance doesn’t finish multi-year programs.
Specialist cryptographic engineering
The three finalized NIST standards are ML-KEM (formerly CRYSTALS-Kyber) for key establishment, published as FIPS 203, ML-DSA (formerly CRYSTALS-Dilithium) for digital signatures, published as FIPS 204, and SLH-DSA (formerly SPHINCS+), the hash-based signature scheme published as FIPS 205, all finalized in August 2024. FN-DSA (formerly FALCON) remains in the standardization pipeline. Working with these requires people who understand lattice-based constructions, hybrid key establishment, certificate lifecycle at scale, and the performance consequences of larger keys and signatures on constrained links and embedded devices. That’s a specialist skill set, and it is not a SOC analyst reassigned for six months.
The division is the same one that already applies elsewhere in the function. A CISO running an operational technology security program does not configure controllers. A CISO running a cloud security program does not write policy-as-code. The executive governs, and specialists execute. A skills gap is closed by hiring, contracting, and training, not by moving governance to another office.
How a Board Governs a Program It Cannot Evaluate
Directors are not cryptographers, and they don’t need to be. They oversee credit models and operational resilience the same way: by setting appetite, monitoring a small number of indicators against tolerances, and holding one executive to delivery.
Build the reporting as a cascade with three levels. At each level the same underlying question is asked at a different resolution.
| Level | What they see | Example indicator |
|---|---|---|
| Board or risk committee | Four to six aggregate indicators, quarterly, against agreed tolerances | Share of Tier 1 systems operating in hybrid or post-quantum mode |
| Steering committee and accountable executive | The same measures decomposed by business unit, criticality tier, and phase, plus program health | Tier 1 migration by division, budget burn against plan, blocked dependencies, hiring against the staffing model |
| Program office and execution teams | Per-system technical and delivery detail | Library upgrade completion, certificate rotation progress, HSM deployment dates, regression results |
A key risk indicator, or KRI, is simply a measure reported against a threshold the board has agreed in advance. Keep leading and lagging indicators in the board set. Share of the cryptographic estate discovered is a leading indicator, and it tells directors whether the program is building the visibility everything else depends on. Share of Tier 1 systems migrated is lagging, and it tells them whether the work is happening.
Pair those with two or three risk appetite statements written in the language the board already uses. Something of the form “no data with a confidentiality requirement beyond ten years transits infrastructure protected by classical asymmetric cryptography alone after [date]” gives directors a threshold they can hold you to without evaluating a key exchange.
When an indicator breaches tolerance, the board does not diagnose the cryptographic cause. It asks the accountable executive what happened, what the recovery plan is, and whether the plan needs more money or more people. One practical constraint: develop these measures jointly with the enterprise risk function and fold them into the risk dashboard the board already reads. A parallel quantum reporting structure that directors have to learn separately gets skimmed.
Four Ways Ownership Breaks
Delegating it to vendors. Suppliers migrate their own products on their own roadmaps. They have no view of your cryptographic estate, no visibility into the custom applications and internal services that hold most of your keys, and no incentive to match your deadline. Vendor readiness is a workstream inside the program, managed through procurement with contractual requirements and a commitment register. It is not a substitute for the program.
Funding it from operations. A capital transformation charged against a monitoring and tooling budget stalls at discovery, because discovery is the only phase cheap enough to fund that way.
Splitting it three ways. When the CIO, CTO, and CISO all share responsibility, none of them can be held to a date. Peers with different objectives negotiate rather than decide.
Ruling out the CISO without naming a successor. The argument surfaces regularly: cryptographic hygiene across the industry is poor, security leadership presided over that, so security leadership should not lead the rebuild. Applied consistently, that reasoning disqualifies every function from fixing anything it currently manages. It also leaves a vacuum, because the alternatives on offer rarely come with a name. The CTO owns platforms rather than security risk. The CIO owns delivery and operations. A newly invented cryptographic officer role has no place in standard governance frameworks, no relationship with the regulators issuing the mandates, and no budget history. The board hears that the problem is bigger than cyber, agrees, and then asks who. If nobody answers, the organization spends a year on governance design instead of discovery.
When you hear the advice, ask the specific follow-up: which person, in which role, with what mandate, what budget line, and what reporting cadence. A vague answer is the diagnosis.
The First Thirty Days
These steps overlap. Do not gate the later ones on the earlier ones.
- Name the executive and record it. Brief the board or risk committee on the deadlines that bind your sector and on harvest-now-decrypt-later exposure, the risk that encrypted traffic captured today is stored and decrypted once a capable quantum computer exists. Get the appointment into the minutes.
- Approve seed funding and a budget structure. The structure matters as much as the number in month one, because it determines whether capital items can be raised at all.
- Stand up the steering committee. Named members from IT, engineering, data, legal, finance, and operations. Write the decision boundary between the committee and the executive on one page before the first meeting.
- Start cryptographic discovery now. Discovery does not depend on the committee’s first meeting or on your first cryptographic engineering hire. It produces the inventory of algorithms, keys, certificates, and protocol dependencies that makes every later decision cheaper, so early data compounds.
- Begin recruiting or contracting specialist capability. Cryptographic engineering hiring runs on a long lead time in every market we see. Start it in parallel with everything above.
Where to Take This Next
The ownership decision is the first of a sequence, and the rest of the program depends on getting it recorded rather than debated. Once the executive is named, the work moves to inventory, risk-based prioritization, and sequencing.
Quantum Academy’s post-quantum migration training covers that sequence for security leaders and the teams delivering the work, including the governance structures, board reporting, and vendor management described here. You can review the programs and enrollment options at quantumacademy.com/.
The open migration methodology the training follows is published at pqcframework.org. For deeper technical background on the standards, the algorithms, and the migration engineering behind them, PostQuantum.com carries the long-form analysis.