Internal scanner

• Key exchange, across protocols. For each endpoint it completes a handshake offering only hybrid ML-KEM groups; a completed handshake confirms post-quantum support, a refusal confirms its absence. The port selects the protocol, so it covers not just HTTPS but mail (SMTP, IMAP, POP3, over STARTTLS) and databases (PostgreSQL, MySQL), where a great deal of internal traffic actually lives.
• SSH key exchange.Targets on port 22 or 2222 are probed as SSH. It reads the server’s advertised key-exchange and host-key algorithms and flags whether post-quantum key exchange (such as sntrup761x25519 or mlkem768x25519) is offered. It never authenticates or begins a key exchange.
• Whole ranges, not just named hosts. Give it a CIDR range like 10.0.0.0/24 and it discovers which hosts are listening on the common cryptographic ports, then probes each one, so nothing quietly falls off the inventory.
• Certificate and config files on disk. Point it at a directory of .pem/.crt files and it classifies each key. Point it at an sshd_config or nginx/Apache TLS config and it flags obsolete protocols, weak ciphers, and key exchange with no post-quantum method configured.
• Progress over time. Compared against a previous run, it reports what moved to post-quantum, what regressed, and what is new, which is the evidence a migration is expected to produce. In a CI pipeline it can fail the build when new quantum-vulnerable crypto appears.

It makes no connection to LatticeScan or anywhere else. It has no telemetry. It uses no credentials and stores nothing remotely. It reads only the files and hosts you name on the command line. The output is a file that stays on your machine. The whole program is a few hundred lines of standard-library code you can read before you run it.

Node.js 24 or newer, which ships the OpenSSL 3.5 required to test ML-KEM key exchange. On an older Node the scanner still runs and inventories certificates, but cannot confirm post-quantum key exchange, and says so.

Download the file, then run it against the hosts you want to inventory:

# a list of internal hosts, one host[:port] per line
node latticescan-internal.mjs targets.txt

# inline targets; the port selects the protocol
node latticescan-internal.mjs api.internal:8443 mail.corp:587 db.corp:5432 bastion:22

# discover and probe every live host in a range
node latticescan-internal.mjs 10.0.0.0/24

# inventory certificate files and audit a config
node latticescan-internal.mjs targets.txt --certs /etc/ssl/certs --config /etc/ssh/sshd_config

# track migration progress, and fail CI on quantum-vulnerable crypto
node latticescan-internal.mjs targets.txt --baseline last-quarter.json --fail-on classical,regression

# combine with your external report into one inventory
node latticescan-internal.mjs targets.txt --merge acme.com-cbom.json

It prints a summary to the terminal and writes a CycloneDX CBOM to disk. Keep each run’s CBOM and pass it as next quarter’s --baseline to see what moved. Download your external report from its scan page and pass it with --merge for one inventory covering both what faces the internet and what runs inside. Every file it reads is local; the scanner still connects to nothing but your own targets.

The federal guidance driving this transition (OMB M-26-15) names an automated cryptographic inventory, populated into a CBOM, as the foundation of the migration. That inventory has to cover the cryptography inside the organization as well as the endpoints facing the internet: internal PKI, key management, VPNs, databases, code signing, and machine identities. The external assessment establishes your public posture; the internal scanner is how you start accounting for the rest.

See the methodology for how the same test is applied externally, and the regulatory timeline for the obligations behind it.