Discovery Agent

Three Products in One

"Discovery agent" undersells it. One binary, one scan, three genuinely distinct capabilities — most vendors sell these as separate products.

Quick Start

Real, working downloads — no account or API key required to get the binary. For the full walkthrough — every run mode, the complete configuration reference, appliance scanning, offline mode, and troubleshooting — see the Complete Guide →

curl -sSL https://api.pqcrypta.com/stream/downloads/discovery-agent/install.sh | bash

🔐 Not blind curl | bash. The installer fails closed: it verifies the binary's Ed25519 signature (key pinned in the script) and SHA-256 checksum before making it executable. Every release is hybrid-signed — classical Ed25519 and post-quantum ML-DSA-65 (NIST FIPS 204), both over a signed SHA256SUMS manifest and verifiable entirely offline (no CA). We sign our own supply chain with the same hybrid transition we recommend to you. Full verification steps: Verify Your Download →

# Linux x86_64 (~12.3 MB)
curl -o pqcrypta-discovery https://api.pqcrypta.com/stream/downloads/discovery-agent/linux

# Windows x86_64 (~16.0 MB)
# https://api.pqcrypta.com/stream/downloads/discovery-agent/windows

# macOS Apple Silicon / arm64 (~16.9 MB)
curl -o pqcrypta-discovery https://api.pqcrypta.com/stream/downloads/discovery-agent/macos

# macOS Intel / x86_64 (~17.6 MB)
# curl -o pqcrypta-discovery https://api.pqcrypta.com/stream/downloads/discovery-agent/macos-intel

chmod +x pqcrypta-discovery

./pqcrypta-discovery \
  --api-url https://api.pqcrypta.com \
  --api-key YOUR_API_KEY \
  --deep-scan

What It Captures

Platform Support

Comprehensive Scan Coverage

The built-in per-OS defaults (used when you run with no --config) cover these categories out of the box — each a real, tested path pattern, not aspirational. Every one of these paths lives in the downloadable reference-{linux,windows,macos}.toml config, so you can trim this list down or extend it: run with --config and your file's scan_paths are exactly what gets scanned.

Air-Gap / Offline Mode

The agent runs a complete assessment entirely on-host, with zero network access — no API key, no callback, nothing leaves the machine. One flag produces a self-contained bundle you carry out on removable media:

• --offline-report ./assessment — scan, classify, and report locally in one step
• report.html — a single self-contained compliance report (all styling inlined, no external requests) safe to open on an isolated host: post-quantum readiness, risk breakdown, remediation ownership, and the full inventory
• cbom.json — a CycloneDX 1.6 Cryptographic Bill of Materials
• inventory.json — every asset with full detail and its assessment

Post-quantum scoring, risk rating, remediation-ownership classification, and CBOM assembly are all computed on the agent — the same logic the platform runs server-side — so an air-gapped report is identical to an online one. There is no SaaS tether: the same single binary that scans a cloud host also runs unattended inside a classified enclave and hands back a complete, standards-based assessment. Verified by running under a network namespace with no interfaces at all.

Self-Hosted / On-Premises Platform

Three ways to run PQCrypta, so the deployment fits your data-sovereignty posture — not the other way around:

• Hosted (SaaS): agents submit to our dashboard with --api-url. Nothing to operate.
• Offline / air-gap: one binary, one flag, a complete on-host assessment — the mode above.
• Self-hosted platform: run the entire platform — API, PostgreSQL, and the Compliance Dashboard — inside your own network. Agents point at your API; no inventory, CBOM, or telemetry ever leaves your environment.

The self-hosted tier ships as a docker compose stack (database + API + dashboard) with a connected installer and a fully air-gapped bundle — container images, schema, and signed agent artifacts staged into a single tarball that installs on a disconnected host with zero registry pulls. Point agents at it with nothing more than --api-url http://your-host:3003; the dashboard, its CSP, and every download link follow the same local base URL.

