What discovery will not do
The boundaries of a discovery run, stated plainly: no exploitation, no key extraction, no cryptanalysis, and no pretence of reaching systems we cannot reach
On this page — 8 sections
Most tooling documentation describes capability. This page describes refusal. It exists because the fastest way to lose a security team's trust is to be vague about what a tool does inside their estate, and because a security review of AutoPQC should be able to start from a written boundary rather than an inference.
The boundary, stated once
Discovery reads recorded cryptographic decisions and reports them with evidence. Every activity below sits outside that sentence, and none of it happens in a standard run. Where an item can be brought into scope at all, it requires written authorisation naming the systems, the window and the accountable owner on your side.
- No exploitation, and no proof-of-exploit.
- No interception of production traffic without written scope.
- No extraction, export, use or reconstruction of key material.
- No attempt to break, weaken or cryptanalyse anything.
- No reading of the contents of encrypted data.
- No claim of coverage over systems we could not reach.
We do not exploit
A weak cipher suite on a listener is reported as a weak cipher suite on a listener. We do not attempt a downgrade, do not attempt a padding oracle, do not fuzz a handshake and do not chain any observation into access. Discovery is an inventory exercise, and an inventory exercise that also breaks things is neither.
The practical consequence is that an AutoPQC finding is never accompanied by a working attack. If your remediation process requires demonstrated exploitability before a change is approved, that demonstration has to come from your own red team or an engagement scoped for it. We will say plainly that a configuration is vulnerable and cite the standard that says so. We will not prove it by doing it.
Not a penetration test
Discovery is not a penetration test, a vulnerability scan or an adversary simulation, and a discovery report does not satisfy a control that requires any of those. It answers a different question: what cryptography exists, where, and how exposed is it to a quantum-capable adversary.
Interception requires written scope
Some questions can only be answered from live traffic. Which parameters clients actually negotiate in aggregate, whether a legacy path is still in use, whether a deprecated suite is genuinely dead. Those answers are valuable, and we still will not collect them by default.
Passive observation of production traffic happens only under a written scope that names the network segments, the capture window, who operates the capture, and where the data lands. In most engagements it is not necessary at all: telemetry your own infrastructure already produces answers the same question without a new capture point. That route is preferred, and we will suggest it first.
Active interception in front of production, including any form of inline proxy that terminates a session we do not own, is not something we do in a discovery engagement under any authorisation. The risk to your availability is real and the same evidence is obtainable another way.
Key material stays where it is
Discovery reads key metadata. Type, size, algorithm, creation date, rotation policy, usage flags, enabled state, and which partition or vault an object lives in. It never reads the key.
| We read | We never read | Why the distinction holds |
|---|---|---|
| Key type, size, algorithm and curve | Private key bytes, in any encoding | Metadata is enough to assess quantum exposure; the key itself adds nothing to the assessment |
| Creation, rotation and expiry dates | Wrapped or exported key blobs | Lifecycle answers the agility question without possession |
| Usage flags and enabled state | Seed material, mnemonics, passphrases or recovery data | Nothing in the method requires them, so nothing requests them |
| Partition, slot and vault location | HSM partition credentials or backup files | Location supports remediation planning; access supports nothing we do |
| Public keys and certificates | Anything obtained by performing a cryptographic operation | Public material is already published to every client |
Out of scope
No credential we ask for carries decrypt, sign, wrap, unwrap, export or partition-login permission. If someone contacts you claiming to represent us and asks for a private key, a seed phrase, an HSM credential or a passphrase, it is not us. Report it through Security & Disclosure.
Encrypted content stays closed
Discovery frequently encounters encrypted objects: sealed secrets in a repository, encrypted volumes, ciphertext columns, signed and encrypted archives. It records their existence, the algorithm that protects them where that is recorded in metadata, and the location. It does not open them, and it has no path to opening them, because it holds no permission that would allow it.
The same rule applies to anything that looks like a credential. If a detector encounters what appears to be a secret in plaintext in a repository, it records the location and the fact, redacts the value, and raises it to your named contact through the agreed channel. It does not store the value and does not validate it against the service it belongs to.
We do not attempt cryptanalysis
AutoPQC assesses exposure to known algorithmic attack, principally Shor's algorithm against integer factorisation and discrete logarithms and Grover's algorithm against symmetric search. It reasons about what those results imply for a given primitive and key size. It does not run them, does not attempt to recover a key from a signature, and does not test whether a specific key is weak by trying to break it.
Where a primitive is assessed as vulnerable, that assessment comes from published analysis and from standards guidance such as NIST SP 800-131A and the transition to NIST FIPS 203, 204 and 205. It does not come from an experiment we ran on your estate. Claims we specifically refuse to make about quantum timelines are listed in Claims we refuse to make.
Vulnerable does not mean compromised
An asset classified vulnerable is one whose primitive is expected to fail against a future quantum-capable adversary, or which already falls short of current standards guidance. It is not a statement that anything has been broken, and it should not be triaged as an incident unless your own evidence points that way.
Where discovery cannot reach
Some parts of an estate are out of reach entirely, and saying so is more useful than a report that quietly omits them. Two categories dominate.
Air-gapped and isolated environments. If there is no network path and no credential, there is no collection. What works instead is an operator-run export: your team produces the configuration, certificate and key-metadata files from inside the enclave, and hands them over for offline ingestion. The resulting assets are marked as collected from an operator export rather than from a live surface, because the provenance is different and an auditor should be able to see that.
Third-party-hosted systems. Cryptography inside a SaaS platform, a managed service or a partner's infrastructure is visible to us only through what that provider publishes: the endpoints it exposes, the certificates it presents, the documentation and attestations it makes available. The internals are not visible without the provider's cooperation, and we will not represent an inference about them as a finding.
| Situation | What is achievable | What stays out of reach |
|---|---|---|
| Air-gapped enclave | Offline ingestion of an operator-produced export, provenance recorded | Live endpoint negotiation and anything requiring a network path |
| SaaS or managed platform | Externally observable endpoints, presented certificates, published attestations | Internal key management, at-rest algorithm choices, upstream dependencies |
| Partner or supplier estate | Whatever their own inventory or questionnaire response provides | Independent verification, unless they run discovery themselves |
| Embedded devices and OT | Firmware inventory and documented capability where a vendor publishes it | On-device inspection, unless the vendor supports a read-only interface |
What to do about the gaps
Gaps are reported as gaps, with the reason, and they carry through to the exposure report rather than being netted out of it. A run that covered six of eight surface families says so on its face. This is deliberate: an aggregate score computed over partial coverage is a misleading number unless the coverage travels with it.
- 01Read the coverage statement before the score. It bounds everything that follows.
- 02Decide, per gap, whether to close it with an operator export, a scoped credential, or a supplier request.
- 03Record accepted gaps with a rationale and an owner. Auditors accept a documented gap far more readily than a silent one.
- 04Re-run once a gap closes, and read the reconciliation to see what the new coverage changed.