PQC migration should be owned jointly by security architecture, infrastructure, PKI, and application teams, with clear executive accountability. The work touches discovery, remediation, lifecycle automation, and dependency management, so no single function can carry it alone. Strong ownership prevents fragmented decisions that leave critical systems stranded on unsupported cryptography.
Why This Matters for Security Teams
pqc migration is not a pure cryptography project. It is a certificate-risk and dependency-risk program that cuts across infrastructure, security architecture, PKI operations, and application ownership. If ownership sits in only one team, the common failure mode is partial migration: strong algorithms in one layer, legacy certificates or untracked dependencies in another. That leaves the organisation exposed even when the crypto inventory looks clean on paper.
This is why governance has to be joint, not serial. The security function can define risk tolerance and policy, but infrastructure teams control deployment realities, PKI teams control issuance and renewal mechanics, and application teams know where certificates are embedded or hard-coded. The problem becomes more visible when teams discover hidden certificate consumers late in the process, similar to the dependency blind spots described in NHIMG research such as the Top 10 NHI Issues. In practice, many security teams encounter certificate sprawl only after renewal failures, vendor outages, or a crypto inventory exercise has already stalled remediation.
How It Works in Practice
Effective PQC migration ownership starts with a named executive accountable for the program, then distributes decision rights by domain. Security architecture sets policy for algorithm approval, acceptable risk, and exception handling. Infrastructure owns platform rollout, certificate lifecycle automation, and service continuity. PKI teams manage issuance, revocation, chain trust, and renewal workflows. Application teams identify where certificates are embedded in code, containers, appliances, and third-party integrations.
That division matters because certificate risk is operational, not theoretical. A migration plan should include:
- Cryptographic and certificate inventory across services, appliances, and third-party dependencies.
- Prioritisation based on business criticality, external exposure, and renewal timeline.
- Testing for algorithm compatibility, handshake failures, and tooling gaps.
- Automation for discovery, replacement, and re-issuance where possible.
- Exception governance for systems that cannot migrate on the same timeline.
Current guidance suggests treating PQC as part of broader identity and certificate governance, not as a one-time hardening task. NIST’s NIST Cybersecurity Framework 2.0 is useful for assigning accountability, while NIST SP 800-53 Rev. 5 Security and Privacy Controls helps map lifecycle, configuration, and access controls to the migration work. For teams that also need a broader identity lens, NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is a useful reminder that unmanaged machine trust is often where hidden certificate exposure accumulates. These controls tend to break down in legacy estates with embedded certificates in appliances and vendor-managed systems because ownership and replacement windows are often unclear.
Common Variations and Edge Cases
Tighter migration governance often increases coordination overhead, requiring organisations to balance security urgency against operational change windows. That tradeoff becomes sharp in hybrid estates, regulated environments, and platforms with long vendor support cycles. There is no universal standard for this yet on how to split ownership across infrastructure and security teams, but current best practice is evolving toward a RACI model with one accountable executive and shared execution owners.
Edge cases usually appear when one of three conditions exists. First, outsourced PKI or managed certificate services can blur operational control, so the internal owner must still retain risk decisions even if issuance is delegated. Second, application teams may not know where certificates live because they are stored in source control, container images, or embedded device firmware. Third, business units may push for crypto replacement before asset inventories are complete, which creates a false sense of progress.
In that environment, the right question is not who “owns” PQC in isolation, but who can approve exceptions, force remediation, and stop risky deployments. NHIMG’s The 2024 ESG Report: Managing Non-Human Identities underscores the cost of fragmented machine-identity governance, which is directly relevant when certificate sprawl overlaps with broader NHI control gaps. The practical answer is shared execution with one accountable leader, because split authority without a single decision-maker tends to stall migration until renewal pressure exposes the weakest dependency.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | PQC migration needs clear governance and accountability across teams. |
| NIST SP 800-63 | Certificate trust and lifecycle management underpin digital identity assurance. | |
| NIST AI RMF | GOVERN | Cross-functional accountability is a governance requirement, not a technical detail. |
| NIST Zero Trust (SP 800-207) | SA-4 | PQC affects trust boundaries and system-to-system authentication in Zero Trust designs. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Certificate sprawl and weak lifecycle control are core NHI risks. |
Assign one accountable owner and use governance reviews to track PQC risk, exceptions, and remediation progress.
Related resources from NHI Mgmt Group
- Who should own AI application security decisions when multiple teams attend the same programme?
- Who should own enterprise authorization policy when business teams and security teams both influence access decisions?
- Who is accountable for product security decisions when infrastructure, identity, and application risk overlap?
- How do security teams reduce risk when self-hosting passkey infrastructure?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
