Estate Inventory

ESTATE INVENTORY

Most organisations cannot answer the first question a regulator asks: where is cryptography used, and by what. An Estate Inventory answers it from the estate itself rather than from a questionnaire. We read the repositories, pipelines, configuration and certificate stores you nominate, identify the cryptographic assets in them, and score each one under a published method. What you keep is a machine-readable bill of material and a register that names every asset, where it was found, and why it was classified the way it was.

Request a demo The Theos Method

AutoPQC · estate register

payments-svc/sign
RSA-2048
HIGH
edge/tls-terminator
ECDHE-P256
HIGH
vault/kms-keyring
AES-256-GCM
OK
ci/release-sign
ECDSA-P256
MED
archive-svc/store
3DES
HIGH

Illustrative — synthetic reference estate, not customer data · 42 assets · 36 outside Contained · 75/100

Duration: [PLACEHOLDER: engagement duration, Estate Inventory]
Method: theos-method-v1.0
Surface: The whole estate
Depth: Source · build · config
Artefact: Scored register
Standards: FIPS 203 · 204 · 205

The starting point

The register you do not have is the risk you cannot size.

Cryptography accumulates the way infrastructure does — a library pinned in 2016, a signing step copied between pipelines, an internal CA nobody owns. None of it is on one page, so every migration estimate is a guess with a confidence interval nobody will write down. The inventory exists to replace that guess with a register.

Scope

In scope, and not in scope

In scope

Source trees and dependency manifests for the repositories you nominate, including cryptographic libraries pulled in transitively.
Build and release chains: signing steps, container base images, and the toolchains that produce shipped artefacts.
Configuration as deployed rather than as documented: cipher suite lists, algorithm parameters, protocol versions and library defaults.
Certificate inventory: leaf and intermediate X.509 material, issuers, key types, key sizes and expiry dates.
Keys and secrets recorded at the inventory level: which store holds them, under which algorithm, inside which custody boundary.
Classification and scoring of every asset discovered, with the evidence for each classification retained alongside it.

Not in scope

Penetration testing and red teaming. We read the estate and describe what is in it; we do not attack it.
Malware, endpoint detection and response, and host-integrity questions of any kind.
Source-code correctness review. We locate cryptographic use. We do not review application logic, and a clean inventory is not a statement that the code is sound.
Identity governance: joiner, mover and leaver process, entitlement review, and access recertification.
Cloud security posture management and general misconfiguration scanning outside cryptographic settings.
Anything on a public blockchain and anything custodial. We do not scan addresses, wallets or contracts, and we hold nothing on your behalf.

Surfaces

What we look at

01
Repositories and dependency manifests
Direct and transitive cryptographic dependencies, the versions actually resolved at build time, and the primitives each one exposes to the application above it.
02
Build and release pipelines
Where artefacts are signed, which base images they inherit, and which algorithms the toolchain chooses when nobody has stated a preference.
03
Deployed configuration
Terminator and service configuration read as it runs. Documented intent and deployed reality diverge often enough that we record both and report the gap.
04
Certificates and trust stores
Issuers, chains, key types, key sizes and expiry dates, including internally issued material and trust anchors nobody currently owns.
05
Key and secret stores
KMS and HSM inventories and secrets stores, recorded by algorithm and custody boundary. We record what exists; we never read key material.
06
Inherited and undocumented use
Cryptography that arrived with a vendor appliance, an acquired system or a decommissioned project, and that no current owner will volunteer in a survey.

Scoring

How it is scored

Every asset in the register is scored under the Theos Method across five dimensions: Primitive Fragility, Confidentiality Horizon, Reachability, Change Cost and Substitution Gap. The first three describe how badly a break would land; the last two describe how hard the asset is to replace. Each dimension is derived by deterministic rules from the evidence collected during discovery, so two assessors reading the same estate reach the same figure. The relative weight of each dimension is published on the methodology page and stated only there, so there is exactly one place to check it.

Read the method specification

Deliverables

What you receive

01
Primary artefact
CBOM (CycloneDX)
CycloneDX JSON
A cryptographic bill of material for the assessed scope, structured to sit alongside an existing SBOM pipeline rather than replace it.
02
Exposure Register (CSV)
CSV, one row per asset
Every discovered asset with its location, primitive, classification, score, tier and the detector that found it. This is the working file your owners triage from.
03
Posture Attestation
Signed attestation, reference format TQ-PA-YYYY-XXXXXX
The signed record that a named scope was assessed on a named date under a named method version. Its reference can be checked at Attestation Lookup by a third party with no access to the estate itself.
04
Evidence Pack
Archive with a sha256 manifest
Detector outputs, configuration captures and version metadata behind each finding, hashed so a reviewer can confirm nothing moved between assessment and report.

Evidence

Evidence and reproducibility

theos-method-v1.0

Nothing in the register is asserted without a trace behind it. Each row names the detector that produced it, the input it read, and the method version it was scored under, and that version travels with the number into every export. The run is pinned to theos-method-v1.0, so a score can be re-derived later even after the method itself has moved on. If a reviewer wants to reproduce a figure rather than accept it, the procedure is written out in Reproducing our numbers.

Reproducing our numbers

The standards floor

What the work stands on

Eight standards, runtime and custody lines sit underneath every engagement in the catalogue. Each card names the groundwork the estate needs for it to land, and the failure mode it retires.

