Who should own PQC readiness in an organisation?

Why This Matters for Security Teams

pqc readiness is not a pure cryptography project. It is a dependency mapping exercise that cuts across identity, PKI, application design, infrastructure, and vendor governance, which is why ownership must be shared rather than isolated in a specialist silo. The practical risk is not just algorithm migration, but missed inventory, hidden trust paths, and broken integrations when legacy assumptions meet new cryptographic requirements. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it frames resilience as an enterprise capability, not a one-team task.

NHI Management Group’s Ultimate Guide to NHIs shows why this matters in operational terms: modern enterprises often have far more NHIs than human identities, and those identities frequently sit inside service workflows, automation, and secrets handling that cryptographic teams do not own directly. That same pattern applies to PQC, where the migration path is shaped by where keys live, how certificates are issued, and which systems depend on them. In practice, many security teams discover PQC blockers only after application owners or platform teams are asked to change production dependencies, rather than through intentional readiness planning.

How It Works in Practice

Effective PQC ownership is usually a federated model with clear accountability. Security architecture sets policy and prioritises the migration roadmap. Identity engineering owns identity formats, trust relationships, and lifecycle impacts. PKI teams manage certificate profiles, trust anchors, and issuance workflows. Application teams assess protocol dependencies and code-level cryptographic use. Infrastructure and platform teams validate operating systems, load balancers, HSMs, and middleware. This is the operational translation of enterprise risk ownership, not a theory exercise.

Current guidance suggests building a cryptographic inventory first, then classifying dependencies by migration difficulty: easy library upgrades, certificate and protocol replacements, hybrid compatibility requirements, and hard cases such as embedded systems or vendor-managed appliances. The NIST Cybersecurity Framework 2.0 supports this kind of coordinated planning because it pushes governance, protection, and recovery into an integrated programme. For identity-heavy environments, the Ultimate Guide to NHIs is a useful reference for where machine credentials, rotations, and offboarding practices intersect with trust migration.

• Assign one executive sponsor and one programme owner to prevent fragmented decision-making.
• Require every domain team to inventory cryptographic dependencies, including NHIs, secrets, certificates, APIs, and automated trust paths.
• Track readiness by system, not by department, so ownership follows the real dependency map.
• Use policy gates for procurement, software release, and platform changes to stop new non-PQC-safe dependencies from accumulating.

These controls tend to break down when organisations rely on outsourced platforms or legacy embedded systems because the cryptographic surface area is broader than the internal team can directly change.

Common Variations and Edge Cases

Tighter PQC governance often increases coordination overhead, requiring organisations to balance cryptographic certainty against delivery speed. That tradeoff is real, especially where teams are already managing certificate renewal, zero trust, and identity hygiene at the same time.

There is no universal standard for PQC ownership structure yet, but the best practice is evolving toward shared accountability with a single programme lead. In smaller organisations, that lead may sit in security architecture or PKI. In larger enterprises, responsibility often lands in a cryptographic transition office, platform engineering, or enterprise risk, provided it has authority over identity and application owners. The key exception is when a business unit runs regulated or externally exposed systems; in that case, ownership should be tightened around the system owner with central oversight, because migration timing and operational risk become business-critical. If the environment depends heavily on NHIs, the governance model should also reflect secrets rotation, certificate automation, and service-to-service trust, not just human authentication assumptions.

In practice, teams that treat PQC as a standards update rather than an application and identity programme usually discover the hardest dependencies only when certificates expire or vendors announce incompatibility.

Related resources from NHI Mgmt Group

• Who should own user lifecycle governance in an organisation?
• Who should own device risk policy in an organisation?
• Who should own architecture decisions in a complex organisation?
• Who should own authorization governance in a scaling product organisation?