DELEGATED ACCESS TRANSITION REVIEW

Delegated Access Transition Review

Modern estates run on delegated authority: a credential signed into existence, narrowed and handed on, exercised against a verifier, and — eventually — revoked. Every link in that chain is a signature, and the chain is only as durable as its weakest one. The link that rots first is the one exercised least: revocation, the emergency path everyone assumes works. This review walks the whole chain on an estate whose signing transition has begun, and reads the revocation paths hardest of all.

Request a demo The Theos Method

AutoPQC · delegation trace

01 issue · token-issuer
RS256
HIGH
02 delegate · scope-grant
bearer, unbound
MED
03 exercise · api-verifier
enforces issuer only
MED
04 revoke · invalidation
classical fallback
HIGH
break-glass · recovery
hardware attest
OK

one chain, traced end to end — weakest link scored first

Duration: [PLACEHOLDER: engagement duration, Delegated Access Transition Review]
Method: theos-method-v1.0
Surface: The delegation chain
Depth: Issue · delegate · revoke
Artefact: Register + attestation
Standards: FIPS 204 · CNSA 2.0

The starting point

Revoking trust is also a signed operation.

Every link in a delegation chain is a signature: the credential issued, the scope narrowed, the approval countersigned — and the revocation that ends it all. The revocation link is exercised least, reviewed last, and in most estates it falls back to the oldest signature in the building the moment something goes wrong. A chain whose emergency path is its weakest signature is a chain measured wrong.

Scope

In scope, and not in scope

In scope

Issuance: the signatures that bring tokens, session credentials and service identities into existence, and whether the issuer can change scheme without re-enrolling every holder.
Delegation: how authority is narrowed and handed on — scopes, impersonation, on-behalf-of chains — and whether each hop is bound to the one before it.
Session credentials: issuance, measured lifetime and rotation of short-lived material, read against the recording problem rather than the expiry date.
Countersigned approvals: the second signatures that authorise privileged actions, and what scheme they actually carry.
Revocation and expiry: every path that withdraws trust — including the paths that quietly fall back to a weaker signature when exercised.
Break-glass recovery: the administrator paths that bypass the normal chain, held to the same standard as the chain they bypass.

Not in scope

Wallet infrastructure, account-abstraction schemes and anything on-chain, which are outside our practice entirely.
Choosing an identity provider. Where a link waits on a vendor's post-quantum support, the constraint is recorded and the vendor's published posture cited from the Compatibility Reference.
The broader signing estate — pipelines and artefacts that are not part of a delegation chain belong to the Signing & Identity Review.
Building or operating the issuer; the ordered change plan is Migration Engineering's work.

Surfaces

What we look at

01
The issuance plane
Every service that signs credentials into existence: token issuers, session-grant services, certificate-backed service identity. What scheme each uses, and what it would take to change it.
02
The delegation graph
Who can hand authority to whom, through what mechanism, and whether each hop carries a statement binding it to the hop before — or is a bare bearer credential trusted on presentation.
03
The verifier population
Everything that accepts a delegated credential, inventoried — because a chain upgraded at the issuer and verified by a legacy consumer is upgraded in press-release terms only.
04
The revocation graph
Every withdraw-trust path: expiry, explicit revocation, emergency invalidation. Which are signed operations, what scheme signs them, and which fall back to something weaker than the authority they cancel.
05
The recovery path
Break-glass and administrative recovery: rarely exercised, rarely reviewed, and exactly as attractive to an adversary as the front door it bypasses.

The chain, in depth

One chain, four signed moments

Delegated authority moves through four moments, and each one is a signature with its own transition state. The review walks them in order, because a chain upgraded at one moment and classical at the next is only as moved as its weakest moment — and then reads the seven surfaces those moments run across.

01
Issue
A credential is signed into existence — typically under a classical scheme the issuer cannot easily change
→Issuance that can carry a composed pair, without re-enrolling every holder
02
Delegate
Authority is narrowed and handed on — often as a bare bearer credential, trusted on presentation
→Each hop bound to the one before it, so the chain is a chain and not a pile
03
Exercise
The credential meets a verifier — and the oldest verifier in the fleet decides what is actually enforced
→Verifier parity: every consumer enforces the same, current scheme
04
Revoke
Trust is withdrawn — through a path that quietly accepts the weakest signature in the estate
→Revocation at least as strong as the authority it cancels

