WitnessOS
Post-quantum readiness

Know what your cryptography depends on. Then move it on a plan.

Australian government systems must inventory their cryptography and maintain a post-quantum transition plan. We produce both as signed artifacts, in the vocabulary your assessor already checks against.

Why now

The milestones are already set

ASD's post-quantum guidance names three dates, and they are the dates a transition plan will be measured against. The work is phased as Locate, Assess, Triage, Implement, and Communicate and educate.

  • End 2026

    Refined transition plan

    A defined plan covering the systems in scope, the sequence of work, and the owner accountable for each part of it.

  • End 2028

    Transition commenced

    Migration work started across the agreed scope, rather than planned and left standing.

  • End 2030

    Transition complete

    Post-quantum cryptography in place for the systems the plan named, with the inventory as the record of what changed.

Control basis

The controls name the artifacts

Two ISM controls turn this from a discussion into a deliverable. Both are quoted from the Australian Information Security Manual, which is published and free to read.

ism-2083

A CBOM, produced and handed over

"A cryptographic bill of materials is produced and made available to consumers of software." If you ship software, the inventory leaves the building and goes to whoever consumes it.

ism-2073

A plan, maintained

"A post-quantum cryptography transition plan is developed, implemented and maintained." Maintained is the operative word, and it is why the inventory is re-issued rather than filed once.

ism-2082

Imported components

Where a supplier provides a CBOM for imported third-party components, it is used during development to confirm those components support ASD-approved algorithms.

ism-principle-pro-17

Cryptographic agility

Systems are designed, configured and managed to support timely, prioritised and orderly changes to cryptography, including post-quantum cryptography.

ism-1990

Validation is preferred, not required

Adherence to FIPS 140-3 validation for ML-DSA and ML-KEM is preferred under the ISM. That softness is what makes the work deliverable today, and it is treated honestly rather than as a loophole.

ism-1996

Hybrid schemes

Where a post-quantum and traditional hybrid is used, at least one component is an ASD-approved algorithm.

The engagement

One boundary, six deliverables

We agree a single boundary with you, take the inventory inside it, and hand you artifacts you keep and can verify without us.

Cryptographic inventory

The algorithms, protocols, libraries, certificates and key-custody points the boundary depends on, delivered as CycloneDX 1.6 and validated against the published schema.

Quantum exposure register

Each asset graded by exposure: harvest-now-decrypt-later, signature forgery or no post-quantum exposure, weighed against how long the data it protects must stay secret.

Transition plan for ism-2073

Sequencing, owners and milestones against the 2026, 2028 and 2030 dates, with a cryptographic-agility position and an explicit hybrid posture.

Signed evidence record

The inventory and the plan bound to a single root and independently timestamped, so the version you hold is provably the version we produced.

Verification you run yourself

The verification path is free, local and needs no account and no network. It is your engineer's run, not ours, and it is the demonstration that matters.

Currency proof

On a cadence you choose, the inventory is re-taken and re-anchored, so drift is detected and named rather than assumed absent.

Proof, not a spreadsheet

A scan is a list. A record is evidence.

An inventory tells you what was present when somebody looked. It cannot tell you that the list you were handed is the list that was measured, that the assets were inside the agreed boundary, or that nothing changed after the report was signed. Those three questions are the ones an assessor asks.

So we bind the inventory to the estate it was taken from. Take the same estate twice and the record is stable. Add one certificate to that estate and the binding breaks and names the exact asset that appeared. Change one byte inside the issued inventory and the record no longer verifies. Those are the properties we demonstrate in a scoping call, on your boundary or on ours.

We also report what the inventory found rather than what sounds impressive. A first pass typically flags classical primitives with a finite security life, including RSA-2048, ECDSA P-256, DH-2048, AES-128 and X25519 key exchange. Our own evidence records are signed with ML-DSA-65 and carry a countersignature for compatibility with verifiers that do not yet support it.

The honest position

No validated module carries ML-DSA today

Under ism-1990 adherence to FIPS 140-3 validation for ML-DSA and ML-KEM is preferred rather than required. That is fortunate, because no currently validated cryptographic module implements them. The NIST validation programme's active certificate list for the OpenSSL provider covers the classical primitives: AES, the SHA family, RSA, ECDSA and the TLS key derivation functions. ML-DSA and ML-KEM are absent from it.

The practical consequence is that nobody can buy their way to a validated post-quantum inventory today, at any price. What can be done is an accurate inventory, an honest statement of which assets sit outside a validated boundary and a plan that does not depend on a module that does not yet exist. We tell you which of your assets fall outside that boundary rather than implying otherwise.

Before you engage

What a fee does not buy

  • No compliance certificate. We produce the inventory, the plan and the evidence behind them. We do not certify you. We do not opine on your compliance.
  • No legal advice. Mapping your obligations to your systems is your counsel's call, not ours.
  • No remediation. We do not re-key your estate. The transition plan says what should change and who owns it.
  • No module validation. We cannot obtain a FIPS 140-3 validation, and no vendor can currently supply one for ML-DSA.
  • No outcome guarantee. An inventory describes an estate at a point in time. It cannot promise the estate will not change, only prove that it did.
FAQ

Questions people ask

What is a cryptographic bill of materials?
A CBOM is an itemised record of the cryptography a boundary depends on: algorithms, protocols, libraries, certificates and where keys are held. It is the artifact the ISM names for knowing what you would have to change, and the Locate phase of the transition is built on it.
Is this the same as a vulnerability scan?
No. A scan reports what is present and known-bad today. A CBOM records the cryptographic dependencies of a boundary. Our record additionally binds that inventory to the estate it was measured from, so a later change is detected rather than assumed absent.
Do we need FIPS 140-3 validated cryptography to comply?
The ISM prefers validation for ML-DSA and ML-KEM rather than requiring it, and no validated module currently implements them. We state plainly which of your assets sit outside a validated boundary, because an assessor will ask.
What counts as a boundary?
Whatever you scope: a system, a service, a platform or a set of components with a shared owner. The statement of work names it. Anything beyond it is quoted separately rather than assumed included.
How does this relate to the rest of WitnessOS?
Same evidence engine, different subject. WitnessOS makes agent action provable. This makes your cryptographic inventory provable. Both produce records that verify independently, with no trust in us required.
What does verification cost?
Nothing. The verification path for a record we issue is free, local and needs no account and no network. A proof you have to pay to check is not a proof, and we do not sell one.
Next step

Scope one boundary

A short call is enough to agree a boundary and a fixed scope. You will see the inventory and the drift detection run before you commit to anything.