Who should own PQC migration across identity, infrastructure, and applications?

Why This Matters for Security Teams

pqc migration is not just a cryptography upgrade. It changes how identities are issued, how secrets are stored, how trust is established between services, and how applications negotiate secure channels. That means ownership cannot sit solely in security, infrastructure, or engineering. It needs a cross-functional crypto centre of excellence with explicit accountability, because the blast radius spans IAM, PKI, platform engineering, and software delivery. The old assumption that crypto work is a specialist back-office task no longer holds.

This is especially important for organisations already struggling with non-human identity sprawl. NHI Management Group research shows that NHIs outnumber human identities by 25x to 50x in modern enterprises, while only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs. That kind of baseline makes PQC migration harder, because the inventory problem arrives before the algorithm problem. The migration also needs to align with broader security governance, including the NIST Cybersecurity Framework 2.0 approach to coordinated risk management.

In practice, many security teams discover the ownership gap only when certificates, service accounts, and application dependencies begin failing in production.

How It Works in Practice

Effective PQC ownership starts with a clear operating model. The crypto centre of excellence should set standards, but each domain team should own execution within its scope. IAM owns identity lifecycle changes. PKI owns certificate policy, trust anchors, and issuance workflows. Platform teams own runtime dependencies, service mesh, and ingress or egress enforcement. Application teams own protocol changes, library upgrades, and test coverage. Risk and architecture teams define adoption priorities and exception handling.

In practice, the first step is discovery: identify where cryptography is used, including certificates, TLS termination, token signing, SSH, API authentication, and embedded libraries. That inventory should cover both human and non-human identities, because service accounts, automation tokens, and workload identities often carry the most fragile dependencies. NHIMG’s Top 10 NHI Issues is useful here because it reinforces that hidden secrets, weak rotation, and poor visibility are usually the real blockers, not the algorithm selection itself.

• IAM should map which identities use certificates, signing keys, or short-lived tokens.
• PKI should determine where hybrid certificates, intermediate CAs, or staged trust models are needed.
• Platform teams should test load balancers, service meshes, and mutual TLS paths for PQC readiness.
• Application teams should update SDKs and libraries, then validate compatibility in non-production first.
• Risk teams should decide which systems need early migration because of data longevity or regulatory exposure.

Current guidance suggests using phased migration, because there is no universal standard for replacing every legacy dependency at once. Some systems may remain hybrid for years, especially where vendor support, embedded devices, or mainframe integrations limit change. The safest model is a shared roadmap with named owners, deadlines, and exception review, rather than a single enterprise crypto project. These controls tend to break down in highly federated environments where teams ship independently and no one owns the full trust chain end to end.

Common Variations and Edge Cases

Tighter PQC governance often increases delivery overhead, requiring organisations to balance cryptographic assurance against release velocity. That tradeoff matters because not every workload has the same urgency or technical feasibility. Internet-facing authentication, long-lived data protection, and identity systems with broad blast radius should move first, while low-risk internal systems may follow later under a controlled exception process.

There is also a genuine ownership split between policy and implementation. Best practice is evolving, but current guidance suggests the crypto centre of excellence should not become a bottleneck that approves every change manually. Instead, it should define approved patterns and delegate execution. That matters for environments with many application teams, because a central team cannot rewrite thousands of service integrations by itself. In those cases, the strongest model is a federated one: central standards, domain execution, and audit trails that show who accepted each risk.

Another edge case is vendor dependence. If a third-party platform controls certificate handling or embedded crypto libraries, internal teams may own the risk but not the code path. That is where procurement, architecture review, and renewal planning become part of PQC ownership. Organisations should also remember that identity migration and crypto migration are linked: if secrets are still stored in code or reused across services, PQC work will expose broader NHI weaknesses rather than isolate them. For that reason, the most mature programmes treat PQC as part of a larger NHI governance effort described in the Ultimate Guide to NHIs and the breach patterns discussed in 52 NHI Breaches Analysis.

Related resources from NHI Mgmt Group

• Who should own ISO 27001 control implementation across identity and access?
• Why do SaaS apps create identity governance risk as they spread across the business?
• Who should own SaaS reporting outputs in an identity programme?
• Who should own vendor risk management in an identity programme?