The PQC migration pilot programme is designed to take a scoped set of your systems through two separate parts: an authorised assessment, then, only with your separate approval, one governed change and a re-scan. Both parts run on Crypto-Agility, a capability of R-Series in development.
Pilot programme by application; we confirm fit and scope before any work.
It suits an organisation that wants to know where its public-key cryptography is and plan its post-quantum migration, starting with a scoped set of systems.
The programme starts with what can be observed, states every gap, and changes one thing only when you approve it. Why post-quantum algorithms matter at all is on Post-quantum cryptography.
Part 1 observes and plans. Part 2 changes one thing, and only after you approve it separately.
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.
In development
Separately approved by you, with a baseline, operational and failure tests, a rollback or hold plan, change receipts and a comparable re-scan of the same scope.
In development
Neither part is on sale today, and neither has a price. Both are in development and open only after their gates.
Nothing is observed until the scope is agreed, authorised and signed.
Only TLS and SSH handshakes, only on the targets in the signed scope, only inside its window.
The assessment observes and plans. It changes nothing in your systems.
Part 2 is a separate offer. It never starts without your separate approval.
A re-scan is comparable only when the scope and the probes match.
Monitoring is not offered today.
The records are designed so that you can check them without DCS.
The authority for every observation, bound by digest.
Every target and probe with its outcome, gaps included.
Signed digests you can check with the verifier supplied with the bundle.
Intent, approval, outcome and any rollback, each a receipt.
Two comparable scans, and the exceptions still open.
Standard profile: Ed25519 + ML-DSA-65, both signatures required. A higher profile with ML-DSA-87 is in development.
Deleting the raw data later does not invalidate the receipts. Your own copy of the deliverables remains checkable against them.
These are in place before the scope file is signed. The change approver is needed only for Part 2.
Your technical contact is named in Schedule A of the letter.
Each target is listed with its host, its port and the observation types allowed on it.
Someone who holds your authority for every target in scope, and signs the letter.
The letter quotes the scope file’s identifier, digest and window, and the scope file is signed before anything is observed.
The channel is monitored during the window, and your contact can stop the observations.
The person who approves the one change under your own change approval.
Third-party hosting. A target hosted by a cloud, CDN, managed-service or SaaS provider is left out unless that provider’s written consent is attached.
No secrets. No secrets are sent in the enquiry, and no private key is requested or handled.
Planned terms. These are the planned terms of an engagement, from draft engagement documents that counsel has not yet reviewed. They are not signed terms.
TLS and SSH handshakes only: protocol versions, key-exchange groups, cipher suites, host-key types and the certificate chains your targets present.
No password, private key, token or agent is offered. TLS session secrets are removed before any transcript is written. Only public certificates and public host keys are recorded.
No secrets in the enquiry, and no private key is requested or handled. Deliverables travel by an encrypted channel, and no secrets travel by ordinary e-mail.
Findings about your systems are never published by DCS, in an advisory or anywhere else. They are used only to deliver your engagement.
Access is limited to the roles named for the engagement, and every access is logged. Your data is not placed into third-party AI tools unless you agree in writing and the provider’s data terms have been reviewed.
Raw transcripts and the derived inventory are deleted after set periods, or returned and deleted at your choice, with written confirmation. The periods are not set yet.
A certificate’s subject can hold a person’s name or e-mail address. The observations do not seek personal data, but they may record some.
Narrowing inside the signed scope needs nothing new. A new target, observation type or address, or a longer window, needs a new scope file and an amendment to the letter.
On a stop, no new connection is started; a handshake already in progress may finish or time out.
A schema-valid CBOM, a valid receipt, two scanners that agree or one post-quantum primitive found does not establish complete coverage, migration completion, regulatory compliance, FIPS validation, defence approval or long-term validity. Not observing something does not prove it is absent.
Pilot programme by application; we confirm fit and scope before any work.
Use the contact page and tell us which systems you would scope first. Send no secrets in the enquiry.
Before any work, we check the fit with you and agree the scope.
Only then can the first observation window open.
In development The R-Series platform and both parts of the programme are in development.
Status as of 31 October 2026: In development. The PQC migration pilot programme is open for pilot conversations; discovery lab acceptance is in preparation. 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. The observations record only public certificates and public host keys, and no private key is requested or handled. Key management is out of scope unless separately accepted.
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 duration is published. In the planned terms, the observation window, the connection limits and the analyst effort are agreed for each engagement and written into the scope file and the letter. One scope file’s window is at most 31 days: a ceiling, not an estimate. More analyst effort goes through change control before the work is done.
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.
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.
Short TLS handshakes from the DCS source address with no request after them, and SSH connections for the user name “probe” that end before any login. Some servers log these as an invalid user or a pre-authentication disconnect.
Yes, at any time. Your contact sends a stop instruction through the stop channel. Observation halts, DCS confirms in writing, and resuming needs a new authorisation.
No. Findings about your systems are never published by DCS, in an advisory or anywhere else.
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.
Not yet. Both parts are in development; neither is on sale yet, and neither has a price. Pilot programme by application; we confirm fit and scope before any work.
No. Monitoring comes later, only after its own service gates. Nothing here promises a recurring service.
Pilot programme by application; we confirm fit and scope before any work.