Cryptographic inventory
A cryptographic inventory you can re-run, not a report you have to believe
QNSI maintains a tenant cryptographic inventory with typed assets and algorithm properties, emits it as a CycloneDX 1.5 CBOM, and can sign it with a post-quantum signature so a third party can check it without trusting us.
A cryptographic inventory is only useful if it can be reproduced. A spreadsheet assembled once by a consultant is a snapshot; it cannot be re-derived, and it cannot be defended six months later when a regulator asks how you knew.
QNSI builds the inventory from observable sources, keeps the algorithm properties alongside each asset, exports it in an open standard, and supports a signed export whose verification does not depend on our infrastructure being available.
Contents
What the inventory holds
Asset types and the properties recorded for each. Secret values are never inventory contents.
KMS keys
Identifier, purpose, algorithm family and parameter set, rotation state, creation and last-used timestamps.
Certificates
Subject, issuer, chain position, signature algorithm, key type and size, not-before and not-after.
Vault secrets
Secret identity, version history, wrap algorithm and envelope version. Secret values are never stored in the inventory.
Signing keys
Algorithm, security level, custody boundary and the operations the tenant policy permits.
Workload identities
Service-to-service authentication material and its verification path.
Host observations
Key material, trust stores and crypto usage observed by the host agent, attributed to a host identifier.
Source repository findings
Cryptographic API and configuration usage in code, with file, rule identifier, confidence and line hash.
Kubernetes assets
Secrets, ingress certificates and crypto configuration, attributed to cluster and namespace.
Properties
How each asset is classified
The algorithm metadata that turns a list of findings into a migration plan.
Algorithm family and parameter set
ML-KEM, ML-DSA, SLH-DSA, RSA, ECDSA and the concrete parameter set in use.
Algorithm class
Whether the asset is post-quantum, hybrid (classical plus post-quantum) or purely classical.
Security level
The NIST category the parameter set targets, where one is defined.
Occurrences
How many distinct places the inventory observed the asset or usage.
Source
Which connector or scan produced the observation, normalised to the provider it came from.
Verification
Signed, then independently checkable
The signed CBOM carries the algorithm, provider, key identifier and signing time so verification is mechanical.
- Export the CBOM for the current inventory state.
- Sign it with a post-quantum signature; the record binds algorithm, provider, key identifier and time.
- A verifier removes the signature field and checks the remainder against the published public key.
The signature is tamper evidence, not a quality judgement: it proves the document has not changed since it was signed, and says nothing about whether the inventory was complete.
Related
Where the inventory is used
Discovery builds it; policy governs it; audit proves it.
What is a cryptographic inventory?
A cryptographic inventory is the maintained record of every cryptographic asset an organisation holds, together with its algorithm properties. It is what makes a post-quantum migration plannable, and what lets an auditor verify the resulting claim.
What is a CBOM?
A Cryptographic Bill of Materials (CBOM) is a standardised form of that inventory. QNSI emits CycloneDX 1.5, where each component is typed as a crypto-asset and carries its algorithm, class, key size and occurrence count.
Can a cryptographic inventory be signed?
Yes. CBOM documents can be signed with post-quantum signatures for tamper evidence. The signature block records the algorithm, provider, key identifier, signing time and the signed value; verification removes the signature field and checks the remainder against the published public key.
What is CBOM crypto inventory used for?
Three main purposes: establishing the migration scope and ordering it by risk, producing compliance reporting for frameworks such as ISO/IEC 27001:2022 and 19790:2025, and giving procurement a measurable definition of quantum-safe coverage instead of a vendor assertion.