Loading…
Loading…
Migrating to ML-KEM, ML-DSA, or SLH-DSA is the easy part. Certification answers the load-bearing question your auditors and customers will ask: does the implementation you shipped actually follow FIPS 203/204/205 — including the input checks the test vectors never touch?
A passing test-vector run is not conformance. We exercise the malformed-input and edge-case behaviour the vectors omit, and give you evidence you can defend.
Every certification is issued as an attestation: a record of the reviewed posture, signed with a post-quantum signature (ML-DSA, FIPS 204) inside a FIPS 140-3 hardware security module, and written to a public transparency ledger. Anyone can check it without trusting us: verify the signature against our published key, then re-run the scan to reproduce the evidence hash.
That a shipped ML-KEM, ML-DSA, or SLH-DSA implementation actually conforms to FIPS 203, 204, and 205, including the input-validation and encoding behaviour that known-answer test vectors never exercise.
Known-answer vectors check the happy path. Certification also tests the input checks in the standards' sections 7.2 and 7.3, where real implementations tend to diverge.
No. Any implementation, in any language, is driven through a small stdin and stdout protocol, so no source access is required.
A signed conformance report you can show auditors, customers, and regulators.
No. Conformance is a continuous property, not a one-off certificate, so we re-test on every release.
The Sieve conformance battery, part of our open-source toolkit.
Book a discovery call and get an indicative scope and pricing for your organisation.