It runs behind a license that is post-quantum signed with ML-DSA (Dilithium3, NIST FIPS 204) and verified entirely offline at startup — no phone-home, so it works in classified enclaves. A tampered license fails closed; an expired one keeps you running in grace mode. It's the same hybrid post-quantum transition we sign our own supply chain with, applied to entitlement.

Appliance Lab Validation

The F5/NetScaler integration isn't tested against mocks — it's validated against a live, licensed F5 BIG-IP Virtual Edition 17.5 (TMOS) running on KVM, scanned exactly the way a customer would run it: agentlessly, from a separate jump host, over iControl REST, using a least-privilege Auditor-role account.

• Deliberate certificate matrix: RSA-2048, RSA-4096, ECDSA P-256, an already-expired certificate, and a spare certificate never bound to any virtual server — every one discovered with correct algorithm, key size, subject, and expiry
• The unbound-certificate claim, proven: the spare cert is invisible to live TLS scanning of the appliance's endpoints (nothing serves it), but the management-API inventory surfaces it — the core reason this scan mode exists
• Factory-vs-customer split verified: TMOS's shipped certificates (ca-bundle, f5-irule, default) classify as hardware-vendor remediation; every certificate we installed classifies as internal — yours to rotate
• Device facts cross-checked: the reported TMOS version, Virtual Edition platform, CPU/memory, management IP, and interface MACs all matched the known VM configuration exactly
• Operationally honest: re-scans are idempotent (no duplicate assets), one unreachable appliance never aborts the rest of the scan, and read-only credentials are sufficient end-to-end — including the TMOS quirk that newly created accounts start password-expired, which is documented in the setup guidance
• End-to-end, not endpoint-deep: the validated path runs appliance → agent → API → inventory → Compliance Dashboard → CycloneDX 1.6 CBOM export

The Citrix NetScaler/ADC integration is validated the same way, against live NetScaler 14.1 firmware (NetScaler CPX) over the NITRO API: the same certificate matrix, correct handling of NITRO's expired-certificate semantics (the true not-after date is preserved even when daystoexpiration has hit zero), factory certificates (ns-server-certificate, ns-sftrust-certificate) classified as hardware-vendor remediation, and device facts — build version, platform, management IP, interfaces — collected from the device's own nsversion/nshardware/nsip endpoints.

CBOM: Weak Cryptography in Source Code

Every other scan type finds crypto material at rest — a cert file, a live TLS endpoint, a database column. CBOM (Cryptographic Bill of Materials) is different in kind: it looks for calls into known-weak cryptographic primitives inside your own application source code. A codebase can have a spotless certificate inventory and still call hashlib.md5() for something security-sensitive — nothing else in this tool can see that.

Scope, stated plainly: this is known-weak call-site detection via pattern matching against real per-ecosystem API idioms — not full static analysis. It does not follow data flow, so a weak primitive reached through a wrapper function or a variable-selected cipher name is out of scope by design. That trade keeps findings high-confidence: what it flags is a literal call into a broken primitive at a specific file and line.

# Off by default. Point it at your source trees:
code_scan_paths = ["/opt/myapp/src", "/opt/myapp/internal"]

OS & Security Metadata Collection

Collected once per scan and attached to every submission — this is what powers the Discovered Systems page in the dashboard (security score, TPM/Secure Boot indicators, hardware).

Command Line Options

Configuration File

The agent is fully config-driven — there is no hidden hardcoded path list. Run it with --config yourfile.toml and that file's scan_paths are authoritative: the agent scans exactly what you list and nothing else. Run it with no --config and it falls back to a built-in per-OS default set — which is literally the same reference-{linux,windows,macos}.toml file you can download and edit. Keystores (.jks/.p12/.pfx/…) are opened and their certificates inventoried wherever scan_paths point, so widening keystore coverage just means adding a path. Every field below is real and currently supported. Start from a ready-made preset in the dashboard's Download Discovery Agent section (role presets, or full per-OS catalogs with every path active) — all at /stream/downloads/discovery-agent/config/<name>.toml.

# API endpoint configuration
api_url = "https://api.pqcrypta.com"
api_key = "your-api-key-here"

