Signing & Identity Review

SIGNING & IDENTITY REVIEW

A forged signature is a quieter failure than a decrypted session, and usually a more expensive one. A Signing & Identity Review establishes what your organisation signs, with which algorithms, under whose authority, and how a verifier would notice if that authority changed. We follow the signing paths that matter: release artefacts, service tokens, federation assertions, documents and administrative access. The output is a scored view of every signing relationship in scope, and a plan for replacing the ones that cannot survive a quantum-capable adversary.

Request a demo The Theos Method

AutoPQC · signing surfaces

ci-release-pipeline
RSA-2048
HIGH
container-registry
ECDSA-P256
MED
jwt-issuer
RS256
HIGH
doc-sealing
SHA-256
OK
ssh-host-keys
Ed25519
MED

targets: ML-DSA-65 · SLH-DSA-128s — FIPS 204 / 205

Duration: [PLACEHOLDER: engagement duration, Signing & Identity Review]
Method: theos-method-v1.0
Surface: Signing & identity
Depth: Pipelines · tokens · hosts
Artefact: Layer report
Standards: FIPS 204 · 205

The starting point

A forged signature does not announce itself.

Signing is the layer where failure arrives dressed as success: a release that verifies, a token that validates, a document that seals — under an algorithm that no longer proves what it once did. The review reads every place the estate asserts identity or provenance, because the first forged artefact will look exactly like all the honest ones.

Scope

In scope, and not in scope

In scope

Code signing and artefact provenance: release signing keys, container image signatures, package signing, and how verification is enforced at deployment.
Token signing: JSON Web Token issuers, signing algorithms in use, key rotation behaviour, and published key sets.
Federation assertion signing across SAML and OIDC: assertion and metadata signing algorithms, certificate rotation, and what a relying party accepts.
Document signing where it carries legal or regulatory weight, including the retention period a signature must remain verifiable for.
SSH host and user keys: algorithms, key sizes, certificate-based SSH where deployed, and the inventory of authorised keys nobody has pruned.
Verification behaviour: whether a failed signature actually blocks anything, and which paths accept unsigned material today.

Not in scope

Penetration testing and adversarial simulation. We review signing relationships; we do not attempt to forge or bypass them.
Malware analysis and endpoint detection. A signed binary that misbehaves is a detection problem, not a cryptographic one.
Identity governance: role design, entitlement review, joiner and leaver process, and privileged access workflow.
Source-code correctness review. We check that artefacts are signed and verified, not that their contents are correct.
Key recovery. A lost signing key cannot be reconstructed by us, and we will not attempt to.
Anything on a public blockchain. No on-chain signature analysis, no wallet or address exposure work, no custody of any kind.

Surfaces

What we look at

01
Release and artefact signing
Which artefacts are signed, by which key, held where, and whether the deployment path refuses an artefact that fails verification or merely logs it.
02
Token issuance
Token signing algorithms in use across issuers, key rotation cadence as observed, published key sets, and any consumer still accepting a downgraded algorithm.
03
Federation and assertion signing
SAML and OIDC signing material, its issuers and expiry, and the coordination cost of changing an algorithm every relying party has to accept.
04
Document and record signing
Signatures that must remain verifiable for a stated retention period, which is where signature longevity and archive policy have to agree.
05
Administrative access keys
SSH host keys, user keys and authorised-key inventories, including keys with no current owner and hosts presenting algorithms nobody chose.
06
Trust distribution
How verifiers learn which keys to trust, and what has to happen everywhere else before a signing key can be replaced anywhere.

The transition, composed

Two signatures, one artefact

An estate mid-transition signs everything twice: the classical signature its verifiers already trust, and the post-quantum signature they will have to. How the pair is put together is a security decision in its own right, and it is where transition estates fail in ways a conventional review never looks at. Five questions decide whether a dual-signing arrangement is sound.

What a signature weighs · published sizes

ECDSA P-25664 bytes — the classical signature verifiers trust today
ML-DSA-65 · FIPS 2043,309 bytes — the primary post-quantum signature
SLH-DSA-128s · FIPS 2057,856 bytes — the conservative hash-based co-signature

Sizes are the published FIPS parameter-set figures, not measurements of ours. The weight difference is why composition is designed, not appended.

