Post Quantum Cryptography Governance
Placing post-quantum risk on the board register
Post-quantum migration is a multi-year programme with no single existing owner, no established budget line and, in the UK, no binding regulatory deadline. Programmes stall for governance reasons rather than technical ones. The board's role is to name an owner, fund discovery and set a target date.
Why post-quantum security has no owner by default
Cryptography is distributed across functions that each own part of it and none of it. Infrastructure teams own the servers and load balancers. Security architecture owns the standards. Application teams own the code that calls the libraries. Identity teams own certificates and credentials. Procurement owns the supplier relationships that determine what can be migrated and when.
No single role currently holds accountability for the cryptographic estate as a whole, which means the first question in any post-quantum programme is not technical. It is who is accountable.
Two further factors compound the problem. There is no established budget line, because cryptographic modernisation has historically been absorbed into other programmes rather than funded directly. And in the UK the NCSC timelines are guidance rather than binding obligation for most commercial organisations, so there is no external deadline forcing prioritisation. The combination reliably produces a working group with analysis and no authority.
What the board actually needs to decide
Boards do not need to understand lattice cryptography. They need to make four decisions, each of which requires a recommendation rather than an education.
The first is risk appetite. For each data class with a long confidentiality requirement, is the organisation prepared to accept that material transmitted today may become readable within its confidentiality period. That is a business judgement, not a technical one, and it is the decision that sets urgency.
The second is funding for discovery. Discovery is the longest single activity in most programmes and must complete before migration duration can be estimated at all. It is also the activity with the clearest independent return, since the resulting inventory supports audit, incident response and outage prevention.
The third is the target completion date. The realistic options are 2031, aligning with the NCSC's highest-priority milestone and US federal signature deadlines, or 2035, the published endpoint. Choosing 2035 is a decision to accept more risk for lower near-term cost, and should be recorded as such rather than arrived at by default.
The fourth is residual risk acceptance. Some assets, particularly embedded devices with immutable roots of trust, cannot be migrated within any timeline. The board accepts that risk with compensating controls and a replacement date, or funds early replacement.
How to word the post-quantum entry on the risk register
A register entry that says "quantum computing may break encryption" achieves nothing. It is unowned, unmeasurable and cannot be assured. The entry below is the structure that works.

Two features make this version work. It is bounded by named data classes and dates rather than stated as a general concern, so progress can be measured. And it separates the confidentiality risk, which is already accruing, from the authentication risk, which takes effect later but with more immediate consequence.
Which governance model works
The model that succeeds in practice has three components.
A named executive owner holds the risk, normally the CISO or CIO, and is accountable for reporting to the board. This is not delegable to a working group, because the decisions that unblock the programme, particularly funding and supplier escalation, require executive authority.
A cryptographic governance body sets standards and arbitrates. It needs representation from security architecture, infrastructure, identity, application development and procurement, and it needs the authority to set organisational standards for cryptographic policy, library usage and migration sequencing rather than merely to recommend them.
A delegated programme owner runs delivery, with a defined scope covering discovery, target architecture, migration and supplier engagement. Where an organisation already runs a certificate lifecycle capability, this frequently sits with the same function, since the tooling and relationships overlap almost entirely.
Procurement deserves particular attention, because it is where most of the achievable near-term risk reduction sits. Assets bought now without post-quantum capability extend the problem by their full service life, and specification changes cost very little at tender.
What post-quantum security reporting should contain
Board reporting should show progress against constraints, not activity.

Two metrics to avoid early. The proportion of certificates using post-quantum algorithms is close to meaningless before the estate is inventoried, and it will remain near zero for legitimate reasons while public trust certificates are unavailable. Counts of completed workshops or assessments measure activity, not progress.
Evidencing post-quantum security for audit
Auditors and regulators increasingly ask what an organisation has done, and the answer needs to be documentary.
The evidence set is straightforward: a current cryptographic inventory, preferably as a machine-readable cryptographic bill of materials; a documented risk assessment showing how exposure was calculated per data class; a migration plan with dates, owners and dependencies; a record of supplier engagement and responses; and board minutes recording the decisions on risk appetite, funding and target date.
That set also satisfies most external questions. The NCSC expects discovery, an initial plan and supplier communication by 2028. Organisations supplying US federal customers face contractor requirements under Executive Order 14412. Financial entities under DORA and organisations in scope of NIS2 face third-party and supply chain obligations that increasingly encompass cryptographic dependency.
Common governance failures
The first is assigning the work to a working group without authority. Analysis accumulates, decisions do not, and the programme stalls at the first supplier who declines to engage.
The second is funding discovery without funding remediation. An inventory that identifies problems no one is resourced to fix damages credibility and makes the next funding request harder.
The third is treating post-quantum migration as a project with an end date rather than a cryptographic management capability. Algorithms will be replaced again, and an organisation that builds the capability once will handle the next transition as an operation rather than a programme.
The fourth is delegating ownership to a vendor. A supplier can deliver discovery, architecture and migration, but the risk remains on the organisation's register and the decisions remain the board's.
How Unsung helps
Unsung is a UK-based, vendor-neutral consultancy specialising exclusively in public key infrastructure and cryptographic systems, working across central government, defence, healthcare, financial services, nuclear and transport.
We produce the evidence base a board needs to decide: exposure assessed per data class, migration duration estimated from an actual inventory through our PKI health check and cryptographic bill of materials services, and a costed plan against a chosen target date. Through our PKI consultancy practice we also support the governance structures themselves, including cryptographic policy, architecture standards and supplier requirements. Being vendor-neutral, our recommended sequencing follows the assessment rather than a product roadmap.
For the exposure calculation that underpins the risk register entry, see the three timelines used in quantum risk assessment.
Frequently asked questions
Who should own post-quantum risk in an organisation?
How should quantum risk be worded on a risk register?
What should we report to the board and how often?
Do we need board approval to start?
How do we justify the investment without a binding UK deadline?
Is this a project or an ongoing capability?


