How discovery finds cryptography
The surfaces an estate presents, the difference between passive and authenticated collection, and why we ask for the smallest credential that still yields evidence
On this page — 7 sections
Discovery is the first phase of every engagement and the one everything else rests on. A risk score, a migration sequence and a standards mapping are worth exactly as much as the inventory underneath them. This article describes what discovery reads, how it reads it, and what it deliberately leaves alone.
A cryptographic surface, defined
Cryptography in a large estate is almost never recorded in one place. It is configured at a load balancer, baked into a container image, hard-coded in a batch job written twelve years ago, delegated to a hardware module in a data centre nobody visits, and inherited from a dependency nobody has read. A cryptographic surface is any location where one of those decisions is written down in a form we can read without altering it.
That definition sets the boundary of the exercise. Discovery gathers evidence about recorded decisions. It does not infer cryptography from behaviour it has not observed, and it does not test whether a control can be defeated. For a plain statement of the boundary, see What discovery will not do.
- Addressable. There is a host, a repository path, an image digest, a key handle or a configuration file we can point at.
- Durable. The decision persists between runs, so a second run can be compared with the first rather than replacing it.
- Parseable. The record has a defined shape: a certificate field, a handshake transcript, a manifest entry, a directive in a configuration file.
The surfaces we collect from
A standard run works through eight surface families. Most estates present all eight. Coverage of each is agreed in writing before the run, and any family excluded from scope is recorded as excluded rather than reported as clean.
| Surface family | What discovery reads | Minimum access that still yields evidence |
|---|---|---|
| TLS and mTLS endpoints | Negotiated protocol version, cipher suite, key-exchange group, signature algorithm, session resumption behaviour | Network reachability from an agreed scan origin |
| Certificate chains and internal PKI | Subject key algorithm and size at each chain position, signature algorithm, validity window, issuing authority | Certificates as presented, plus a CA inventory export where one exists |
| Source repositories and dependency manifests | Cryptographic call sites and their algorithm arguments, protocol pinning, key-generation parameters, crypto libraries and versions from lockfiles | A read-only token scoped to the repositories in scope |
| Container images and registries | Crypto libraries in each layer, embedded trust stores, statically linked cryptography in shipped binaries | A read-only registry pull credential |
| Key stores, key management services and HSMs | Key object metadata: type, size, algorithm, creation and rotation dates, usage flags, partition and mechanism inventory | A metadata-list role. Never an export, decrypt or sign permission |
| Remote access: VPN, SSH and jump hosts | Host key algorithms, permitted key-exchange, cipher and MAC lists, IKE proposals, client profile defaults | A configuration read, or an exported configuration file |
| Code signing and release pipelines | Signing algorithm, key custody location, timestamp authority, whether a verification gate exists before deployment | Read access to pipeline definitions |
| Data transports: brokers, queues and database listeners | Listener transport policy, client authentication mode, at-rest algorithm selection, driver fallback behaviour | A configuration read or an administrative metadata query |
Hardware security modules deserve a note of their own. We read the partition inventory, the firmware level and the list of mechanisms the module supports, including whether it offers any of the algorithms in NIST FIPS 203, 204 and 205. What we cannot see from the management interface is which of those mechanisms applications actually call. That gap is closed from the application side, by the source and configuration detectors, and the two views are reconciled rather than merged.
Passive collection
Passive collection observes what a system already publishes. A TLS handshake with an agreed endpoint, a certificate served to any client, a manifest in a repository we have been given read access to. Nothing is written, nothing is stored on the target, and no session belonging to anyone else is touched.
Passive work is where a run starts, because it is cheap, reversible and requires the least trust. It is also where the largest single tranche of assets usually comes from: perimeter and internal TLS, certificate chains, and the dependency graph of anything under version control.
- It tells you what a server negotiated with us, at one moment, from one network position.
- It does not tell you the full set of parameters a server would accept. Enumerating that set is a separate, explicitly scoped activity.
- It does not tell you whether a code path that imports a weak primitive is ever executed. That question belongs to scoring, not discovery.
Authenticated collection
Some evidence only exists behind a credential. Key metadata, HSM partition inventories, private repository contents, pipeline definitions and appliance configuration are all in that category. For those surfaces we ask for a named, scoped, revocable identity, and we tell you in advance which detector will use it and what it will read.
Credentials are requested per surface, not per estate. There is no single account with visibility across everything, because such an account would be the most valuable object we created during the engagement.
- Repositories
- Read-only, scoped to the repositories in scope. No write, no administration, no organisation-wide read.
- Container registries
- Pull-only on named repositories. No push, no tag deletion, no manifest mutation.
- Key management services
- List and describe on key metadata. Explicitly not decrypt, sign, wrap, unwrap or export.
- HSM management interface
- Read-only operator role. No partition login, no cryptographic operation, no backup.
- Appliances and servers
- Configuration read, or an operator-produced configuration export handed to us instead of live access.
- Pipelines
- Read on definitions and job history metadata. No ability to trigger, approve or modify a run.
An export is often enough
For appliances where a read-only role does not exist, a configuration export produced by your own operators is a perfectly good substitute. It is frequently the faster path, because it needs no new identity at all.
Why least privilege is the default, not the concession
The usual argument for least privilege is risk reduction, and that holds here. There is a second reason that matters more in practice: a narrow credential produces a cleaner claim. If a detector can only list key metadata, then every statement it makes is a statement about metadata, and nobody reviewing the report has to wonder whether we looked at something we should not have.
This is why we would rather report a surface as not collected than widen a credential to reach it. An honest gap is auditable. A broad permission used once is not.
Out of scope
Discovery never requests a permission that can use, export or decrypt key material, and never asks for a credential that would let us change the target. If a surface can only be read with such a permission, it stays out of scope and appears in the report as uncollected, with the reason stated.
How a run is sequenced
- 1
Scope in writing
Surface families, address ranges, repositories, registries and appliances are listed and signed off. Anything not listed is out of scope by default, not by omission.
- 2
Passive sweep
Reachability, TLS negotiation, certificate chains and anything else that requires no credential. This establishes a first inventory and a first count.
- 3
Credential handover
Scoped identities are created by your team, tested against a single read, and recorded with an expiry. Nothing is created by us on your systems.
- 4
Authenticated sweep
Repository, image, key store, HSM, pipeline and appliance detectors run against the surfaces they were given. Each emits evidence tagged with the detector and version that produced it.
- 5
Reconciliation
Evidence from different surfaces about the same underlying thing is collapsed into single assets under the rules in the asset model. Conflicts are kept as conflicts, not averaged away.
- 6
Evidence close-out
The Evidence Ledger panel records what ran, when, under which detector versions, and which surfaces were skipped. Credentials are handed back for revocation.
What comes out of a run
The output of discovery is an inventory, not a verdict. Each asset carries the evidence that produced it, the detector and version that emitted that evidence, a confidence characterisation, and a location precise enough for an engineer to go and look. Scoring runs afterwards, against that inventory, and is documented separately in How the exposure score is built.
In our pilot estate, discovery produced 42 cryptographic assets, of which 36 were classified vulnerable, giving an aggregate risk score of 75 / 100. The same estate took 22 hours of manual review to inventory by hand and 14 minutes with AutoPQC. Those figures describe one estate and are not a promise about yours.
- An asset inventory with stable identifiers, so run two can be compared with run one.
- Per-asset evidence, quotable in an audit response without re-running anything.
- A record of what was not collected, and why.
- A draft cryptographic bill of materials, described in Cryptographic bills of material.