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.
Finding classical cryptography is only the start. The work is to say what was seen and what was not, rank what matters, change one thing under approval, and look again.
Why post-quantum algorithms matter at all, and which one does which job, is on Post-quantum cryptography.
No separate site and no separate product. Crypto-Agility is described here and under Migration on R-Series.
Every cryptographic operation goes to the R-Series engine. The capability plans and records; it never signs on its own.
An assessment and a bounded change pilot are two separate offers, each with its own gate.
Four steps, in order. The re-scan observes the same scope as the assessment, so the two can be compared.
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.
The two offers in order, for one organisation’s own estate: what you do, what DCS does, what you receive and what evidence remains at each of the six steps.
Pilot programme by application; we confirm fit and scope before any work.
In development See the pilot programme
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.
The report is the deliverable of the assessment. It is not deliverable until every expert-review field is completed and signed.
When the observations were made, and exactly what they covered.
Every asset the scan could not reach or did not test, named.
Which algorithms each asset used, with their parameter sets and key sizes.
How strong the evidence behind each finding is.
What the assessment assumed, and what it set aside.
The version of every rule a score or target came from.
A target for each asset and each use, never one suite for everything.
The waves, and how the same scope will be observed again afterwards.
No sample assessment is shown here. A sample is published only when an accepted report template supports what it shows.
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
The rebuild, in development, rests on four foundations.
Every refusal carries a stable code. Nothing that refuses returns allow, ok or valid.
Status words come from one fixed list. Labels the evidence cannot back are gone.
Routing, inventory and reporting read the same tables. An unknown profile or algorithm is refused, never defaulted.
The CBOM follows written conventions. Coverage gaps get their own entries, and none can read as safe.
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.
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.
Two entries are the same asset only when their names match exactly. Order, location and probe ids never decide it.
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.
A CBOM difference alone is never migration evidence. It shows that two inventories differ, not that a change happened, was authorised or is complete. The change itself is evidenced by its own signed receipts. Migration evidence on R-Series
Each record below is part of the design, in development.
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.
The before and after evidence is bundled so that a second process can check it with only the public verifier.
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.
In development The migration programme on R-Series
No. It is a capability of R-Series, in development. Two offers are being prepared on it, an assessment and a bounded change pilot. Neither is on sale yet; each opens only after its own gate.
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.
TLS and SSH observations on authorised endpoints, and the certificate chains visible through that TLS work, with a coverage ledger and a CBOM. Source code, data at rest, key management and vendor or SaaS channels are out unless separately accepted.
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.
No. The assessment observes and plans. A change happens only in the separate change pilot, under your own change approval, with a baseline, tests and a rollback or hold plan.
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.
No. Monitoring comes later, only after its own service gates. Nothing here promises a recurring service.
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.