Who should be accountable for post-quantum readiness across the enterprise?

Accountability should sit with the owners of identity, infrastructure, application, and supplier risk together, because cryptography crosses all of those boundaries. Standards, architecture, and vendor management have to move in the same direction or migration will stall in the gaps between teams.

Why This Matters for Security Teams

Post-quantum readiness is not a narrow cryptography project. It is an enterprise accountability problem because encryption shows up in identities, APIs, applications, internal platforms, vendor integrations, and archived data. If ownership stays trapped inside one team, migration stalls at the boundaries where certificates expire, libraries lag, or suppliers control the update path. NIST’s Cybersecurity Framework 2.0 makes clear that governance and risk ownership must be explicit, not implied. NHIMG research also shows why this cannot be treated as background work: Ultimate Guide to NHIs — Why NHI Security Matters Now reports that 90% of IT leaders say properly managing NHIs is essential for successful zero trust.

The practical risk is that post-quantum deadlines arrive faster than enterprise change cycles. Many organisations still do not know where their cryptographic dependencies live, which means they cannot assign remediation intelligently. In practice, many security teams encounter cryptographic exposure only after a product dependency, certificate lifecycle, or supplier contract has already blocked the migration path, rather than through intentional planning.

How It Works in Practice

Accountability should be distributed by control plane, then coordinated through one enterprise program owner. Identity teams typically own authentication, token formats, certificate issuance, and workload identity. Infrastructure teams own platform libraries, HSMs, vaults, network termination points, and patch cadence. Application teams own code changes, protocol selection, and dependency updates. Supplier risk owns third-party commitments, migration clauses, and evidence that vendors can actually execute the change.

The most effective pattern is a cryptography inventory tied to business services, not just to algorithms. Teams need to know where RSA, ECC, TLS termination, signing workflows, certificate authorities, and key exchange mechanisms are used, then map each dependency to a remediation path. Policy should define which systems must be upgraded first, which can be wrapped temporarily, and which require compensating controls until replacement. For enterprise governance, NHIMG’s NHI research is useful because the same service-account, token, and secret sprawl that creates NHI risk also creates hidden cryptographic dependencies.

• Identity teams own cryptographic trust primitives for humans, workloads, and service accounts.
• Infrastructure teams own platform readiness, including libraries, vaults, and certificate rotation paths.
• Application teams remediate code, dependencies, and protocol usage.
• Supplier risk ensures vendors publish timelines, proofs, and contract commitments.

Best practice is evolving toward a named executive sponsor with a cross-functional steering group that tracks inventory, roadmap, exceptions, and supplier attestations. CISA guidance on post-quantum cryptography readiness supports this kind of staged enterprise planning. These controls tend to break down when legacy applications depend on unmanaged third-party libraries because cryptographic upgrade paths are hidden inside code ownership that no one has formally assigned.

Where Accountability Usually Breaks Down

Tighter cryptographic governance often increases coordination overhead, requiring organisations to balance speed of migration against operational disruption. The largest gap is usually not technical capability but unclear exception handling. Current guidance suggests that temporary risk acceptance should be time-bound, documented, and owned at a business level, not left as an implicit engineering choice.

Edge cases matter. Some systems cannot be upgraded in place because embedded devices, regulated platforms, or external suppliers control the timeline. In those environments, accountability should shift from “who can patch fastest” to “who can prove residual risk is understood and reduced.” NIST’s Cybersecurity Framework 2.0 is helpful here because it frames governance as an ongoing function, not a one-time project. For NHIs, the same principle applies to long-lived service identities and secrets, which often outlast the systems they protect.

There is no universal standard for exactly how to divide post-quantum ownership across the enterprise, but there is broad agreement that one team cannot carry it alone. Organisations that wait for perfect centralisation usually lose time while asset visibility, vendor readiness, and migration ownership remain fragmented.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised SaaS integration is used to move across multiple clouds?
• How should security teams make NHI best practices usable across the business?
• Why is single-provider AI agent governance not enough for enterprise security?
• When should security teams prioritise post-quantum readiness work?