01 · Composition shape

Is the way the two signatures travel together — side by side, one wrapping the other, or bound into one object — stated once and used everywhere, or decided ad hoc per pipeline?

02 · Context binding

Does each signature cover a statement that the other exists, so neither can be lifted out of the pair and presented alone as if it were the whole story?

03 · Fallback discipline

Which code paths accept a single signature — legacy verifiers, error handlers, feature flags — and is each one a dated, named exception in the register or an accident nobody has met yet?

04 · Order and canon

Is the pair encoded in exactly one canonical order and encoding, so swapping, re-encoding or duplicating elements cannot yield a second artefact that still verifies?

05 · Verifier parity

Does every verifier in scope enforce both signatures, or do only the newest ones — leaving the transition's guarantee only as strong as the oldest verifier still running?

Stated against

NIST FIPS 204 — the module-lattice signature standard the primary post-quantum signature is drawn from.
NIST FIPS 205 — the stateless hash-based standard behind the conservative co-signature option.
IETF PQUIP — hybrid signature spectrums (working draft) — the design-space map for composite and dual signatures the review's vocabulary aligns with.

Scoring

How it is scored

Signing findings are scored under the Theos Method using the same five dimensions as every other engagement: Primitive Fragility, Confidentiality Horizon, Reachability, Change Cost and Substitution Gap. Signing behaves differently from transport under two of them. Confidentiality Horizon matters less, because a signature is verified now rather than read decades later, while Substitution Gap frequently dominates, because a signing algorithm can only change once every verifier will accept the new one. Change Cost captures that coordination load directly. The weights sit on the methodology page and are stated only there.

Read the method specification

Deliverables

What you receive

01
Primary artefact
Exposure Register (CSV)
CSV, one row per asset
Every signing key, issuer and verification path in scope, with its algorithm, classification, score, tier and current owner.
02
Posture Attestation
Signed attestation, reference format TQ-PA-YYYY-XXXXXX
The signed record that the signing and identity 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 and re-algorithm signing keys, arranged so verifiers are ready before issuers change.
04
Evidence Pack
Archive with a sha256 manifest
Key metadata, issuer configuration and verification-path observations behind each finding, hashed for review.
05
CBOM (CycloneDX)
CycloneDX JSON
The signing 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

Every signing finding names the key or issuer it describes, the surface it was observed on, and whether verification was tested or read from configuration, because those are different grades of evidence and we do not blend them. Scores are pinned to theos-method-v1.0 and the version is carried into each export. The re-derivation procedure, including how to reach the same tier from the same inputs, is set 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, Signing & Identity Review]
Scope you nominate: The signing keys, token issuers, federation relationships and host fleets in scope, agreed in writing before we begin.
Access we need: Read-only access to signing configuration, issuer metadata, published key sets and host key inventories.
People we need: The release engineering owner, the identity platform owner, and whoever administers the host fleet.
What we never ask for: Private signing keys, the ability to sign anything, production credentials, or write access to an issuer.
Handover: A walkthrough of the sequencing plan with release engineering and the identity platform team together, since neither can move alone.

Questions

Questions we are asked

Why review signing at all if the risk is decryption: Because the two have different clocks. Recorded traffic can be decrypted years after capture, so confidentiality is a retroactive problem. A forged signature is a live problem the day the primitive falls, and replacing a signing algorithm takes longer because every verifier has to accept it first.
Do you need our signing keys: No. We record algorithm, key size, custody location, rotation behaviour and verification enforcement. None of that requires private key material, and we will decline it if offered.
What this engagement will not tell you: It will not tell you whether a signed artefact is trustworthy in content. Verification proves origin and integrity, not correctness, and a properly signed release can still be defective. It also will not assess your identity governance: who should hold an entitlement is outside this scope.
Can we move to a post-quantum signature algorithm now: In some paths, yes, and in others the constraint is your verifiers rather than your issuers. We record which paths support FIPS 204 or FIPS 205 today, which are blocked by a dependency, and what the interim posture should be for each.
How do you handle long-lived document signatures: By comparing signature lifetime against the retention period the record actually has. Where a document must remain verifiable well beyond the safe life of its signing algorithm, that gap is recorded as a finding rather than treated as an archive detail.

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 Signing & Identity 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