Who owns post-quantum migration in an identity programme?

Why This Matters for Security Teams

Post-quantum migration is not just a crypto upgrade. It is an inventory, dependency, and governance problem that cuts across identity, certificates, secrets, applications, and infrastructure. If ownership is pushed entirely into platform or infrastructure teams, the migration usually starts with TLS endpoints and ends with overlooked service accounts, embedded certificates, and hard-coded trust assumptions. Current guidance in the NIST Cybersecurity Framework 2.0 treats this kind of work as a cross-functional risk activity, not a single-team task. For identity programmes, that matters because trust objects have a lifecycle: they are issued, used, rotated, deprecated, and eventually retired, just like credentials. The practical lesson is that ownership must sit with lifecycle governance, while execution is shared across IAM, PKI, security architecture, and application owners. That is the same governance pattern NHI programmes need when they discover how many hidden trust artefacts are scattered across systems, as described in the Ultimate Guide to NHIs. In practice, many security teams encounter dependency failures only after certificate expiry, library incompatibility, or vendor support gaps have already disrupted production, rather than through intentional migration planning.

How It Works in Practice

The cleanest operating model is a shared one with a named owner for each layer. Identity governance should own the policy, risk register, and retirement deadlines. PKI should own certificate algorithms, issuance paths, and revocation readiness. Platform teams should inventory runtime dependencies, while application owners validate code paths, libraries, and external integrations. Security governance should arbitrate exceptions, track residual risk, and ensure the programme is aligned to enterprise risk appetite. This is not a one-time cutover. It is a staged trust transition. A workable sequence usually looks like this:

• Build a trust inventory for certificates, signing keys, token issuers, and machine identities.
• Classify where crypto is customer-facing, internal, embedded, or third-party dependent.
• Prioritise the highest-value and longest-lived trust objects first.
• Test dual-stack or hybrid modes where legacy and post-quantum methods must coexist.
• Set deprecation dates, fallback rules, and exception review cadence.

The reason this matters for identity is that cryptographic trust often underpins service-to-service access, automation, and secrets distribution. If those flows are not visible, the migration stalls. Research from the Top 10 NHI Issues shows how often organisations lack full visibility into non-human trust paths, and that same blind spot appears in post-quantum planning. For control design, use NIST Cybersecurity Framework 2.0 to anchor governance, and map migration checkpoints to asset inventory, configuration management, and change control. These controls tend to break down when certificates are embedded in legacy appliances or vendor-managed services because the dependency owner is not the system owner.

Common Variations and Edge Cases

Tighter cryptographic control often increases operational overhead, requiring organisations to balance faster migration against compatibility and uptime risk. That tradeoff is especially visible in environments with mainframes, industrial systems, regulated third-party integrations, or externally managed SaaS where algorithm choices are constrained. In those cases, best practice is evolving rather than fixed: some systems can move quickly to hybrid certificates, while others need extended coexistence periods and formal exception management. There is also no universal standard for who “owns” post-quantum readiness at the team level. In mature programmes, the answer is a federated model with one accountable executive sponsor and named owners for identity, PKI, applications, and infrastructure. This is where lifecycle governance matters more than ticket routing. If the programme only tracks infrastructure certificates, it will miss identity issuers, signing workflows, secrets stores, and machine-to-machine trust chains. The operational priority is to know which trust objects can be changed centrally, which require application updates, and which are stuck behind vendor roadmaps. The 52 NHI Breaches Analysis is useful here because it reinforces a broader pattern: hidden machine trust creates downstream risk long before an incident is visible. In practice, the hard part is not selecting the algorithm; it is finding every place where identity depends on it.

Related resources from NHI Mgmt Group

• Who is accountable when identity controls fail in a GRC programme?
• Who should own accountability for AI agent misuse in the identity programme?
• How should security teams build a cross-domain identity programme?
• When does a machine identity become a compliance problem?