Crypto-Agility is a capability of R-Series, in development. It is designed to take part of an estate from an authorised assessment to a ranked plan, through one approved change, and back through a second scan, with evidence left at every stage.
Crypto-Agility is the part of R-Series that turns an estate’s cryptography into a plan: a policy, a router over the R-Series engine’s primitives, a scheduler, a CBOM and a report. It holds no cryptography of its own; every signature comes from the R-Series engine.
On R-Series, it sits beside the PQC migration programme and R+13 migration evidence. No separate site and no separate product.
Why post-quantum algorithms matter at all, and which one does which job, is on Post-quantum cryptography.
Every cryptographic operation goes to the R-Series engine. The capability plans and records; it never signs on its own.
A signed record of the scope digest, the observations, the coverage, the CBOM digest and stable component identities, so two scans of one estate compare component to component.
The assessment report’s manifest is a receipt from the R-Series engine. The report content is designed to regenerate byte for byte from the same inputs.
Intent, approval, outcome and rollback are each a receipt. The approval names the plan, the assets, the operation, the suite, an expiry and a nonce.
| R-Series part | What Crypto-Agility takes from it |
|---|---|
| R+13 Migration evidence | The migration verdict, which is the R+13 verifier’s and never a capability’s own |
| CBOM ingest and diff | CBOM evidence that enters only through the engine’s CBOM ingest, with digests and differences computed by the engine |
| Connector OS | Governed execution for the one approved change of a change pilot |
| Atlas | The before/after bundle of a change pilot |
Authorised discovery of TLS and SSH endpoints and their certificate chains, a coverage ledger that shows every gap, and a CycloneDX CBOM of what was observed.
Reviewed findings, a risk rationale for each, a migration target for each use, and migration waves set by owners and dependencies.
One approved change, end to end, under your own change approval, with a baseline, tests and a rollback or hold plan.
The same scope observed again, the difference between the two scans, and the exceptions that remain.
Offer 1 covers TLS and SSH observations on authorised endpoints and certificate chains visible through the scoped TLS work, with a coverage ledger and a CycloneDX CBOM of observed assets. Source, data-at-rest, key-management and vendor/SaaS channels are unavailable unless separately accepted. Schema validity does not establish completeness.
The assessment never changes anything. A change is a separate offer that starts only after the assessment is accepted, under your own change approval.
Authorised discovery of the scoped endpoints, a CycloneDX CBOM, a Crypto-Agility plan and an assessment report whose expert-review fields are completed and signed before delivery.
In development
One change, approved by you, carried out through governed execution with Connector OS, recorded as R-Series receipts, and shown before and after in one bundle that can be checked without DCS.
In development
Neither offer is on sale today, and neither has a price. Both are in development and open only after their gates, listed under Where it stands.
Each stage says what DCS delivers and what evidence it leaves behind. Nothing moves to the next stage on a promise.
DCS delivers. The sponsor, the assets and environments, the region, the supported stack, the authorisation, data handling and a statement of work. No secrets in a public enquiry.
Evidence it leaves. A scope file and a written authorisation. The scope’s digest is later signed into the scan receipt.
DCS delivers. An approved collector and access, and scoped observations. Unsupported, excluded, partial and failed coverage stays visible.
Evidence it leaves. A coverage ledger, and a scan receipt that binds the scope, the observations, the coverage and the CBOM digest.
DCS delivers. Reviewed findings with their provenance, the CBOM, a risk rationale, and migration waves based on owners and dependencies.
Evidence it leaves. A CycloneDX CBOM and the assessment report. The report’s manifest is a signed receipt.
DCS delivers. A separate offer, under your own change approval: a baseline, operational and failure tests, and a rollback or hold plan.
Evidence it leaves. Change receipts for the intent, the approval, the outcome and any rollback. The approval is bound to the exact plan, assets and operation.
DCS delivers. A comparable re-scan, offline checking of the supported evidence, the residual exceptions, and your acceptance.
Evidence it leaves. The re-scan difference, an offline check of the scan, report and change receipts, and the list of exceptions still open.
DCS delivers. Only after service capacity, response, freshness and retention gates. No recurring service is promised from a roadmap item.
Evidence it leaves. None yet. Monitoring is not offered today.
A migration target describes your system. The receipt profile describes how DCS signs the evidence about it. One never sets the other.
The risk model gives each asset a target crypto profile for each use it serves. A target is never expressed as a receipt suite.
Standard profile: Ed25519 + ML-DSA-65, both signatures required. A higher profile with ML-DSA-87 is in development.
The receipt suite follows the evidence policy, never a migration target.
A re-scan is comparable only when the scope and the probes match. Where coverage differs, the result says so instead of guessing.
An entry missing from the later scan is “not observed in the later run”, never removed, fixed or migrated. An added one is “newly observed”.
If an asset was scanned on one side and a gap on the other, its entries are reported as incomparable.
When the policy or a fact it needs is missing or unknown, the authorisation answer is deny.
policy missing→DENY
When an inventory is unknown or incomplete, the assessment says UNKNOWN or INSUFFICIENT, never ok.
inventory incomplete→UNKNOWN · INSUFFICIENT
What is being fixed. An earlier internal version of this package read a missing policy as allow and an empty or unrecognised inventory as fine, and its CBOM did not validate against CycloneDX 1.6. A code review by someone who did not build it found these. The rebuild, in development, reverses them.
None of the things on the left establishes any of the things on the right.
Support for an algorithm is not a product claim. An assessment is not a certification, and DCS software is not a FIPS 140-3 validated cryptographic module.
Each offer opens only when every gate on its rail has passed. None has passed yet.
Status as of 31 October 2026: In development. The assessment engine is built and is in its final independent review round. Receipt V2 revision 7 was issued on 30 October 2026. Evidence Contract v1 was signed with conditions by the programme’s cryptography lead on 30 October 2026. Every statement on this page is drawn from the claim register of that date.
No. ML-DSA signs; it does not encrypt data. Keeping data secret in transit or at rest needs key establishment, such as ML-KEM, chosen separately. See Post-quantum cryptography.
No. They are separate things. Receipt migration is about how DCS signs the evidence it produces. Transport and storage migration is about your own systems: your TLS, your SSH and your stored data.
It is recorded, not skipped. Unreachable, refused, excluded, partial and failed coverage stays visible, and no figure for an asset with gaps is called complete. Not seen is not absent.
Not yet. A sample is published only when an accepted report template supports what it shows.
No. A re-scan shows how two comparable scans differ. A CBOM difference alone is never migration evidence: the change has its own receipts, and whatever is still open is listed as an exception.
An authorised look at one part of your estate, every gap stated, and a plan you can check. Tell us what you would scope first.