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.

Request a demo The Theos Method

AutoPQC · key custody

kms-primary
AES-256 root
OK
hsm-cluster
FIPS 140-3
OK
secrets-store
static tokens
HIGH
rotation-policy
annual
MED
backup-region
replicated
MAP

custody boundaries drawn · rotation runway scored

Duration: [PLACEHOLDER: engagement duration, Key Management Review]
Method: theos-method-v1.0
Surface: Key custody
Depth: KMS · HSM · secrets
Artefact: Layer report
Standards: FIPS 203 · 140-3

The starting point

Custody is the layer that fails quietly.

Keys do not expire loudly the way certificates do. A rotation policy that lapsed, a backup region holding older material, a secrets store that outgrew its access list — none of it pages anyone. The review reads custody end to end, because a migration executed on top of unmapped custody moves the algorithms and leaves the exposure where it was.

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.

Custody, in depth

The custody stack, layer by layer

A key estate is not one thing — it is a stack, and in most estates every layer of it is classical: the roots, the envelopes around each key, the channels keys travel over, the escrow deposits, the ceremonies, the recovery paths and the trail that records all of it. A review that reads only the top layer certifies the paint. This is the stack the review actually walks, with what is typically classical at each layer today and the transition move planned for it.

01 · Root keys

Typically today

RSA and ECC roots living in managed key services and hardware modules

The transition move

Vendor post-quantum key types adopted as firmware lines ship them — with the wait recorded as a dated constraint, not ignored

02 · Wrapping at rest

Typically today

Data keys and exported material sealed under classical envelope encryption

The transition move

Hybrid re-wrap under ML-KEM-768, with envelope-version metadata so old and new wrapping coexist during the changeover

03 · Distribution channels

Typically today

Key material crossing service boundaries over classically-established channels

The transition move

Hybrid establishment on every channel a key crosses, because a recorded channel is a recorded key

04 · Escrow and backup

Typically today

Split-knowledge backups and escrow deposits sealed once and kept for years

The transition move

Re-seal on a schedule — a recorded escrow deposit is harvestable in exactly the way recorded traffic is

05 · Rotation ceremonies

Typically today

Quorum ceremonies that re-establish custody without changing what the estate trusts

The transition move

A rehearsed refresh path that migrates the wrapping without rotating public identity — proven before it is needed

06 · Short-lived material

Typically today

Session keys, cached derivations and pre-computed material outliving their purpose on disk

The transition move

Volatile-memory discipline with measured lifetimes, so nothing short-lived persists long enough to be worth harvesting

07 · Recovery paths

Typically today

Administrator break-glass over hardware tokens and classical attestations

The transition move

Hybrid attestation on recovery, because the emergency door must be as durable as the front one

08 · The custody trail

Typically today

Ceremony records and access events signed classically and retained for the regulator

The transition move

Dual-signing on records that will still be read long after the classical signature stops proving anything

Ceremony quorum · 3-of-5 · illustrative

Ceremony arithmetic — illustrative. The review reads who holds each share, where the threshold sits, and whether the refresh ceremony has ever actually been run.

Where a layer depends on a vendor's post-quantum support, the vendor's published posture lives in the Compatibility Reference — the review cites it rather than restating it.

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 specification

Deliverables

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-XXXXXX
The 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 sha256 manifest
Key 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

theos-method-v1.0

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.

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, 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.
We already have SOC 2 — does this overlap: Barely. SOC 2 examines whether operational controls exist and operate as described; it never asks whether the mathematics underneath those controls will still hold. This review reads the primitives themselves — what wraps each key, what establishes each channel — and scores their durability. The two reports answer different questions, and the parties asking for them increasingly want both.

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 Key Management Review 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