Operational Dependency: What Cryptographic Inventories Omit

Migration to post-quantum cryptography begins with inventory: an organization cannot sequence what it cannot see. Current inventory practice, including the emerging cryptographic bill of materials (CBOM) formats, records cryptographic identity — algorithm, library, version, location of use. It does not record operational dependency: the external services each cryptographic operation requires in order to continue functioning. Standards such as FIPS 203, 204, and 205 are algorithm specifications; they make no availability claims and were never intended to. The fragility of deployed cryptography lies not in its primitives but in the substrate those primitives assume — trusted time, reachable revocation infrastructure, available entropy, accessible key custody, and functioning lifecycle automation. An inventory that omits these records what an asset is while remaining silent on what it needs. This paper defines six classes of operational dependency, distinguishes enumerable dependency from untested failure behavior, and extends the coverage-declaration doctrine stated in Jenkins Bey (2026), Step Zero: The Cryptographic Inventory Imperative — Doctrine Summary (DOI: 10.5281/zenodo.22086670), arguing that dependency findings require the honest residual more acutely than identity findings do. The term is qualified deliberately: in software bill-of-materials practice a dependency is a component that invokes cryptography, whereas operational dependency runs the other way.