# Filesystem paths to scan for certificates, keys, SSH keys, and keystores
# (.jks/.p12/.pfx found here are opened and their certs inventoried too).
# When this file is passed via --config, these paths are AUTHORITATIVE — the
# agent scans exactly this list. ~, $VAR, ${VAR} and %VAR% are expanded.
# For the complete built-in set, start from reference-linux.toml (or the
# Windows/macOS catalogs) instead.
scan_paths = [
    "/etc/ssl/certs",
    "/etc/pki",
    "/root/.ssh",
    "/opt/tomcat/conf",   # e.g. keystore.jks — parsed into individual certs
]

# Enable deep scanning (slower but more thorough)
deep_scan = false

# Filter for specific algorithms (comma-separated). Leave empty/commented to scan
# for all algorithms.
# algorithms_filter = ["RSA", "ECC"]

# Paths to exclude from scanning. OPT-IN: with no excluded_paths (or no config at
# all) nothing is excluded. Uncomment to skip pseudo-filesystems and scratch dirs
# — strongly recommended if you add broad roots or run with --full-disk-scan.
# excluded_paths = ["/proc", "/sys", "/dev", "/tmp"]

# Source-code trees to scan for weak-crypto API calls (CBOM). Off by default.
code_scan_paths = []

# Keystore passwords for locked PKCS#12/PFX/JKS containers. The built-in defaults
# (empty / changeit / password) are always tried first; these are added after.
# There is no lockout on a local keystore, so the list is tried first-match-wins
# with no need to map a password to a specific store. Used LOCALLY only — never
# submitted, never logged. Four sources, merged in order (all opt-in):
# keystore_passwords = ["s3cret", "corp-export-pw"]         # inline
# keystore_passwords_file = "/etc/pqcrypta/keystore-pw.txt" # newline-separated file
# (env) PQCRYPTA_KEYSTORE_PASSWORDS="pw1\npw2"              # environment variable
# keystore_passwords_command = "vault kv get -field=pw secret/keystores"  # any secrets
#   manager via its CLI — aws secretsmanager get-secret-value, op read, gpg -d, etc.

# Database connections to scan (optional). Reads real column values matching
# %cert%/%key%/%pem% and parses them; never stores the raw value. Dispatch is by
# DSN scheme (postgres/mysql/sqlite/mssql/oracle all functional). Oracle needs
# Instant Client installed on the scanning host itself — skipped gracefully if not.
# [[database_connections]]
# name = "Production PostgreSQL"
# db_type = "postgres"
# dsn = "postgres://user:password@localhost/dbname"
# [[database_connections]]
# name = "Legacy SQL Server"
# db_type = "mssql"
# dsn = "mssql://user:password@localhost:1433/dbname"
# [[database_connections]]
# name = "Oracle Prod"
# db_type = "oracle"
# dsn = "oracle://user:password@host:1521/ORCL"

database_connections = []

# Live network/TLS endpoints to inspect — reflects what's actually being
# served right now, not just files sitting in a cert store.
[[network_targets]]
host = "example.com"
port = 443

# F5 BIG-IP / Citrix NetScaler certificate stores, via management API.
# [[appliance_targets]]
# name = "F5 Prod LB"
# appliance_type = "f5"          # or "netscaler"
# mgmt_url = "https://your-f5-mgmt-host"
# username = "readonly-api-user"
# password = "..."
# verify_tls = true

API Integration

{
  "scan_id": "550e8400-e29b-41d4-a716-446655440000",
  "agent_hostname": "server-01.example.com",
  "agent_version": "1.0.0",
  "agent_platform": "linux",
  "os_metadata": {
    "os_name": "Ubuntu", "os_version": "24.04",
    "tpm_available": true, "secure_boot_enabled": false,
    "cpu_model": "AMD EPYC-Milan Processor", "cpu_cores": 4
  },
  "assets": [
    {
      "location": "/etc/ssl/certs/server.crt",
      "location_type": "filesystem",
      "asset_type": "certificate",
      "algorithm": "RSA",
      "key_size": 2048,
      "subject_cn": "server.example.com",
      "issuer_cn": "Let's Encrypt Authority X3",
      "not_after": "2026-06-01T00:00:00Z",
      "sha256_fingerprint": "..."
    }
  ],
  "scan_duration_ms": 45320,
  "errors": []
}