The fallback trap

The failure this review reads hardest: a revocation or recovery path that, when exercised, falls back to a bare classical signature — cancelling post-quantum authority with a pre-quantum pen. It is rated at the severity of the strongest credential it leaves standing, because that is what an adversary gets by forcing the fallback.

01 · Issuance signatures

What signs each credential into existence, and whether the issuer can change scheme in place.

02 · Verification policy

The modules and rules that accept a credential, and whether they can swap verifiers without redeployment.

03 · Session lifetimes

Issuance, measured persistence and rotation of short-lived material, against the recording problem.

04 · Countersigned approvals

The second signatures on privileged actions, and the scheme they actually carry.

05 · Revocation paths

Every withdraw-trust route — expiry, explicit, emergency — and what each falls back to under stress.

06 · Recovery attestations

Break-glass signatures and attestations, held to the standard of the chain they bypass.

07 · Chain isolation

Whether one issuer's compromise stays one issuer's problem, or crosses scopes through a shared link.

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 weights and tiers stated in full at /methodology. Revocation findings score against the authority they fail to cancel: a weak revocation path inherits the severity of the strongest credential it leaves standing.

Read the method specification

Deliverables

What you receive

01
Primary artefact
Delegation-chain register
CSV + PDF
Every issuer, hop, verifier and revocation path in one register: scheme, lifetime, binding and fallback behaviour, sortable and exportable.
02
Issuer swap-readiness findings
Written findings + proposed fixes
Whether each issuer and verifier can move to a post-quantum scheme without re-enrolling every credential holder. Hard-wired scheme assumptions are named individually.
03
Session-credential exposure analysis
Analysis + measured lifetimes
Short-lived material read against the recording problem: what is actually persisted, for how long, and what a recorded credential still tells an adversary after it expires.
04
Revocation-path threat model
Register, severity-ordered
Every withdraw-trust path traced end to end. A revocation that falls back to a bare classical signature is a finding at the severity of what it fails to cancel.
05
Recovery readiness findings
Written findings
The break-glass paths, their signatures and attestations, and the upgrades that bring the emergency door up to the standard of the front one.
06
Layer score and Posture Attestation
Signed attestation
The delegation chain scored under the method version named on the document, verifiable through the Attestation Lookup.

Evidence

Evidence and reproducibility

theos-method-v1.0

Every finding names the issuer, the hop, the verifier or the revocation path it was read from, and the register's scores recompute under the published method from the register's own fields. 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, Delegated Access Transition Review]
Access: Read access to issuer configurations, verifier policies, delegation and revocation logs. No signing keys and no live credentials, ever.
Prerequisite: A signing transition already underway somewhere in the chain. Estates starting cold begin with the Signing & Identity Review.
Output: The delegation-chain register, the revocation-path threat model, and a Posture Attestation for the layer.

Questions

Questions we are asked

Why is this its own review: Because delegation fails as a chain, not as parts. An access review checks who may do what; this review checks whether the signatures carrying that authority — issuance, each hop, each approval, each revocation — survive the transition together. The chain's guarantee is set by its weakest signed link, and that link is usually one nobody has exercised recently.
How does this relate to the Dual-Signing Transition Review: They meet where a delegation chain dual-signs. This review covers the chain's architecture; if your issuers emit composed classical-plus-post-quantum pairs, the pair's own soundness — shape, binding, order — is that review's subject, and the two are natural companions.
Our session credentials only live fifteen minutes: A short lifetime shrinks the window in which a credential can be replayed; it does not shrink what a recorded one reveals. Issuance transcripts and the material inside them are recordable today and readable later, and the analysis treats measured persistence — not intended lifetime — as the exposure.
What this engagement will not tell you: It will not tell you whether your authorisation policy is right — who should be allowed to do what is your call, and an access-governance question besides. It also will not detect a delegation already abused; that is monitoring and forensics, not architecture review.
Which identity stacks do you read: The estate's own issuers and the standard federation, token and service-identity mechanisms they implement, whoever ships them. We name no vendor coverage claims: what we read is stated in the engagement letter, and anything we could not read is stated in the findings.

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 Delegated Access 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