EvolextQuantum
Navigation

Crypto inventory / tool-assisted scanner

Find the cryptography your migration depends on

Combine supported repository discovery with a separate review of supplied architecture, vendor, and system evidence. Each evidence source and its limitations are recorded within the agreed scope.

Evolext’s work currently focuses on research, assessment, and controlled laboratory prototypes. Production changes require separately agreed engineering and validation.

Discuss this scope ↗

Who this is for

SaaS companies and SMEs that need a defensible starting point for post-quantum planning but do not yet have a reliable cryptographic inventory.

The question this answers

Where is cryptography used, and what evidence is missing?

What we need to begin

  • A named system owner and written authorization for the agreed scope
  • Available architecture, dependency, certificate, and vendor information
  • Access to approved exports or repositories without sharing production secrets
  • A short list of business-critical systems and long-lived data

What we inspect

  • Scanner: supported source API usage and recognized local dependency declarations.
  • Separate supplied evidence: certificates, protocol settings, configuration, and runtime observations when available.
  • Separate supplied evidence: cloud, identity, PKI, network, and managed-service dependencies.
  • Human review: owners, vendor questions, upgrade constraints, and unresolved dependencies.
  • Coverage and confidence: record what was analyzed, skipped, or remains unverified.

What you receive

  • A scoped cryptographic inventory with source and confidence labels
  • An exposure map linking cryptographic use to systems and owners
  • A list of evidence gaps, vendor questions, and follow-up actions
  • A prioritized handoff into the readiness assessment

Important limitations

  • The v0.2.0 scanner analyzes supported source files and recognized local dependency declarations only. It does not scan certificates, runtime, networks, configuration, or cloud environments.
  • This is not penetration testing, certification, an SBOM, or a CBOM.
  • A point-in-time inventory is limited by the evidence supplied and cannot prove every cryptographic dependency has been found.

When the work is complete

The agreed evidence sources have been reviewed, observations reconciled with system owners, and an inventory with coverage limits and unresolved gaps delivered for review. Completion does not mean every dependency has been discovered.

Scope, schedule, and fees are agreed after reviewing requirements. An inquiry does not create an engagement or guarantee availability or an outcome.

Illustrative example · not client work

Inventory entry

Observation / decision
A local manifest declares a cryptographic dependency.
Evidence source
An approved manifest export, reviewed within a defined repository scope.
Uncertainty
Declaration does not establish execution, actual algorithms, or complete coverage.
Owner
Application owner, to be confirmed.
Next action
Confirm reachability and cryptographic role; record unresolved dependencies.

How the engagement works

  1. 01

    Authorize

    Agree systems, evidence sources, access boundaries, and handling rules before collection.

  2. 02

    Collect

    Review approved exports, manifests, configurations, interviews, and tool-assisted observations.

  3. 03

    Validate

    Reconcile duplicates, owners, confidence levels, unknowns, and material evidence gaps.

  4. 04

    Prioritize

    Identify the systems and questions that should enter a readiness assessment first.

Evidence and limitations

Assessment evidence — based on authorized, supplied, and observable sources

Evolext work is research-, assessment-, and prototype-stage. Guidance and source findings do not establish production readiness, compliance, or universal security.

Access boundaries, approved collection methods, permitted recipients, and retention or deletion arrangements must be agreed before collection. Discuss whether approved exports can answer the question without production access. Do not send repositories, credentials, keys, or confidential reports through the inquiry form.

NCCoE guidance informs discovery and migration planning. FIPS 203, 204, and 205 define ML-KEM, ML-DSA, and SLH-DSA algorithm standards respectively; they do not establish protocol, vendor, or system readiness. Applicable references and implementation limits must be recorded for each engagement. References are not certification.

NCCoE migration guidance ↗

Last reviewed:

Choose your starting point. ↗

Tell us which system or migration decision you want to explore. Keep the first inquiry high-level; do not submit credentials, private keys, secrets, or confidential reports.

Discuss this scope ↗Read the privacy policy ↗Migration ↗