Post-quantum cryptography (PQC) is frequently discussed as a straightforward exercise in swapping out algorithms like RSA for newer standards such as ML KEM and hybrid key exchange. However, this perspective overlooks the operational reality facing DevOps teams: selecting an algorithm is only one part of the problem. The significantly harder task involves determining where vulnerable or legacy cryptography exists within your environment, which applications depend on it, who owns those dependencies, and how difficult each replacement will be to execute.
Visibility as a Foundation
NIST's current Migration to Post Quantum Cryptography project explicitly identifies cryptographic visibility and risk management as core workstreams. They recommend building comprehensive inventories that cover algorithms, protocols, keys, certificates, applications, services, devices, and data flows—rather than treating the certificate inventory as synonymous with the entire landscape.
For engineering teams in modern organizations, this distinction is critical because cryptography is distributed throughout the software delivery lifecycle. A developer might introduce a dependency via a package; a CI pipeline may sign an artifact using specific keys; containers inherit TLS libraries from base images; Kubernetes terminates TLS through ingress controllers; and cloud services manage encryption keys via KMS or HSM.
None of these dependencies necessarily appear in conventional certificate inventories. Consequently, the first step toward quantum readiness is not deploying a post-quantum algorithm immediately. It is establishing sufficient visibility to understand where cryptography exists and what depends on it before any migration begins.
The Embedded Cryptographic Footprint
Modern software delivery creates cryptographic dependencies long before an application reaches production environments. Git repositories typically utilize HTTPS or SSH, dependency managers retrieve packages through authenticated connections, CI systems communicate with external services over TLS, and artifact repositories rely on certificates for authentication.
The runtime environment introduces another layer of complexity where a single application can depend on cryptography provided by several infrastructure layers owned by different teams. Kubernetes clusters use certificates for control plane communication; ingress controllers terminate TLS; service meshes establish encrypted connections between microservices; APIs validate signed tokens; databases encrypt stored information; and cloud platforms manage encryption keys.
This scale illustrates why visibility cannot be limited to application code alone. A source code search for RSA, AES, ECDSA, or SHA256 will not reveal the complete picture because applications frequently inherit cryptographic behavior from frameworks, operating systems, libraries, containers, infrastructure components, and managed services. The footprint of a production system is better represented as a dependency graph than merely as a list of algorithms.
What an Inventory Must Capture
A useful inventory requires more information than just algorithm names to be actionable for engineers and security teams. It must provide context on where dependencies exist, what they protect, who controls them, and how they can eventually be replaced. Key elements include:
- Algorithms: Identifying exposure across RSA, ECC, AES, SHA families, and PQC algorithms.
- Libraries: Revealing implementation dependencies like OpenSSL or BoringSSL versions.
- Protocols: Showing where cryptography is negotiated via TLS, SSH, VPN, mTLS, etc.
- Certificates and Keys: Mapping PKI dependencies including issuer chains and lifecycle management for rotation.
- Data Sensitivity: Establishing protection requirements to help prioritize migration efforts.
NIST notes that inventories can describe key metadata without containing actual key material. The relationships between these elements matter as much as the elements themselves; knowing an organization has thousands of RSA certificates does not reveal which applications use them or whether underlying systems support different mechanisms.
Why SBOMs Are Not Enough
Software Bills of Materials (SBOM) have become vital for supply chain security, identifying components and package versions. However, cryptographic visibility requires another level of detail beyond standard software component lists to address the specific risks associated with encryption mechanisms.
What This Means For Practitioners
To prepare for quantum readiness, teams must move from reactive algorithm replacement planning to proactive inventory building that captures infrastructure dependencies. The operational implication is clear: you cannot migrate what you do not see. Engineering efforts should focus on mapping the cryptographic dependency graph across your entire stack before attempting any migration strategy.