A complete cryptographic assessment, produced with no route out

What offline mode is

Offline mode is the same binary doing the same discovery, with the submission step replaced by a local assessment. Instead of posting findings to an API and letting the platform score them, the agent scores them itself and writes the finished result next to itself on disk.

Concretely, in this mode the agent:

• opens no outbound connection of any kind — no submission, no telemetry, no update check, no licence call, no DNS beyond what a network target you explicitly configured would need;
• accepts no API URL and no API key. There is no credential to provision for an air-gapped host, and none to leak on one;
• needs no installation. It is a single statically-built executable; there is no runtime, interpreter or shared library to satisfy inside the enclave;
• writes only to the output directory you name, and reads everything else read-only.

Everything needed to reach a verdict is compiled into the binary: the compliance rules, the risk model, the remediation-ownership classifier, the parameter-set-to-NIST-level mapping and the CycloneDX writer. There is no rules file to keep current and no lookup to perform.

What runs offline

All eight discovery sources run in offline mode — the mode changes what happens to the findings, not how they are found. Worth being precise about one thing: “offline” means no route to us, not necessarily no network at all. An enclave with its own internal LAN can still scan the endpoints and appliances on it; the agent simply never reaches beyond them.

Get it in, verified

An air gap moves the trust problem to the boundary: whatever you carry across, you should be able to prove is what we published. Verify on the connected side, then carry the verified bytes in.

The four binaries

Each is a self-contained executable — no installer, no package manager, no dependencies. On a connected Linux or macOS host, install.sh downloads and verifies in one step into the current directory (it does not touch anything system-wide), which is a convenient way to prepare transfer media.

Verify before it crosses

Every release is published with a SHA256SUMS manifest signed twice: classically with Ed25519, and with post-quantum ML-DSA-65 (FIPS 204). A tool that tells you your signatures will not survive a quantum adversary ought to be signed with one that will.

BASE=https://api.pqcrypta.com/stream/downloads/discovery-agent
curl -O $BASE/linux                       # or windows | macos | macos-intel
curl -o SHA256SUMS            $BASE/verify/SHA256SUMS
curl -o SHA256SUMS.sig        $BASE/verify/SHA256SUMS.sig
curl -o SHA256SUMS.mldsa.sig  $BASE/verify/SHA256SUMS.mldsa.sig
curl -o pqcrypta-agent-signing.pub $BASE/verify/pqcrypta-agent-signing.pub

# 1. classical signature over the manifest
openssl pkeyutl -verify -pubin -inkey pqcrypta-agent-signing.pub \
  -rawin -in SHA256SUMS -sigfile SHA256SUMS.sig

# 2. the manifest pins the binary
sha256sum -c SHA256SUMS --ignore-missing

The public keys are published from a second, independent origin — the append-only discovery-agent-keys repository — so you can compare the key you verified with against a copy we do not serve. The full procedure, including ML-DSA verification, is in §2 of the guide.

Configuration presets

With no --config, the agent uses its built-in per-OS path catalog, which is a good default for a first look. For a repeatable air-gapped scan, carry a TOML file in alongside the binary: when one is supplied its scan_paths are authoritative — the agent scans exactly that list and nothing else, which is usually what an enclave's change control wants to see.

The three reference-* catalogs are the built-in defaults written out as editable files, so no config at all and --config reference-linux.toml scan the same set. To narrow a scan, delete paths; to widen it, add your own. Two settings matter more than usual on an isolated host:

• keystore_passwords — passwords tried against locked PKCS#12/PFX/JCEKS containers. A container that stays locked is reported as a gap in coverage rather than a clean result, because an unopened keystore and an empty one otherwise look identical. Passwords are never written to any output file.
• excluded_paths — pairs with --full-disk-scan to keep a whole-volume sweep out of pseudo-filesystems and build caches.

Running it

One flag switches the run from “submit” to “assess locally”: --offline-report <dir>. The directory is created if it does not exist.

Linux / macOS

chmod +x ./pqcrypta-discovery
./pqcrypta-discovery --config linux-web-server.toml \
                     --offline-report ./assessment --deep-scan

Windows

