You cannot migrate cryptography you cannot find.

• Static discovery

  source · config · certificates

  Public-key generation and signatures, key agreement, symmetric ciphers, hashes and legacy protocol versions, across Python, JavaScript and TypeScript, Java and Kotlin, Go, and server configuration. X.509 certificates are inspected for key size, signature algorithm and expiry. Every finding carries a file and line, or the certificate it came from.

• Runtime observation

  what is actually negotiated

  A pure-Python TLS handshake observer reports the cipher suites a client offers and the one a server actually selects — the cryptography that is genuinely in use, including inside dependencies no static scan can see. It needs no root, no kernel probes and no decryption, and it reports what was negotiated rather than inferring it.

• Classification

  quantum · classical · advice

  Each asset is classified by quantum exposure — broken by Shor, weakened by Grover, or resistant — with a separate verdict for whether it is safe today, and named migration advice referencing the NIST standards (FIPS 203, 204, 205).

• CycloneDX 1.6 CBOM

  machine-readable · portable

  A Cryptography Bill of Materials in the OASIS CycloneDX format — the same schema family as the SBOM tooling already in your pipeline — carrying an observedInUse property that distinguishes assets confirmed on the wire from those seen only in source.

• Prioritised migration register

  sequenced · costed by effort

  Findings ordered by what breaks first and by what protects data with the longest sensitivity window, with per-file density so a remediation sprint can be scoped rather than guessed at.

• A pipeline gate

  exit code · CI-ready

  It exits non-zero when migration-required cryptography is present, so it can fail a build. You cannot hold a migration steady if nothing stops the old algorithms being reintroduced next sprint.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [{
    "type": "cryptographic-asset",
    "name": "RSA-2048",
    "cryptoProperties": {
      "assetType": "algorithm",
      "algorithmProperties": {
        "nistQuantumSecurityLevel": 0
      }
    },
    "properties": [{
      "name": "cryptoagility:observedInUse",
      "value": "true"
    }]
  }]
}

“The discovery step is the one that cannot be skipped, and it is the one almost nobody has started.”

Why the 2028 milestone is the commercially interesting one.

• The engine

  free · AGPL-3.0-or-later

  Static discovery, certificate inspection, runtime observation and CBOM generation. Installable from PyPI, source on GitHub, no account, no licence key, no phone call. Run it on your own machine today and judge the output for yourself.
  pypi.org/project/cryptoagility · github.com/chimaobikanu/cryptoagility

• What we sell

  the work above it

  Turning a CBOM into a funded, sequenced migration: reconciling what the code declares against what the network actually negotiates, ordering the work by risk and shelf life, producing the evidence pack an auditor or customer questionnaire can be answered from, and keeping it true as the estate changes.

• Do it yourself

  free

  The AGPL scanner, on PyPI. Point it at your code and generate your own CBOM and report. No account, no telemetry, no expiry.

• Discovery Scan

  $2,500 · fixed fee

  We run the scan across the estate you name and deliver the reviewed register: CBOM, prioritised migration report, and a findings summary. Fixed scope, fixed turnaround, no meeting required to buy it. Built for a vendor with a customer questionnaire to answer.

• PQC Readiness Assessment

  $8,500

  Everything above, plus runtime observation inside your own environment, reconciliation of declared against observed cryptography, dependency-only findings a static scan misses, a sequenced 30/90/180-day roadmap, and a workshop with the engineers who will do the work.

• Continuous

  $1,500 / month

  CI integration and a pipeline gate, scheduled re-scan, drift alerting when new weak cryptography appears or a certificate is replaced, and the evidence pack refreshed quarterly. For anyone who has to prove the position is still true a year later.

• White-label

  from $6,000 / year

  The engine inside your own assessment service, under your brand. For consultancies and managed security providers who have the clients and the questions but no cryptographic tooling to answer them with.

1. Inside your network, or ours

   Run it yourself — it is a Python package — or we run it with you. Either way your source stays where it is. The tool makes no outbound connections and carries no telemetry, and our CI fails the build if anyone adds a networking import to the discovery core, so this is enforced rather than promised.

2. Scope, then scan

   Repositories, configuration paths and endpoints, written down first. What we did not scan is listed in the report, so absence of a finding is never mistaken for absence of exposure.

3. Review, not dump

   Raw scanner output is not a deliverable. Findings are reviewed, false positives removed, and anything ambiguous said to be ambiguous — a register nobody trusts is worse than no register.

4. Re-scan after remediation

   The same inputs, run again, so the evidence of closure is produced the same way as the evidence of the problem.

• It does not discover keys held in hardware security modules or cloud KMS. A PKCS#11 and vendor-API inventory layer is on the roadmap and is not built.

• It does not analyse firmware or embedded devices. If your exposure is in OT or on silicon, this is not the tool for it.

• Its detection rules are deliberately shallow but transparent. Per-language coverage will never match a decade-old commercial corpus, and we would rather you knew where the edges are than trusted a number we made up.

• For TLS 1.3 it reports the negotiated cipher suite, not the key exchange, because the suite name does not carry it. No key exchange is inferred or guessed.