What we ask for, and what we never ask for
The access an engagement asks for, and the four things we decline every time: private keys, production credentials, plaintext secrets and write access.
On this page — 5 sections
This is a short article to state and an important one to get right. An engagement reads metadata, configuration and inventory data. It does not read secrets, it holds nothing on your behalf, and it cannot change anything. What follows is that claim in enough detail for your own security reviewer to approve an access request without needing a call.
The four things we never ask for
These are absolute. They do not vary by engagement, by scope, by sector, or by how much faster the work would go with them.
- Private keys
- No key material of any kind. No private signing keys, no exportable backups, no wrapped material, no escrow copies. We record algorithm, size, purpose, state, custody boundary and rotation history, and none of that needs the key.
- Production credentials
- No administrative credential and no standing access to a live system. Where a setting can only be observed from a running service, we read it from your configuration management or from a non-production environment, and the finding says which.
- Plaintext secrets
- No secrets in the clear: not in a document, not in a ticket, not in a chat message, and not attached to a report as evidence. A secrets store is inventoried by what it holds and under which algorithm, never by its contents.
- Write access
- No ability to change anything. No certificate signing authority, no ability to use a key, no write access to an issuer, and no ability to make a production change ourselves. Your teams hold production throughout.
If any of the four is offered, we decline it. That is not a courtesy. Holding material we have no use for would create an exposure for you and a liability for us, and it would make the engagement harder to defend to your auditor rather than easier.
If someone asks anyway
Nobody acting for Theos Quantum will ask you for a private key, a production credential or a secret in plaintext, on any channel, at any point in an engagement. A request that does is either not from us or is a mistake we want to hear about. Do not send the material, and report it through Security & Disclosure.
What we do ask for
Every category below has a read-only form, and each is named on the inputs sheet of the engagement that needs it.
| What we ask for | What it covers |
|---|---|
| Scope in writing | The repositories, environments, hostnames, certificate authorities, key services or host fleets in scope, agreed before anything starts. |
| Source and build metadata | Dependency manifests, the library versions a build resolves, container base images, and the pipeline steps that sign what you ship. |
| Deployed configuration | Cipher suites, algorithm parameters and protocol versions as deployed rather than as documented. Where the two differ, both are recorded. |
| Certificate inventories | Issuers, chains, key types, key sizes and validity windows, including internally issued material and trust anchors nobody currently owns. |
| Key metadata and policy | Algorithm, size, purpose, state, custody boundary and rotation history. Metadata, never material. |
| Issuer metadata and published key sets | Token and assertion signing configuration, published key sets, and host key inventories. |
| A representative environment and a load profile | Somewhere to measure the performance impact of a change, and traffic that resembles production. Migration Engineering only. |
Why metadata is enough
The questions an engagement answers are which cryptography exists, how exposed it is, and what replacing it would cost. All three are answerable from the properties of a key rather than from its value. An RSA-2048 signing key is fragile because it is RSA-2048; reading the modulus changes nothing about the score. The same holds for a cipher suite, a certificate chain and a token issuer. The observable behaviour is the evidence, and the secret is not part of it.
The constraint does have one cost, and we would rather name it than let a reader discover it. We cannot confirm that the contents of a key store match its inventory, because confirming that would mean reading the contents. Where the distinction matters, each finding records which grade of evidence it rests on, so a reader can tell an observation apart from a configuration statement.
What the Evidence Pack contains
Every engagement in the catalogue produces an Evidence Pack: detector outputs, configuration captures, key metadata exports and version metadata, with a sha256 manifest so a reviewer can confirm nothing moved between assessment and report. It holds metadata and observations. It holds no key material and no secrets, which is what makes it safe to hand to an auditor or a customer without a further review of its contents.
Out of scope
We take custody of nothing. There is no key escrow, no credential vault, no digital asset custody, and no arrangement under which we hold material on your behalf. We also do not need, and will not accept, customer data, board minutes, or anything covered by legal privilege. Two consequences follow directly, and both are better stated here than discovered later. We cannot recover a lost key or repair a failed escrow arrangement, only describe the exposure. And we cannot tell you that a key has been misused: detecting misuse is a monitoring and forensics question, and an inventory and lifecycle review is not one.
Answering your own security reviewer
Access requests stall in review far more often than they are refused. Four statements usually clear the queue, because they answer what a reviewer is actually asking.
- The engagement reads metadata, configuration and inventory data. It does not read key material or secrets, and it is not a penetration test.
- The access is read-only. No credential issued for an engagement can change a configuration, sign anything, or use a key.
- The credentials stay under your control. Your team issues them, scopes them to the sources agreed in writing, and can revoke them at any point without us being involved.
- A refused source is not a blocker. It is recorded as a documented blind spot in the output, which is a better outcome than an approval nobody was comfortable giving.
What we hold once an engagement has produced something, for how long, and under whose keys is set out in What we hold, and what we never take and Retention and deletion. If a reviewer needs an answer to a question those do not cover, ask through our contact page and we will answer that specific question in writing.
Each engagement page carries its own inputs sheet, including the line stating what we never ask for.Engagement catalogueMore in Data & privacy