Who should own PQC migration decisions when assets are blocked by code changes, vendor dependencies, or risk acceptance?

Why This Matters for Security Teams

pqc migration decisions rarely fail because the cryptography is unknown. They fail because ownership is fragmented across application code, PKI operations, vendor contracts, and risk acceptance. When a system blocks migration, the real question is who can change the blocker without turning the decision into a permanent exception. That is why security should govern the process, but not own every remediation task.

This is a practical issue, not an abstract one. NHI programs already show how quickly weak ownership turns into persistent exposure. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts in its Ultimate Guide to NHIs, and the same ownership gaps appear in crypto migration. If the team responsible for the blocked asset is not named, funded, and accountable, the migration queue becomes a risk backlog. The control model should therefore map to the team with implementation authority, while security enforces policy, timelines, and review discipline. That approach aligns well with NIST SP 800-53 Rev 5 Security and Privacy Controls and current NIST guidance on governance.

In practice, many security teams encounter stalled PQC work only after audit findings or vendor renewals have already exposed the gap.

How It Works in Practice

The cleanest operating model is to assign decision ownership by blocker type. Application owners own code changes when libraries, protocols, or integrations need refactoring. Infrastructure, platform, or PKI teams own certificate and key lifecycle changes when the issue sits in TLS termination, key distribution, HSMs, or trust stores. Vendor management owns external dependency tracking, contract pressure, and escalation when a supplier cannot yet support the required crypto posture. Security owns policy, standards, and exception governance.

That split matters because PQC migration is not a single technical switch. It is a chain of local decisions that must be coordinated at runtime and over time. In many organisations, the first step is inventory: identify where cryptographic dependencies live, which systems are internet-facing, which are long-lived, and which can be isolated for earlier migration. From there, teams should create a migration plan with named owners, target dates, testing gates, and rollback criteria. Risk acceptance should be time-bound and tied to a specific blocker, not to a vague future upgrade cycle.

Practitioners usually pair this with formal control mapping. NIST Cybersecurity Framework 2.0 gives a useful governance structure for identifying who is accountable, who is executing, and how progress is tracked. The NHI Management Group view is that crypto migration should be treated like any other identity control dependency: inventory first, ownership second, exceptions last. That lines up with broader NHI hygiene concerns in Top 10 NHI Issues, where weak lifecycle governance often outlives the original risk decision.

• Use a RACI model that separates policy ownership from implementation ownership.
• Track blockers by asset, dependency, owner, and expiration date.
• Require vendor exceptions to include roadmap evidence and renewal review dates.
• Escalate overdue risk acceptances to the business owner, not only to security.

These controls tend to break down in highly outsourced environments because the organisation can document risk but cannot compel a supplier to change crypto support timelines.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, requiring organisations to balance speed against accountability. That tradeoff becomes sharper when assets are embedded in legacy systems, regulated workloads, or vendor-managed platforms. In those cases, the right answer is not to force one team to own everything, but to create a clear decision chain with explicit escalation paths.

There is no universal standard for this yet, but current guidance suggests a few practical patterns. For legacy code that cannot be changed quickly, application owners should still own the remediation plan even if a platform team implements part of it. For vendor dependencies, procurement and vendor management need authority to escalate, but security should set the minimum acceptable crypto requirement. For formal risk acceptance, business leadership should own the decision when the residual risk affects operations or revenue, with security documenting the control gap and review cadence.

This is also where governance needs discipline. Risk acceptance should expire, not persist. Exceptions should be reviewed on a fixed schedule, and the review should ask whether the blocker still exists, whether a compensating control was added, and whether the asset can now be moved to a PQC-ready path. Mature programs also keep an exception register that links the decision to the specific asset and owner, so the same issue does not reappear as a new exception later. The lesson from the broader NHI domain is straightforward: when ownership is diffuse, exceptions become architecture.

Related resources from NHI Mgmt Group

• Who should own review decisions for high-risk code changes?
• Who should own DNS migration decisions when service ownership changes?
• Who should own PQC migration when multiple teams depend on the same trust assets?
• Who should own the risk when AI-generated code changes security-sensitive flows?