Post-quantum cryptography (PQC) governance is the organizational framework, covering risk tolerance statements, Key Risk Indicators (KRIs), and escalation structures, that helps enterprises manage and measure their migration from quantum-vulnerable algorithms to NIST-approved quantum-resistant standards such as ML-KEM, ML-DSA, and SLH-DSA.
Most organizations have accepted that PQC migration needs to happen. Many have a roadmap in a slide deck. Very few have built the governance infrastructure to actually run it: the risk tolerance statements that tell a program when it is on track, the KRIs that turn technical progress into something a board can act on, and the escalation triggers that catch problems before they become missed deadlines. That gap is not a technology problem. It is a governance problem. Without structured governance, PQC programs stall, lose momentum, or get cut mid-cycle when a louder priority competes for the same budget.
In this blog, we will walk through how to write a board-level risk tolerance statement, how to build a KRI hierarchy from the boardroom to the operations floor, and what each metric actually needs to measure to drive real decisions.
Why Quantum Risk Needs Its Own Governance Framework
Most enterprise risk frameworks were not built with PQC migration in mind. Trying to fold quantum risk into existing operational risk categories tends to produce something that looks like governance but does not work like governance.
Quantum risk has three properties that set it apart from most other risks a security team deals with.
1. The threat timeline is fixed
NIST approved FIPS 203, FIPS 204, and FIPS 205 in August 2024. NSA’s CNSA 2.0 advisory, originally published September 2022 with updated FAQs through 2024 and 2025, sets quantum-resistant algorithm requirements for National Security Systems. At the policy level, National Security Memorandum 10 (NSM-10) established 2035 as the government-wide quantum migration target. Executive Order 14306 (June 6, 2025) directed CISA, in consultation with NSA, to publish and regularly update a list of product categories where PQC-capable products are widely available, to guide federal procurement decisions.
NIST IR 8547, published as an initial public draft in November 2024 with a final version still pending, makes clear that quantum-vulnerable algorithms will be phased out in a structured transition. The draft outlines deprecation of lower-security classical algorithms such as RSA-2048 and ECC P-256 by 2030, with all quantum-vulnerable public-key algorithms disallowed in NIST standards by 2035. High-risk systems are expected to transition well ahead of that date.
For organizations in the National Security Systems (NSS) supply chain, CNSA 2.0 (v2.1, December 2024) sets deadlines that vary by system type. The most immediate: any new NSS acquisition after January 1, 2027 must support CNSA 2.0 algorithms, unless a documented exception applies. This is a procurement gate, and the existing systems are not immediately banned. Separate “support and prefer” and “exclusive use” deadlines apply by system category through 2030 and 2033 respectively, with full NSS quantum resistance targeted by 2035 under NSM-10. The broader federal civilian deadline, supported by NIST IR 8547, targets deprecation of quantum-vulnerable algorithms by 2030 and full disallowance by 2035.
On top of all of this, the Harvest Now, Decrypt Later (HNDL) threat means adversaries are already collecting encrypted data today so they can decrypt it once quantum computing gets there. Organizations that are not yet migrating are not simply waiting for a future deadline. They are already exposed.
2. Migration timelines are long and cannot be compressed
Large enterprise PQC programs realistically take years from start to finish. An organization that has not started its cryptographic inventory and migration planning is already working against the clock. Any governance approach that treats quantum risk as something to deal with later is already behind.
3. You Cannot Manage What You Cannot See
A ransomware attack triggers alerts. A data breach gets logged. Quantum exposure generates nothing. No system flags a session as harvested for future decryption. Without deliberate measurement, an organization can carry significant quantum risk and have no idea.
These three properties are exactly why quantum risk needs its own governance structures rather than being absorbed into general cybersecurity reporting. Now that we understand what makes this risk different, the logical starting point is defining what level of that risk your organization is willing to accept.
Defining Your Quantum Risk Tolerance for PQC Governance
A risk tolerance statement for quantum security works at two levels. The board needs to set both.
Strategic level: The strategic statement defines the organization’s overall position. A solid example looks like this: the organization will complete migration of all systems protecting data with confidentiality requirements beyond ten years before the earliest credible estimates for a cryptographically relevant quantum computer, and will achieve compliance with all applicable PQC regulatory deadlines with at least a twelve-month buffer.
That statement works because it answers the questions a board actually cares about. Are we going to be compliant? Are we protecting our most sensitive data? What margin do we have? A board member does not need to understand lattice cryptography to evaluate whether the answer is yes or no.
Operational level: The operational level turns that strategic position into specific tolerances for each risk area during the migration. These tolerances give the migration program a measurable standard and give the board a way to track progress without getting buried in technical detail. The thresholds in the table below are illustrative internal governance targets, not external compliance requirements. They should be calibrated to your organization’s sector, regulatory environment, and data profile.
| Risk Dimension | Illustrative Tolerance | Why It Matters |
|---|---|---|
| HNDL exposure | No more than 20% of data with 10-plus-year secrecy requirements protected by quantum-vulnerable algorithms by end of 2027. Target 0% by end of 2029. | Sets a clear priority order and a measurable board-trackable target. |
| TNFL exposure | All production code-signing keys and Certificate Authority (CA) signing keys migrated to PQC by end of 2027, with no carve-outs permitted. TNFL, or Threat-Now-Forge-Later, is the risk that a quantum-capable adversary forges digital signatures in real time, compromising code integrity, certificates, and authentication. | Signature compromise enables real-time exploitation, not just retrospective decryption. A tighter timeline makes sense here. |
| Regulatory compliance | Achieve compliance with all PQC regulatory requirements at least twelve months before the applicable deadline. Zero tolerance for deadline non-compliance. | The buffer exists because migration programs slip. A slip that eats the buffer is a warning, not yet a crisis. |
| Crypto-agility | All newly deployed systems from Q3 2026 onward should implement crypto-agile architecture as a mandatory design requirement. Any deviation requires Steering Committee sign-off and a documented remediation plan before deployment. | Stops the program from building new technical debt at the same time it is trying to clear old debt. |
The specific thresholds should reflect your sector, regulatory environment, data profile, and risk culture. What matters is that they are specific enough to drive real decisions and get reviewed at least once a year as the landscape shifts. Once those tolerances are in place, the governance function needs metrics to measure performance against them. That is where the KRI hierarchy comes in.
A Cascading KRI Hierarchy for PQC Migration: Board to Operations
This governance framework covers 17 KRIs across three organizational layers, supported by four ownership functions and three reporting cadences. KRIs are what make governance operational rather than theoretical. For quantum security, they need to work at three organizational layers, each with a different audience, reporting cadence, and level of detail. The board needs a short set of metrics that answer strategic questions. The CISO and Steering Committee need more granular signals for resource and priority decisions. Operations need real-time data that feeds both layers above.
Board-Level KRIs (Quarterly Review)
The board does not need fifteen quantum metrics. It needs four or five that answer the questions which directors will raise at every quarterly review: are we on track, are we compliant, what is our current exposure, and has anything changed since last quarter?
The KRIs below are proposed governance metrics recommended as a starting framework. They are not prescribed by NIST, NSA, or CISA, but they are designed to turn the technical realities of PQC migration into the kind of decision-relevant signals a board can actually use.
1. Migration Completion Rate
Percentage of quantum-vulnerable cryptographic instances, meaning each occurrence of a vulnerable algorithm, key type, or protocol identified in the inventory, migrated to PQC or hybrid, measured against the total identified in the cryptographic inventory. Reported as a single number with a trendline. Illustrative threshold: a variance of more than five percentage points against the approved quarterly target triggers a Steering Committee review and board notification.
2. HNDL Residual Exposure
Percentage of data with long-term secrecy requirements still protected by quantum-vulnerable algorithms. This answers the question the board actually cares about: how much of our most sensitive data is harvestable right now? It should decline toward the tolerance set in the risk tolerance statement each quarter. Illustrative threshold: any quarter where this number fails to decrease triggers escalation to the risk committee.
3. Regulatory Compliance Buffer
Days remaining between the organization’s projected migration completion date and the nearest applicable regulatory deadline. This tells the board whether there is breathing room or whether the program is cutting it close. Illustrative threshold: buffer below twelve months triggers amber status; below six months triggers red status and board-level intervention.
4. Third-Party Quantum Readiness
Percentage of critical third-party vendors and partners that have demonstrated PQC readiness or provided a credible migration timeline. This surfaces a supply chain risk that the organization’s own migration work cannot fix. Illustrative threshold: any Tier 1 vendor scoring below “planning” on a quantum readiness assessment triggers a formal engagement.
5. Material Developments Flag
A qualitative signal, not a number. Has anything changed in the quarter that shifts the risk picture? A new cryptanalysis paper that affects resource estimates. A regulatory deadline that moved up. A vendor that dropped PQC support. A hardware milestone that compressed the timeline. This comes from the Cyber Threat Intelligence (CTI) function and gets packaged for the board by Governance, Risk, and Compliance (GRC).
These five metrics give the board what it needs to govern. The CISO needs a fuller picture to manage the program week to week, which is what the next layer is for.
CISO and Steering Committee KRIs (Monthly Review)
The CISO needs more detail than the board does. These metrics inform resource allocation, priority adjustments, and escalation decisions.
6. Cryptographic Inventory Completeness
Percentage of the technology estate covered by the cryptographic inventory. When the inventory covers only 60% of the estate, the migration completion rate becomes unreliable. Every completion percentage is calculated against a partial picture, and the gaps in coverage are exactly where the highest-risk systems tend to hide. Illustrative threshold: completeness below 80% means the migration plan is unreliable. The priority shifts from migrating to inventorying.
7. Migration Velocity
Cryptographic instances migrated per month, measured as a rolling three-month average. A program that was moving well and then stalls tells the CISO something a completion percentage alone does not: there is a blocker. Illustrative threshold: velocity falling below 70% of the planned rate for two consecutive months triggers a program review.
8. Crypto-Agility Adoption Rate
Percentage of new system deployments that meet the crypto-agility design requirement. If the organization deploys new systems faster than it migrates old ones, and those new systems are not crypto-agile, it builds fresh technical debt during a program designed to retire old debt. Illustrative threshold: any month below 95% triggers a review of the procurement and architecture governance process.
9. Regulatory Horizon Tracker
A table showing each pending or proposed regulatory requirement affecting the organization’s PQC posture, with jurisdiction, effective date, current compliance status in green, amber, or red, and the responsible owner. This is produced by the regulatory intelligence function and reviewed monthly by the Steering Committee.
Note: FIPS 140-2 validated modules move to Historical status on September 21, 2026. New acquisitions must plan around FIPS 140-3 validation, and current Cryptographic Module Validation Program (CMVP) validation timelines run 18 months or more. Validation work that has not already started will face a real procurement gap at the 2027 CNSA 2.0 acquisition gate.
10. Vendor PQC Readiness Scores
Aggregated readiness scores for critical vendors, tracked monthly. The important signal is movement, not just the current score. A vendor that was at “planning” and is now “stalled” is a very different situation from one making consistent progress. Illustrative threshold: any Tier 1 vendor that drops a readiness level triggers an engagement review.
11. Budget Consumption vs. Plan
PQC migration budget consumed versus planned spend. Programs that significantly underspend are usually behind schedule, not running efficiently. Illustrative threshold: underspend exceeding 15% in any quarter triggers a program review, because underspend almost always signals blocked workstreams.
The monthly layer keeps the CISO and Steering Committee in control of the program. But those metrics are all derived from data collected at the operational level, which is where the real-time picture lives.
Operational KRIs (Weekly or Real-Time)
Everything the board and the CISO report on each quarter and each month is ultimately built from data collected at this layer.
12. Weekly Migration Throughput
Cryptographic instances migrated in the past seven days, broken down by system tier. The migration program manager uses this to spot bottlenecks before they compound into a quarterly miss.
13. Cryptographic Drift Count
Number of systems that revert to classical-only cryptography after migration, whether through a vendor update, a configuration management failure, or an unapproved deployment. Every instance gets investigated. If it keeps happening, the problem is not a one-off mistake. It is something systemic in the deployment pipeline.
14. Hybrid Downgrade Alerts
Count of hybrid downgrade alerts from the Security Operations Center (SOC), broken down by confirmed attacks, misconfigurations, and false positives. A hybrid downgrade happens when a hybrid PQC-classical connection is forced or misconfigured to operate on classical cryptography alone. The trend across categories shows whether detection capability is maturing and whether the false positive rate is coming under control.
15. Certificate Transition Progress
Percentage of certificates reissued with PQC signature algorithms, tracked against the certificate lifecycle timeline. Certificates that expire before reissuance create forced migration events that may not line up with the program plan. That is the kind of miss that generates incident reports at the worst possible moment.
16. Open Exceptions and Deferrals
Count of systems granted an exception from the migration timeline, with the expiration date for each. An exception register that keeps growing without items being resolved is a governance failure. Illustrative threshold: any exception older than six months without a documented remediation plan triggers an escalation.
17. Vulnerability Remediation Window (TTR-PQC)
For any PQC-specific vulnerability disclosed, such as a CVE in a PQC library or an implementation flaw, the time from disclosure to confirmed remediation across all affected systems. This measures how fast the organization turns a CTI assessment into closed exposure. The gap between understanding a vulnerability and actually fixing it is where risk lives.
With a full KRI hierarchy in place, the governance program has the instrumentation it needs to see what is happening at every layer. The next question is who owns each piece of it.
Governance Roles and Ownership
A KRI hierarchy only works if someone owns each metric and has the authority and resources to act on it. Quantum security governance typically needs four distinct functions to run well.
Executive sponsor: The CISO or a direct CISO report with enough organizational authority to compel action across business units. PQC migration touches every part of the technology estate. Without a sponsor who can resolve cross-functional disputes, programs stall at the boundaries between teams.
PQC Steering Committee: A cross-functional group that includes security architecture, risk, legal, procurement, and the business lines with the highest HNDL exposure. This committee owns the operational KRIs, reviews vendor readiness, approves exceptions, and escalates to the board when thresholds are breached.
GRC function: Responsible for turning technical KRI data into board-ready reporting, maintaining the regulatory horizon tracker, and managing the exception register. The GRC function is the translation layer between what the migration program measures and what the board can act on.
Cryptographic intelligence: A function that may sit inside the existing CTI team, responsible for the Material Developments Flag. This function watches cryptanalysis publications, regulatory movements, hardware capability milestones, and vendor PQC roadmap changes. It turns all of it into the quarterly qualitative assessment the board receives. Without this function, the gap between a new research paper and a board-level governance decision can easily stretch to six months. That gap is where programs get caught off guard.
With the right roles in place, the governance program has both the tools and the accountability structure it needs. If you are looking for help building any part of that infrastructure, here is how Encryption Consulting approaches it.
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 act as your trusted partner, guiding you through every step with clarity, confidence, and real-world expertise.
We start with a Cryptographic Discovery and Inventory, scanning your entire environment to locate certificates, keys, algorithms, and protocols across endpoints, applications, APIs, and infrastructure. This gives you the baseline visibility that any migration depends on.
From there, we run a PQC Assessment to measure your exposure to quantum threats, pinpoint RSA- and ECC-dependent systems, and produce a prioritized report of vulnerable assets ranked by risk severity.
With that picture in hand, we build a PQC Strategy and Roadmap: a phased migration plan shaped around your risk appetite, regulatory requirements, and long-term security goals, with cryptographic agility built in so your systems can adapt as standards continue to develop.
We then support Vendor Evaluation and Pilot Testing, helping you choose the right tools, run proof-of-concept tests, and confirm interoperability before any full-scale rollout begins.
Finally, we oversee Full Implementation, deploying hybrid classical and quantum-safe models, rolling out PQC across your PKI and infrastructure, and putting monitoring in place for long-term cryptographic health.
CBOM Secure
Encryption Consulting’s CBOM Secure tool plays a central role in helping organizations prepare for this transition. Rather than working through spreadsheets, manual OpenSSL outputs, or scattered configuration files, teams get a consolidated view of cryptographic usage across their entire environment. The tool surfaces which algorithms are currently in use, identifies what needs to change to meet post-quantum security requirements, and shows whether systems are aligned with your security objectives.
For organizations preparing for board-level discussions, architecture decisions, or compliance planning, CBOM Secure delivers the clarity and speed that manual processes simply cannot match.
Beyond reporting, CBOM Secure accelerates the work itself. It automates cryptographic inventories, checks TLS configurations, validates algorithms against current and emerging standards, and aligns policies across teams, so organizations can move from discovery to action with confidence rather than guesswork.
Conclusion
Most organizations know quantum risk is real and most have a migration plan somewhere. What is missing is the governance layer that makes the plan actually run: a board-level risk tolerance, a KRI hierarchy that turns technical progress into decisions, and clear ownership of each function. Without it, the same failure modes show up every time. Programs underspend because workstreams are blocked and nobody escalates. Boards lose interest because progress is not visible in terms they can act on. Teams get caught off guard when a deadline moves or a cryptanalysis paper changes the picture.
NIST finalized FIPS 203, 204, and 205 in August 2024. NIST IR 8547 sets deprecation of RSA-2048 and ECC P-256 by 2030 and full disallowance by 2035. HNDL collection is already happening. The migration takes years. The organizations that come through in good shape are the ones that built the governance early.
Start with the inventory. Build the governance around it. Move with purpose.
