KEY MANAGEMENT REVIEW
Key Management Review
An estate can hold thousands of keys and still not know how many it can rotate this quarter. A Key Management Review establishes what keys exist, which service or module holds each one, who can use it, and what would have to happen for its algorithm to change. We work at the inventory and lifecycle layer: creation, rotation, custody boundaries, escrow and destruction. The output is a scored key inventory and an honest account of where agility exists and where it has been designed out.
Scope
In scope, and not in scope
In scope
- Key inventory across managed KMS services and hardware security modules, recorded by algorithm, key size, purpose and current state.
- Custody boundaries: which keys never leave a module, which are exportable, and which are held by a third party on your behalf.
- Rotation in practice: which keys rotate on a schedule, which rotate only after an incident, and which have never rotated since creation.
- Secrets stores and the cryptographic material inside them, including credentials that are functionally keys but are not managed as such.
- Key lifecycle and escrow: generation, backup, escrow arrangements, revocation and destruction, and the evidence retained for each.
- Algorithm agility at the key layer: whether a key's algorithm can be changed without rewriting the systems that consume it.
Not in scope
- Custody of digital assets. We do not hold, move or advise on the safekeeping of any asset, and we operate no custody service.
- Threshold signature and multi-party computation wallet schemes. These belong to a different market and we do not review them.
- Key recovery. If a key is lost or an escrow arrangement has failed, we can describe the consequence. We cannot reconstruct the material.
- Penetration testing of a key store, and any attempt to extract material from a module.
- Identity governance and privileged access workflow. We review who can use a key at the policy level, not how your access requests are approved.
- Cloud security posture management generally. Non-cryptographic misconfiguration is a real problem and a different engagement.
Surfaces
What we look at
01
Managed key services
Key inventory per service and region, algorithms and sizes in use, key state, and the default choices applied whenever no algorithm was specified.
02
Hardware security modules
Partition and key inventory, firmware-constrained algorithm support, and which post-quantum primitives the installed generation can and cannot perform.
03
Custody boundaries
Where each key can be used and where it can travel, including exportable keys, wrapped backups and material held by a third party.
04
Rotation and lifecycle
Rotation as observed rather than as policy, plus the state transitions each key can actually undergo without a consuming system breaking.
05
Secrets stores
Cryptographic material managed as configuration rather than as keys, and the paths by which it reaches an application at runtime.
06
Escrow and destruction
Escrow arrangements, backup custody, revocation routes and destruction evidence, assessed against the retention obligations the data carries.
Scoring
How it is scored
Keys are scored under the Theos Method across Primitive Fragility, Confidentiality Horizon, Reachability, Change Cost and Substitution Gap. At the key layer the interesting pair is Change Cost and Substitution Gap: a key wrapped in a module that cannot perform a lattice-based primitive is not a configuration change, it is a procurement decision, and the score should say so. Confidentiality Horizon is taken from the data the key protects rather than from the key itself, which is why a rarely used archive key can outscore a busy session key. The weights live on the methodology page and only there.
Read the method specificationDeliverables
What you receive
01
Primary artefact
Exposure Register (CSV)
CSV, one row per asset
Every key and secret in scope with its algorithm, custody boundary, rotation state, classification, score and tier.
02
Posture Attestation
Signed attestation, reference format
TQ-PA-YYYY-XXXXXXThe signed record that the key management scope was assessed on a named date under a named method version, checkable at Attestation Lookup.
03
Remediation Sequencing Plan
PDF with a CSV work-item export
The order in which to rotate, re-wrap and re-algorithm keys, separating what a rotation job can do from what needs new hardware or a new service.
04
Evidence Pack
Archive with a
sha256manifestKey metadata exports, policy captures and lifecycle observations behind each finding, hashed for review. Metadata only, never key material.
05
CBOM (CycloneDX)
CycloneDX JSON
The key layer slice of the cryptographic bill of material, mergeable with an existing estate-wide CBOM instead of replacing it.
Evidence
Evidence and reproducibility
Findings are built from key metadata and policy, never from key material, and each row records which store it was read from and when. Scores are pinned to theos-method-v1.0 so a figure can be re-derived after the method has moved on, and the version accompanies every export. Where a module's post-quantum capability could not be confirmed from published vendor documentation, the row says so instead of guessing. Reproducing our numbers sets out the re-derivation procedure.
Inputs
Inputs and duration
- Duration
- [PLACEHOLDER: engagement duration, Key Management Review]
- Scope you nominate
- The key services, modules, secrets stores and escrow arrangements in scope, agreed in writing before we begin.
- Access we need
- Read-only access to key metadata, key policy, rotation history and module inventory. Metadata, not material.
- People we need
- The key management owner, a security architect, and whoever holds the vendor relationship for any hardware module in scope.
- What we never ask for
- Key material of any kind, exportable key backups, production credentials, or the ability to use a key.
- Handover
- A walkthrough of the register with the key management owner, including the rows we could not confirm and why.
Questions
Questions we are asked
- Do you ever handle our keys
- No. We read metadata and policy: algorithm, size, purpose, state, custody boundary and rotation history. We do not export, wrap, use or hold key material, and we will decline an offer of it.
- Is this a review of digital asset custody
- No. This engagement covers enterprise key management: managed key services, hardware modules and secrets stores. Custody of digital assets and multi-party wallet schemes are outside our practice entirely.
- What this engagement will not tell you
- It will not tell you whether a key has been compromised. Detecting misuse is a monitoring and forensics question and this is an inventory and lifecycle review. It also will not recover anything: if escrow has failed, we can describe the exposure but not repair it.
- Our hardware modules cannot do post-quantum algorithms yet
- That is a common finding and it belongs in the plan rather than in a footnote. We record the constraint, score the keys behind it accordingly, and place the procurement decision in the sequence at the point where it blocks other work.
- How do you treat credentials stored as secrets
- As cryptographic assets when they behave like one. A long-lived shared secret used to authenticate a service is inventoried and scored, even though nobody manages it in a key service.
Related reading
Three articles that go further
Discuss this engagement
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. If you would rather put questions in writing first, write to us instead.