DUAL-SIGNING TRANSITION REVIEW

Dual-Signing Transition Review

An estate in transition signs everything twice — the classical signature its verifiers trust today and the post-quantum signature they will have to. The pair is a construction in its own right, and it fails in ways a conventional signing review never examines: a fallback path that quietly accepts one signature alone, a binding nobody wrote down, an encoding with two valid orders. This review reads the pair itself — its shape, its binding, its exceptions and its verifiers — across every pipeline that signs.

Request a demo The Theos Method

AutoPQC · dual-sign proof

release-pipeline
ECDSA + ML-DSA-65
OK
token-issuer
RS256 only
HIGH
artifact-verifier
enforces both
OK
legacy-verifier
classical-only
MED
canon-check
single encoding
OK

the pair: composed · bound · ordered · verified

Duration: [PLACEHOLDER: engagement duration, Dual-Signing Transition Review]
Method: theos-method-v1.0
Surface: The signature pair
Depth: Compose · bind · verify
Artefact: Register + attestation
Standards: FIPS 204 · 205

The starting point

Two signatures can be weaker than one.

The point of signing twice is that both must fail before trust does. Composed carelessly, the arrangement inverts: a fallback path accepts one signature alone, a missing binding lets half the pair travel as the whole, a second valid encoding makes two artefacts of one. An estate can hold two sound algorithms in an unsound arrangement — and the arrangement is what this review reads.

Scope

In scope, and not in scope

In scope

The composition inventory: every place the estate emits a classical and post-quantum signature together, and the shape each pipeline uses — side by side, wrapping, or bound into one object.
Binding: whether each signature covers a statement that the other exists, so neither half can be presented alone as the whole.
Fallback acceptance: every code path that will accept a single signature — legacy verifiers, error handlers, feature flags — and whether each is a dated, named exception or an accident.
Order and canon: whether the pair has exactly one valid encoding and ordering, so no permutation of the same signatures yields a second artefact that verifies.
Verifier parity: whether every verifier in scope enforces both signatures, or the guarantee quietly degrades to the oldest verifier still running.
The transition-window register: the dated exceptions that make the window honest, with owners and expiry.

Not in scope

The broader signing estate — pipelines that do not yet dual-sign are the Signing & Identity Review's subject, not this one's.
On-chain, wallet and smart-contract signing schemes, which are outside our practice entirely.
Building or operating the signing service itself; the ordered change plan is Migration Engineering's work.
Certifying implementations of the algorithms — conformance testing belongs to accredited laboratories, and we cite their results rather than reproduce them.

Surfaces

What we look at

01
Release and build pipelines
Where artefacts acquire the pair: which step signs classically, which signs post-quantum, and whether both happen before anything ships or one is appended after the fact.
02
Token and assertion issuers
Session tokens, service assertions and federation material mid-transition, where the pair's lifetime is minutes rather than years and composition mistakes iterate quickly.
03
The verifier population
Every consumer of a signed artefact, inventoried: which enforce both signatures, which enforce one, and which decide based on a header the artefact itself controls.
04
The exception register
Feature flags, compatibility switches and legacy allowances that permit single-signature acceptance, each read as a dated liability rather than a setting.
05
Encoding and canon
The byte-level representation of the pair: one canonical order, one encoding, and no second serialisation of the same signatures that still verifies.

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

Findings are scored under the published Theos Method across its five dimensions — Primitive Fragility, Confidentiality Horizon, Reachability, Change Cost and Substitution Gap — with the weights and tier boundaries stated in full at /methodology, not restated here. A composition finding scores against the pair, not the primitives: two sound algorithms in an unsound arrangement score as the arrangement.

Read the method specification

Deliverables

What you receive

01
Primary artefact
Composition register
CSV + PDF
Every dual-signing pipeline with its shape, binding, encoding and verifier population — the pair's inventory, sortable and exportable.
02
Binding findings
Written findings + proposed fixes
Where a signature fails to cover the pair's existence, with the concrete change that closes it.
03
Fallback path register
Register, severity-ordered
Every path that accepts one signature alone, classified as dated exception or defect, each with an owner.
04
Order-and-canon analysis
Findings + test vectors
Permutation and re-encoding checks on the pair, with vectors your own pipeline can replay.
05
Layer score and Posture Attestation
Signed attestation
The layer scored under the method version named on the document, verifiable through the Attestation Lookup.
06
Standards mapping
Clause-by-clause table
Each finding mapped to FIPS 204, FIPS 205 and the IETF hybrid-signature design-space draft, ready for a regulator's questionnaire.

Evidence

Evidence and reproducibility

theos-method-v1.0

Every finding names the pipeline, the artefact, the verifier and the check that raised it, and the test vectors in the analysis are replayable against your own estate. Re-run the review's checks and you reproduce the review's findings — see /knowledge/reproducing-our-numbers for the standing commitment.

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, Dual-Signing Transition Review]
Access: Read access to pipeline definitions, verifier configurations and a sample of signed artefacts. No signing keys, ever.
Prerequisite: At least one pipeline already emitting a classical and post-quantum signature together — estates not yet dual-signing start with the Signing & Identity Review.
Output: Composition register, findings, the transition-window register, and a Posture Attestation for the layer.

Questions

Questions we are asked

Why is this its own review: Because the pair is its own construction. A signing review asks whether each signature is sound; this review asks whether the arrangement of the two is — binding, fallback, order, parity. Estates pass the first and fail the second, and the failure is invisible until someone exercises a path nobody registered.
We have not chosen our post-quantum scheme yet: Then this review is early. The Signing & Identity Review reads your current estate and its composition section sets out the choices; this engagement assumes a pair already in production and reviews how it is put together.
Is this the Signing & Identity Review under another name: No. That review covers the whole signing estate — pipelines, tokens, documents, host keys — at inventory depth. This one assumes the transition has started and goes to full depth on a single construction: the dual-signature pair.
What this engagement will not tell you: It will not tell you whether your chosen algorithms are correctly implemented — that is conformance testing, and it belongs to accredited laboratories. It also will not review the pipelines that have not started dual-signing; those belong to the Signing & Identity Review.
Which pipelines and formats do you read: Build and release pipelines, artefact and container signing, token issuance and document sealing, in the formats the estate actually uses. Where a format is exotic, the composition questions do not change — shape, binding, fallback, order, parity — and we state plainly anything we could not read.

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 Dual-Signing Transition 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