Platform capability
Cryptographic Discovery & Inventory
Find cryptographic dependencies across cloud infrastructure, hosts, TLS endpoints, certificates, secret managers, Kubernetes, repositories, and imported inventories.
Buyer outcome
Create an accountable migration backlog from observed cryptographic assets instead of spreadsheets, vendor assumptions, or incomplete cloud-only scans.
Source-backed · deployment evidence required
For CISO · Cryptography lead · Enterprise architect · Security engineering
Evidence boundary
Connector, local-scanning, normalization, classification, checkpoint, and export contracts exist in source. Complete estate coverage, classification accuracy, connector execution, and deployment-specific behavior remain NOT VERIFIED unless linked evidence says otherwise.
Capability map
What discovery & inventory covers
Each item is a source-backed or deployment-bounded capability, not an implied certification or universal runtime guarantee.
Operating model
How the capability fits into an accountable workflow
01
Connect or import
Attach an eligible discovery source, run the local CLI, or submit a normalized inventory through the API.
02
Classify
Normalize algorithms, protocols, providers, certificates, keys, and code usages into an evidence-bearing inventory.
03
Prioritize
Apply policy, data-lifetime, exposure, expiry, and dependency context to form a migration backlog.
04
Export and reconcile
Produce CBOM, QBOM, SBOM, and signed findings for review, migration planning, and later cutover validation.
Integration & assurance
Connect the capability, then verify the exact boundary
Integration surfaces
Frequently asked questions
Discovery & Inventory questions
Does QNSI require repository upload for source-code discovery?
The CLI source defines local parsing and normalized-finding upload contracts. Repository contents do not need to be uploaded for local analysis. Payload exclusion, signing, ingestion, materialization, and deployment behavior still require deployment-specific verification.
Are CBOM, QBOM, and SBOM the same artifact?
No. CBOM describes cryptographic assets and dependencies, QBOM records quantum-readiness context, and SBOM describes software components. QNSI keeps them separate so a release can bind software, cryptography, and migration evidence without implying that one inventory proves the others.
Next step
Evaluate the capability against your actual environment
Start with the public evidence, then scope the exact services, integrations, custody, deployment, and assurance required. QNSI will not convert source presence into a production claim without evidence.