.\pqcrypta-discovery.exe --config windows-server.toml `
                        --offline-report .\assessment --deep-scan

Flags that change what an offline run covers:

What it produces

Three files, written to the directory you named. They are deliberately different artifacts for three different readers — a person, a tool, and a system of record.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:9736ddc0-9a4b-440e-821f-ada23574ff26",
  "version": 1,
  "metadata": {
    "timestamp": "2026-08-07T20:26:54.361158110+00:00",
    "tools": [{ "vendor": "PQCrypta", "name": "discovery-agent", "version": "1.0.16" }],
    "component": {
      "type": "device",
      "bom-ref": "host:pqcrypta.com",
      "name": "pqcrypta.com",
      "version": "Ubuntu 24.04.4 LTS"
    },
    "properties": [{ "name": "pqcrypta:mode", "value": "offline" }]
  }
}

{
  "type": "cryptographic-asset",
  "bom-ref": "5cc3d78e…70fd@/etc/ssl/certs/CFCA_EV_ROOT.pem",
  "name": "CFCA EV ROOT",
  "cryptoProperties": {
    "assetType": "certificate",
    "certificateProperties": {
      "subjectName": "CFCA EV ROOT",
      "issuerName": "CFCA EV ROOT",
      "notValidBefore": "2012-08-08T03:07:01+00:00",
      "notValidAfter": "2029-12-31T03:07:01+00:00",
      "certificateFormat": "X.509"
    }
  },
  "hashes": [{ "alg": "SHA-256", "content": "5cc3d78e…70fd" }],
  "evidence": { "occurrences": [{ "location": "/etc/ssl/certs/CFCA_EV_ROOT.pem" }] },
  "properties": [
    { "name": "pqcrypta:location",  "value": "/etc/ssl/certs/CFCA_EV_ROOT.pem" },
    { "name": "pqcrypta:algorithm", "value": "RSA" },
    { "name": "pqcrypta:key_size",  "value": "4096" }
  ]
}

{
  "type": "cryptographic-asset",
  "bom-ref": "algorithm:ecc-secp256r1--p-256-",
  "name": "ECC-secp256r1 (P-256)",
  "cryptoProperties": {
    "assetType": "algorithm",
    "algorithmProperties": {
      "primitive": "key-agree",
      "parameterSetIdentifier": "secp256r1 (P-256)",
      "nistQuantumSecurityLevel": 0
    }
  },
  "properties": [{ "name": "pqcrypta:quantum_vulnerable", "value": "true" }]
}

// …and the edge that makes it reachable from the asset:
{
  "ref": "5cc3d78e…70fd@/etc/ssl/certs/CFCA_EV_ROOT.pem",
  "dependsOn": ["algorithm:rsa-4096"]
}

{
  "location": "/etc/ssl/fated/server/smtp.fated.org.key",
  "location_type": "filesystem",
  "asset_type": "private_key",
  "algorithm": "RSA",
  "key_size": 4096,
  "sha256_fingerprint": "66c2dc47f67b…d739",

  "compliance_status": "legacy",
  "risk_level": "high",
  "recommendation": "Quantum-vulnerable. Migrate to Hybrid (ML-KEM-1024 + ML-DSA-87) or Pure PQ.",

  "remediation_owner": "internal",
  "is_actionable": true,
  "remediation_note": "You hold the private key — this key material is yours to rotate."
}

Scored on the host — and scored the same way

An offline assessment is worth little if it is a lesser assessment. Post-quantum scoring, risk grading, remediation-ownership classification and CBOM assembly all run on the agent, using the same rules the platform applies at ingestion, and the two implementations are pinned against drift by parity tests: an air-gapped report reads identically to a connected one for the same asset.

Five compliance statuses, applied identically in both modes:

Unattended & repeatable

An inventory is a maintenance obligation, not a one-off. The agent is a single-shot process with no daemon and no state directory, which makes scheduling it trivial — each run overwrites the previous bundle, or writes to a dated directory if you want the history.

0 3 1 * * /opt/pqcrypta/pqcrypta-discovery \
    --config /etc/pqcrypta/agent.toml --deep-scan \
    --offline-report /var/lib/pqcrypta/$(date +\%Y-\%m) >> /var/log/pqcrypta-scan.log 2>&1

schtasks /create /tn "PQCrypta Assessment" /sc monthly /d 1 /st 03:00 /ru SYSTEM `
  /tr "C:\pqcrypta\pqcrypta-discovery.exe --config C:\pqcrypta\agent.toml --deep-scan --offline-report C:\pqcrypta\assessment"

Running as SYSTEM (or root) is what closes the permission-denied gaps — unprivileged runs report the directories they could not read rather than pretending they were empty.

Exit codes

So a scheduler that only watches the exit status will not notice reduced coverage. If that matters, watch the log for Access is denied / Permission denied lines, or diff the asset count between runs — a sharp drop is the signal.

A third mode: raw findings

Between submitting and a full assessment there is --output <file>, which writes the discovered assets as raw JSON with no local assessment — no compliance status, no risk, no ownership, no CBOM. It exists for pipelines that do their own scoring. If you want the assessment, use --offline-report; the two are alternatives, not layers.

Carrying results out

What crosses the boundary is your call; the tool has no channel of its own. In practice there are two useful patterns:

• Review inside, carry out the machine-readable pair. Read report.html on the host, then move cbom.json and inventory.json out for aggregation. Both are plain text and diff cleanly, so they survive whatever review your boundary imposes.
• Carry out the CBOM only. It identifies its own subject host, so it stands alone, and it contains no filesystem detail beyond evidence.occurrences[].location — which you can strip if paths themselves are sensitive.

On the outside, the same inventory can be loaded into the Compliance Dashboard alongside connected hosts, so an air-gapped enclave appears in the same estate-wide readiness numbers as everything else rather than living in a spreadsheet nobody re-runs.

Re-running is cheap and produces a directly comparable document: same fields, fresh serialNumber, new timestamp. Quarterly re-runs turn a one-off audit into a trend line — which is what “maintain a cryptographic inventory” actually asks for.

When you do have a network

Offline mode is complete for one host at one moment. What it cannot do is accumulate. Point the same binary at an API with --api-url and --api-key instead of --offline-report, and the findings stop being a file and start being an estate.

What connected mode adds

• The Compliance Dashboard — total assets and devices, the compliance split, quantum readiness with a qualitative stage label rather than a bare percentage, organization-controlled versus vendor-controlled progress, and a Discovery Coverage checklist. Most cards jump straight into a pre-filtered inventory.
• Estate-wide CBOM export — one CycloneDX document across every host, filtered by any combination of source, device, algorithm, certificate role and compliance status. CSV and JSON report exports share the identical filter set, so a selection always describes the same rows.
• A policy engine — compliance rules evaluated against every stored asset at ingestion and on demand, so “no RSA under 3072 in production” becomes a check rather than a convention.
• Threat-intelligence correlation — CISA KEV and NVD data matched against the OpenSSL versions your scans actually observed, so a vulnerable library is a current finding rather than a mailing-list post.
• SIEM delivery — real webhook POST or RFC 3164 syslog to a registered destination, so findings land where your analysts already look.
• Lifecycle — assets a scan no longer observes are retired automatically, with a guard that refuses to write off most of a host at once because that is the signature of a narrowed scan, not a decommissioning.

Everything above is in the full guide; the overview covers all eight discovery sources.