FIPS 203

ML-KEM — key establishment

The module-lattice key-encapsulation standard. It replaces classical key exchange in TLS 1.3 handshakes, tunnel establishment and key wrapping — the surfaces where traffic captured today can be stored against a future decryption.

Groundwork: A runtime line that can load a post-quantum provider, stated per service rather than assumed estate-wide.
Risk retired: Sessions recorded now being opened later, once the classical exchange underneath them falls.

FIPS 204

ML-DSA — digital signatures

The module-lattice signature standard, the replacement path for RSA and ECDSA signing across code, documents and server authentication. During a transition it runs alongside the classical signature rather than instead of it.

Groundwork: A signing pipeline that can carry two signatures on one artefact for the length of the transition window.
Risk retired: A forged release or a forged server identity signed by an algorithm that no longer resists forgery.

FIPS 205

SLH-DSA — hash-based signatures

The stateless hash-based signature standard: the conservative member of the family, resting on hash-function assumptions alone. Its natural home is firmware and other signatures that must still verify decades from now.

Groundwork: Room in the artefact path for a larger signature than the lattice schemes produce.
Risk retired: A structural surprise in lattice mathematics taking both primary schemes down at once.

Policy

CNSA 2.0 — the dated timeline

The published NSA algorithm suite sets dates, not suggestions: post-quantum operational across national-security systems by 2030, exclusive by 2035. Even estates far from that perimeter inherit its dates through their suppliers.

Groundwork: A register the timeline can be laid against, asset by asset, rather than a single estate-wide guess.
Risk retired: Discovering a contractual algorithm deadline in a procurement questionnaire instead of in your own plan.

Transition

Hybrid establishment — classical + ML-KEM

The transition posture for key establishment: derive the session from a classical curve and ML-KEM together, so a flaw in either primitive alone leaves the session standing. Mainstream clients already advertise the combined group.

Groundwork: TLS 1.3 endpoints, and visibility into which peers negotiate the hybrid group and which quietly do not.
Risk retired: Betting the confidentiality of day-one traffic on a single primitive, new or old.

Runtime

The provider-capable runtime line

Post-quantum negotiation arrives through the runtime, and an estate pinned to older lines does not negotiate it. The version actually loaded per service is a finding in its own right, not a build-system detail.

Groundwork: Retiring the oldest runtime pins — or naming them in the register as accepted, dated exceptions.
Risk retired: One service negotiating hybrid while its neighbour, one pin behind, silently falls back to classical.

Tooling

Open post-quantum tooling, pinned

The open-source implementations the ecosystem tests against. Where they appear in an estate we record the exact build, because a reviewed library and a deployed library are only the same thing if their hashes say so.

Groundwork: A pinned build with its hash recorded in the register, not a floating dependency.
Risk retired: Drift between the implementation that was reviewed and the one that ships the following quarter.

Custody

KMS and HSM key custody

Where the keys actually live. Managed key services and hardware modules are adding post-quantum key types on their own schedules, and custody boundaries — who can wrap, rotate, restore — decide how a migration lands there.

Groundwork: Audit access to key inventories and rotation policy. Key material itself never crosses the boundary.
Risk retired: A replica, backup or recovery region migrating out of step with the primary it must mirror.

Inputs

Inputs and duration

Duration: [PLACEHOLDER: engagement duration, Estate Inventory]
Scope you nominate: The repositories, environments and certificate authorities in scope, agreed in writing before we begin.
Access we need: Read-only access to source, build metadata, deployed configuration and certificate inventories.
People we need: One platform or infrastructure owner, one application owner per in-scope system, and whoever holds the certificate inventory today.
What we never ask for: Private keys, production credentials, customer data, or write access to anything.
Handover: A walkthrough of the register with the owners named above, so triage starts with the people who will do it.

Questions

Questions we are asked

How complete can an inventory actually be: Complete for the scope you nominate, and silent outside it. We report coverage explicitly: which repositories, environments and stores were read, and which were not. An asset we never looked at is listed as uncovered, not as safe.
Do you need to run anything in production: No. Discovery reads source, build metadata, configuration and inventory data. Where a deployed setting can only be observed from a running service, we read it from a non-production environment or from your own configuration management, and we say which.
What this engagement will not tell you: It will not tell you whether your applications are secure. It finds and scores cryptographic use; it does not review logic, test for exploitable defects, or assess controls. It also will not tell you when a quantum computer will break a given primitive, because nobody can date that honestly.
How does this relate to an SBOM we already produce: It extends it. The CBOM models cryptographic assets in a CycloneDX shape, so it can be consumed by the tooling already reading your SBOM rather than sitting in a separate silo.
Can the register be re-run later: Yes, and the comparison is the point. A second run under the same method version shows which assets changed, which were remediated, and which appeared since the first pass.

Signed · Verifiable

Every engagement in the catalogue ends with a Posture Attestation you can verify.

The attestation names the scope, the method version and the date, and anyone holding its code can check it on this site.

See the specimen Attestation Lookup

Three articles that go further

The scope conversation

Take Estate Inventory to a scope conversation

Tell us the estate you have in mind and we will walk through what this engagement would cover, what it would produce, and where its boundary sits — before anything is signed. If you would rather put questions in writing first, write to us instead.

Book a consult Request a demo Back to the catalogue