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

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.

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

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.

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.

Request a demo Contact us