PQC Is Exposing the Cryptographic Governance & Control Gap
Post-quantum cryptography is forcing organisations across sectors and jurisdictions to discuss discovery, inventories, cryptographic mapping, and crypto-modernisation.
That is necessary.
It is not sufficient.
The more difficult question is not whether an organisation can produce a list of cryptographic assets. The difficult question is whether it understands and governs the control environment surrounding those assets.
Do you know where your cryptographic controls are?
That question reaches beyond certificates, keys, algorithms, and cryptographic libraries. It asks who has the authority to create trust, approve trust, revoke trust, rotate keys, alter policy, administer a certificate authority, change a trust store, or operate the systems that manage cryptography.
It also asks whether those actions are authorised, monitored, tested, funded, maintained, and supported by evidence.
Without that information, an organisation may possess a substantial cryptographic inventory while lacking a governed cryptographic estate.
Discovery is not governance
Discovery identifies what exists.
It may reveal:
Algorithms embedded in applications and services.
Certificates deployed across internal and external environments.
Keys stored in platforms, devices, cloud services, and hardware security modules.
Cryptographic libraries and providers used by software.
Protocols supporting identity, authentication, encryption, signing, and secure communications.
Cryptographic dependencies introduced by suppliers and managed service providers.
Firmware, hardware, and infrastructure that cannot be changed without specialist intervention.
That information is valuable. It provides the foundation for prioritisation and migration planning.
However, discovery alone does not establish ownership or authority. It does not prove that cryptographic mechanisms are maintained, funded, monitored, tested, or capable of controlled change.
A certificate inventory may show where certificates exist. It may not show who can issue them, who can revoke them, who approves changes to the certificate authority, or whether renewal depends on a manual process that no team formally owns.
A key inventory may show where keys are stored. It may not show who can create, export, recover, rotate, suspend, or destroy them.
An algorithm inventory may show where RSA, ECC, or other mechanisms are used. It may not show whether the application can transition to a different algorithm or provider without code changes, redesign, or supplier intervention.
This is the control gap.
What is a cryptographic control?
A cryptographic control is not simply the technical object performing encryption or signing.
It is the combination of authority, policy, identity, permission, process, technology, monitoring, and evidence that governs a cryptographic function.
Controls determine:
Who can create or approve trust.
Who can issue, revoke, and renew certificates.
Who can create, rotate, recover, suspend, and destroy keys.
Who can alter cryptographic policy.
Who can change a trust store or certificate authority.
Who can approve a new algorithm, provider, or cryptographic service.
Who can administer the systems that administer cryptography.
How privileged activity is separated, recorded, reviewed, and challenged.
How exceptions are approved and eventually removed.
How control effectiveness is tested and demonstrated.
This is why cryptographic governance cannot be reduced to asset discovery.
An organisation needs to know not only what cryptographic mechanisms exist, but also how authority flows through the estate.
The ownership problem
Cryptography frequently crosses organisational boundaries.
A certificate may be operated by infrastructure, issued through a security team, renewed by an application pipeline, and governed by a policy owned by risk or compliance.
A cloud-managed key may support a business application owned by one department, while the cloud platform, key-management service, and operational procedures are controlled by another party.
A supplier may embed cryptography in software or firmware without exposing the full implementation or lifecycle model to the customer.
This creates a practical governance problem.
Who owns the cryptographic control?
Not who uses the system.
Not who receives the alert.
Not who renews the certificate when the process works.
Ownership means accountability for the control’s purpose, operation, maintenance, cost, risk, change, and evidence.
A properly governed control should have a named owner or accountable function, a documented purpose, defined operating responsibilities, funding, maintenance arrangements, escalation paths, and a review cycle.
Where those elements are absent, responsibility becomes distributed without becoming accountable.
That is how control drift develops.
The cost question
Cryptographic controls create ongoing costs.
Those costs may include:
Certificate authority services.
Hardware security modules.
Key-management platforms.
Software licences and support contracts.
Certificate lifecycle management.
Specialist engineering and operational support.
Monitoring, logging, testing, and audit activity.
Vendor assurance and contractual review.
Migration, interoperability, and performance testing.
Replacement of systems that cannot support new cryptographic requirements.
A cryptographic inventory that does not connect controls to cost creates an incomplete view of risk.
A control without funding is not sustainable. A control without maintenance is an unmanaged dependency. A control without a replacement path can become a source of operational fragility.
PQC migration will place additional pressure on these areas. New algorithms, larger keys, new certificate profiles, hybrid mechanisms, provider changes, and interoperability requirements may affect performance, capacity, licensing, hardware, and support models.
The question is not simply whether a product claims PQC support.
The question is whether the organisation can operate, govern, fund, and replace that capability throughout its lifecycle.
Crypto-agility is a governance capability
Crypto-agility is often presented as the ability to switch algorithms.
That is too narrow.
SITG-Consulting defines cryptographic agility as:
The capability to transition between cryptographic algorithms, providers, and policies as standards evolve or vulnerabilities emerge.[sitg-consulting]
This definition matters because it includes algorithms, providers, and policies.
A system may support a new algorithm while remaining operationally rigid. It may require a major application redesign to change providers. It may depend on a single supplier. It may lack the approvals, testing, monitoring, or rollback capability needed to change cryptographic policy safely.
That is not meaningful agility.
A crypto-agile environment needs the ability to make controlled changes across the technical and governance layers. This includes architecture, application design, interfaces, identity, access management, certificate lifecycle, key management, supplier dependencies, operational procedures, testing, and assurance.
The objective is not to change cryptography constantly.
The objective is to retain the ability to change it when standards evolve, vulnerabilities emerge, providers fail, products reach end of support, or regulatory and contractual requirements change.
PQC will expose hidden dependencies
PQC migration will require organisations to examine where public-key cryptography supports confidentiality, identity, authentication, integrity, signatures, software updates, device trust, and secure communications.
That examination will expose dependencies that are difficult to see from a conventional asset inventory.
It may reveal:
Applications with cryptographic parameters embedded in code.
Trust stores maintained outside central governance.
Certificates issued by unknown or unsupported authorities.
Key lifecycles dependent on manual intervention.
Hardware that cannot support required key sizes or algorithms.
Cloud services with unclear provider transition paths.
Supplier products with limited cryptographic transparency.
Operational procedures that depend on individual knowledge.
Systems that cannot tolerate certificate, key, or algorithm changes.
Controls that have never been tested under failure conditions.
PQC will not automatically repair these weaknesses.
The migration process will make them harder to ignore.
It will force organisations to ask whether they can identify the control, assign accountability, approve the change, test the outcome, monitor the result, and produce evidence that the migration was completed safely.
From inventory to control evidence
A useful cryptographic inventory should evolve into a control and dependency record.
For each significant cryptographic control, an organisation should be able to identify:
The function
What does the control protect or enable?
Is it supporting confidentiality, integrity, identity, authentication, signing, key establishment, software integrity, or trust validation?
The location
Where is it implemented?
Is it in an application, device, cloud service, network, firmware component, certificate authority, hardware security module, supplier platform, or operational process?
The authority
Who can create, approve, change, suspend, revoke, recover, or destroy the relevant cryptographic material or policy?
The owner
Which person, team, business function, or supplier is accountable for the control?
The cost
What funds its licensing, operation, maintenance, monitoring, support, testing, and eventual replacement?
The lifecycle
When was it implemented, last reviewed, last tested, patched, renewed, or changed?
What is the plan for replacement or retirement?
The dependency
Which applications, business processes, suppliers, platforms, and data flows depend on it?
The evidence
Can the organisation demonstrate that the control operates as intended?
This information turns a static inventory into a governance instrument.
The questions that matter
If an organisation wants to understand its PQC and crypto-modernisation risk, it should ask:
Where are the cryptographic controls?
What functions do they support?
Who owns them?
Who funds them?
Who maintains them?
Who can change them?
Who can approve those changes?
Which suppliers or cloud providers are involved?
What happens if the control fails?
How quickly can it be replaced or reconfigured?
What evidence demonstrates that it works?
What prevents unauthorised or untested change?
What is the migration path if the algorithm, provider, or policy becomes unacceptable?
These questions apply across jurisdictions. They are not dependent on one national regulatory model or one migration deadline.
They are questions of operational accountability, enterprise risk, resilience, and trust.
The control plane is the issue
PQC is often described as an algorithm transition.
It is broader than that.
It is an examination of whether an organisation understands the cryptographic dependencies that support its digital operations and whether it can change those dependencies in a controlled manner.
Discovery tells you what exists.
Governance tells you whether it is owned, controlled, maintained, funded, testable, and defensible.
Crypto-agility determines whether the organisation can transition between cryptographic algorithms, providers, and policies as standards evolve or vulnerabilities emerge.
If an organisation cannot identify who owns a cryptographic control, who funds it, who maintains it, who can change it, and how the change can be evidenced, then the issue is not limited to PQC readiness.
The issue is the control plane.
And without a governed control plane, an inventory is only a catalogue of assumptions.
Comments