Accountability should sit with the designated migration lead, but the broader answer is that identity, infrastructure, and application owners all share responsibility for the trust map. PQC migration fails when no one owns dependency truth. Governance frameworks should make that ownership explicit before deadlines tighten.
Why This Matters for Security Teams
Incomplete cryptographic inventory is not a paperwork gap. It means the migration lead cannot reliably say which systems use RSA, where certificates live, which libraries depend on vulnerable primitives, or which business services will fail when algorithms are retired. That turns pqc migration into an operational trust exercise instead of a controlled engineering program. Current guidance from NIST Cybersecurity Framework 2.0 emphasizes governance and asset visibility because organisations cannot protect what they have not mapped.
The accountability question matters because incomplete inventories usually create false confidence. One team assumes another owns certificate discovery, while application owners assume infrastructure has already captured dependencies. NHI Management Group notes in the Ultimate Guide to NHIs that 5.7% of organisations have full visibility into their service accounts, which is a good proxy for how often identity dependency truth is missing at the outset. In practice, many security teams encounter cryptographic blind spots only after a migration milestone has already been set, rather than through intentional dependency discovery.
How It Works in Practice
Accountability should be assigned to a designated migration lead, but execution must be shared across identity, infrastructure, and application owners. The migration lead owns the trust map, the exception register, and the decision log. Identity owners identify where keys, certificates, and trust anchors are issued and rotated. Infrastructure owners inventory platform-level dependencies such as load balancers, VPNs, CI/CD runners, and service meshes. Application owners confirm library usage, embedded crypto, external integrations, and hard-coded assumptions.
Practically, this means building an inventory from multiple sources rather than a single CMDB export. Teams usually combine:
- certificate authorities and PKI records
- cloud asset inventories and configuration scans
- source code and dependency analysis
- secrets stores, vaults, and CI/CD tooling
- network and telemetry data that reveal live crypto dependencies
The current best practice is to treat unknowns as migration blockers, not deferred cleanup. A cryptographic inventory should track algorithm, key length, issuer, usage, expiration, application owner, service criticality, and replacement path. This also aligns with the governance emphasis in Ultimate Guide to NHIs, because identity visibility and lifecycle control are prerequisites for any trust transition. The inventory should be updated continuously, not only during program kickoff, because new dependencies appear as systems deploy and teams refactor.
These controls tend to break down when cryptography is embedded in legacy appliances, vendor-managed platforms, or unmanaged third-party integrations because ownership and telemetry are both incomplete.
Common Variations and Edge Cases
Tighter inventory requirements often increase delivery overhead, requiring organisations to balance migration speed against the cost of discovery. That tradeoff becomes more severe when deadlines are driven by external compliance dates or vendor retirement notices, because the pressure to move can overwhelm the time needed to prove dependency truth.
There is no universal standard for who owns every edge case, but current guidance suggests the migration lead should remain accountable for overall completeness even when technical discovery is delegated. In regulated environments, vendors may supply attestation for hosted services, yet that does not remove the internal obligation to document how those services consume cryptography. In complex estates, shared ownership works best when RACI-style assignment is explicit and when exceptions are time-bound with named approvers.
Edge cases also include shadow IT, unmanaged SaaS, and embedded devices where the cryptographic control plane is not visible to central teams. In those environments, the answer is not to wait for perfect completeness. It is to establish a decision process that records unknown assets, assigns a follow-up owner, and prevents silent migration of unverified dependencies. Without that discipline, accountability becomes symbolic and the inventory remains incomplete even after the program formally starts.
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 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM | Incomplete crypto inventory is fundamentally an asset and dependency visibility problem. |
| OWASP Non-Human Identity Top 10 | NHI-01 | PQC migration exposes unmanaged identities and hidden trust relationships in the crypto estate. |
| NIST AI RMF | Governance is needed to assign accountability for complex migration decisions and unknown dependencies. |
Build and maintain a living asset inventory that includes cryptographic dependencies before migration cutovers.
