The standards journey
Seven things procurement asks about — in plain language
These aren't app features you'd notice. They're the certifications and standards a serious buyer checks off. Here's each one: what it is, why it matters to you, and exactly where we stand. No blur.
🔐
Quantum-safe connection ML-KEM · FIPS 203
What it is: our signatures are already quantum-safe (ML-DSA-65); this will extend post-quantum protection to the live connection too. Today the transport is classical TLS 1.3 with certificate pinning.
Why you need it: an attacker can record your encrypted traffic today and decrypt it in ~10 years once quantum computers arrive ("harvest now, decrypt later"). For evidence that stays sensitive for decades, that matters.
Status: roadmap — engineering, edge + client. Not required for the seal itself.
🧬
A second quantum-safe signature SLH-DSA · FIPS 205
What it is: a backup signature built on completely different math from our main one.
Why you need it: belt and braces. If a weakness is ever found in one algorithm family, the second, unrelated one still holds — insurance for long-horizon archives.
Status: roadmap — low effort, deliberately deprioritized (our main PQ signature already covers the quantum case).
🏅
Lab-certified crypto FIPS 140-3 validated
What it is: the difference between "we use the approved algorithm" and "an accredited lab certified our exact implementation."
Why you need it: US federal and some regulated buyers are legally required to run only lab-validated crypto modules — no validation, no deal.
Status: roadmap — we use the FIPS 204 algorithm today; swapping to a pre-validated module is engineering, not a new lab audit. The cheapest of the seven.
🕰️
Standards-based timestamps RFC-3161 · LIVE
What it is: beyond the device's own signed time, a StateNull-operated timestamp authority stamps "this hash existed at exactly 14:03:22 UTC" — a standard RFC-3161 token any tool can check. It is not an independent or qualified trust service.
Why you need it: in a dispute, a separately signed statement of when is harder to challenge than the device's own clock alone.
Status: shipping now — server-side TSA with its own timestamping certificate; tokens verify in openssl ts.
📎
Signatures your PDF reader trusts PAdES-B/-T
What it is: the European standard that makes Adobe Reader show a signed PDF with a green "valid signature" check.
Why you need it: a reviewer can then verify your report in the tool they already trust — no need to trust ours.
Status: roadmap — builds on the timestamp authority above.
🌐
Industry-standard provenance C2PA listing
What it is: today the app can embed a real C2PA 1.3 content credential (a standards-based JUMBF/COSE manifest) into the JPEG when you export — an opt-in setting — signed with a hardware-backed device key under our own claim-signer certificate. That certificate is not on the public C2PA trust list, and we hold no conformance listing: stock C2PA validators verify the manifest as valid but show it as an unknown source. Conformance is what would change that — Adobe, Google and camera tools recognising StateNull as a known source.
Why you need it: once we are conformance-listed, your sealed media would show as a recognised source in any C2PA tool. Today, stock validators read the embedded manifest as standards-valid from an unknown source; full verification of the seal itself is through StateNull's own offline verifier.
Status: roadmap — a membership & conformance process (organizational), not just code.
🎯
Proven by outsiders Pen-test & certs
What it is: an independent security team attacks the product and publishes a report; formal certifications (e.g. ISO 27001) audit the organization.
Why you need it: "trust us" isn't evidence. An outside attacker's report — and a certificate — is what your own security team will ask for first.
Status: roadmap — scheduled with the first paid deployment.