GET /crypto-assets/report
    ?remediation_owner=internal          # any inventory filter: compliance_status,
    &expires_after=2026-07-06T00:00:00Z  #   risk_level, asset_type, environment,
    &discovered_by_hostname=web-01       #   application, search, date bounds, device
    &columns=device,location,hosted_on_hostname,hosted_at_locations,algorithm,valid_until,compliance_status
    &group_by=device                     # orders rows by hosting device for sectioned output
    &format=csv                          # csv | json (default csv)
    &limit=10000                         # row cap, max 50000 (json summary still counts the full match)

Compliance Assessment

Classification is based on the actual NIST-registered OIDs for post-quantum algorithms, not string matching.

Remediation Ownership

A flat inventory tells you what's wrong. Ownership classification tells you who can actually fix it — the difference between an inventory and a to-do list. Classification is layered: operator-defined location rules match first (first match by priority wins, editable without a deploy), then a semantic classifier reasons from what the asset is — holding a private key means the key material is yours; a certificate whose CN/SAN matches one of your own scanned domains is yours (or your public CA's, if one issued it); a locally-minted self-signed certificate is yours; a code-signing or timestamping certificate belongs to the software vendor that shipped it; and any other CA certificate is a trust anchor owned by the issuing CA. Only what survives both layers lands in Unknown for human review.

Executive Order Alignment

On June 22, 2026 the White House signed "Securing the Nation Against Advanced Cryptographic Attacks" — the executive order that turns post-quantum migration from guidance into mandate. It sets two hard deadlines: federal high-value assets and high-impact systems must use post-quantum cryptography for key establishment by December 31, 2030 and for digital signatures by December 31, 2031, with federal contractors required to meet post-quantum FIPS by end of 2030. The run-up is fast — and already underway. OMB issued its binding execution memo on June 24, 2026, two days after the order: every agency owes OMB a PQC Migration Plan within 120 days — roughly October 22, 2026 — and the memo names its first phase (2026–2027) explicitly: inventorying cryptographic systems. Around that sit the order's other clocks: agency PQC migration leads within 30 days, the first proposed contractor FAR rule within 180 days, NIST revising the Cryptographic Module Validation Program within 180 days to accelerate PQC module validations, and — the part aimed squarely at tooling — CISA/NIST guidance within 270 days defining the minimum elements of a Cryptographic Bill of Materials, which must "enable the automated assessment of the cryptographic assets utilized by a hardware or software element." Section 6 goes further still and directs OMB, the Department of War, NASA, and GSA to establish "shared procurement of PQC tools" — the order doesn't merely permit agencies to buy cryptographic discovery tooling, it organizes how they will buy it.

The Discovery Agent and its CBOM export were built for exactly that shape of obligation: discover the estate, classify what's quantum-vulnerable and who can fix it, and emit the evidence in a format a machine — not just an auditor — can assess.

Stated plainly, because credible alignment includes its bounds: the CISA/NIST minimum-element guidance itself is not yet published (due ~March 2027), so conformance today targets CycloneDX 1.6 — the only widely adopted CBOM format and the one that guidance is expected to reference. Anything the final guidance names beyond the spec's fields is already carried in the export's namespaced properties and can be promoted without a schema change. And ECC assets are classified as key-agreement, so ECDSA signing certificates land in the 2030 rather than the 2031 bucket — both classes are equally quantum-vulnerable, so migration urgency is unaffected.

Technical Stack

Use Cases

Using the Compliance Dashboard

Every scan submission lands here. The Compliance Dashboard is one page with everything scoped consistently — pick a device once, and every table on the page narrows to it.

Security Characteristics

Frequently Asked Questions