All 31 questions, on the record
ASD's post-quantum questions for your vendors — answered
In July 2026 the Australian Signals Directorate published Post-quantum questions to ask your vendors — 31 questions any organisation can put to a software vendor to find out whether the cryptography protecting its documents will survive the arrival of quantum computers. ASD's own guidance warns about vendors who respond with general assurances and deferred timelines.
We think the fairest thing a vendor can do is answer the questionnaire in public — including saying plainly where we haven't shipped something yet. Below are all 31 ASD questions, each with Omitly's answer on the record: what's shipped today (Ed25519 signing), what's roadmapped and not yet available (hybrid post-quantum signing, tracked as omitly#533), and no invented ship dates. Take the same questions to every vendor that touches your documents.
Locate
1. Do you maintain a CBOM (cryptographic bill of materials) or equivalent?
Yes. A CycloneDX-style CBOM ships with every release: algorithms, parameter sets, libraries with versions, protocols, and where each is used (sealing, licence verification, update transport, optional output encryption). A public summary of every primitive is at https://security.omitly.app/crypto/ — the full machine-readable CBOM and SBOM are provided to licensed customers.
2. Where is cryptography implemented?
Application layer only, in one auditable Rust workspace reused byte-identically across the desktop app and the npm verifier (WASM). TLS for downloads and updates uses the operating system's stack. No middleware, firmware or hardware cryptography. OS keystores (Keychain/CNG) hold keys for custody only — no algorithm is hardware-bound.
3. Is any cryptography hardcoded, fixed or hardware-bound?
No. The seal envelope is algorithm-tagged with an open registry; signature and hash algorithms are data, not code structure. The verifier fails loud on unknown versions rather than silently ignoring them. Nothing is hardware-bound. That registry is why adding post-quantum signing later is a data-level entry, not a format break — see Q8.
4. Do third-party dependencies introduce cryptography?
Yes, and they are enumerated in the CBOM: standardised, widely-used libraries only — an audited Rust Ed25519 implementation for today's seal signing. No bespoke or proprietary primitives — our formats are bespoke, our cryptography is not. A post-quantum (ML-DSA) backend is on our roadmap (omitly#533, not shipped); when we add one it will be held to the same standard before it touches a legal-evidence trust path.
5. How is cryptography updated?
Through ordinary signed application updates and versioned npm releases — no reinstallation, no hardware dependency. Cryptographic changes ship as coordinated verifier+app releases with advisories.
6. Hardware roots of trust?
None, deliberately: Omitly is local-only desktop software; no TPM/HSM/enclave dependency constrains a future PQC transition.
7. How is firmware authenticity verified?
Not applicable — we ship no firmware. Application binaries are platform-signed (Apple notarisation, Windows Authenticode) and release artefacts are signed for the updater.
8. Are firmware/boot processes updatable for PQC signatures?
Not applicable (no firmware). Our equivalent long-lived mechanism — the sealed document format — is designed so a post-quantum signature scheme can be added by data-level registry entry, not format replacement. That slot exists and is currently unused: today's seal is Ed25519 only. Hybrid ML-DSA-87 + ECDSA P-384 signing is roadmapped (omitly#533), not shipped.
Assess
9. Which customer data flows rely on traditional asymmetric crypto?
Omitly is local-only: your documents never transit to us, so there are no vendor-side customer data flows. Asymmetric cryptography appears in exactly two places today: (a) document seals — Ed25519, signing/integrity; and (b) licence verification — a vendor-signed entitlement chain, also Ed25519 (documented exception, see Q14). Plus (c) TLS for downloads/updates (platform stack). A hybrid ML-DSA-87 + ECDSA-P384 seal is roadmapped (omitly#533), not shipped.
10. Data lifetime assumptions?
Sealed legal documents are assumed to need decades of verifiability. That's already reflected in what ships today: an algorithm-tagged, versioned seal envelope built so a new algorithm is a registry entry rather than a format break, and an RFC 3161 timestamp added automatically when a timestamp authority is reachable at sealing (sealing itself never requires a network). Retention is customer-controlled — the files are local; we hold nothing. SHA-384/512 digests and a hybrid post-quantum signature are on the roadmap (omitly#533), not shipped.
11. Documented product-specific CRQC risk assessment?
Yes — a written assessment distinguishing prospective signature forgery from harvest-now-decrypt-later, referencing ASD ISM controls (1917, 1990–1996, 2073) and NIST IR 8547, with the multi-engine review trail that produced it. Published at https://security.omitly.app/pqc/, alongside our public threat model at https://security.omitly.app/threat-model/.
12. Do you distinguish signing, encryption and authentication risks?
Yes, explicitly. Signing (seals): forgery is prospective, not retroactive; sealed documents outlive algorithms, which is exactly why a post-quantum leg (ML-DSA-87, omitly#533) is the priority for our transition — though it hasn't shipped yet. Encryption: the only encryption we perform is optional AES-256 output protection — symmetric, with a key size generally treated as resistant to known quantum attacks, and no harvest-now-decrypt-later exposure through us. Authentication (licences): vendor-rotatable short-horizon trust with a working recovery story; lowest priority, by design.
13. Can customers choose stronger settings today?
Strong settings are the only settings: Ed25519 signing, SHA-256 hashing, AES-256 output protection, timestamping when a timestamp authority is reachable — all on by default, with no weaker “compatibility mode” to fall into. A move to ASD-approved hybrid signing (ML-DSA-87 + ECDSA-P384) is roadmapped (omitly#533), not available today.
14. What authentication relies on traditional asymmetric crypto?
Licence-file verification (offline root → scoped intermediate → licence, Ed25519) and today's document seals (also Ed25519). Ed25519 is not an ASD-approved algorithm; both uses are documented exceptions with rationale (not customer-data-bearing for licences; widely-audited, well-understood classical cryptography for seals, pending the hybrid roadmap) recorded in the CBOM and exception register. The chain and seal formats are both algorithm-tagged, so a future algorithm change is a policy addition, not a format break.
Triage
15. PQC-ready early enough for rollout before end-2030?
Not yet, and we say so plainly rather than assume it: post-quantum signing (ML-DSA-87 + ECDSA-P384 hybrid seals) is roadmapped as omitly#533 and has not shipped. What's already true is the groundwork — an algorithm-tagged, versioned seal envelope designed for exactly this addition, so when it ships it's a registry entry, not a format break. We haven't committed to a ship date here; ASD's 2030 line is the deadline we're building toward.
16. Components requiring hardware replacement / re-architecture?
None expected. Software-only. Carrying larger post-quantum signatures in the seal container without breaking PDF readers is part of the omitly#533 design work — not yet shipped, but not a hardware dependency either way.
17. PQ/T hybrid as temporary, and path to PQC-only?
Aligned with ASD's position on how it should work when it ships: hybrid (ECDSA-P384 + ML-DSA-87) is planned as a transition mechanism only, not a permanent end state. The intent is for composition to be verifier policy, separate from the format, so a later dated cutover to ML-DSA-required (and eventually PQC-only) needs no format change and historical documents stay verifiable. None of this exists yet — it's the design target for omitly#533, not a shipped mechanism.
18. Customer risk in prioritisation?
Risk-based, not revenue-based: archival/long-retention profiles (legal matters, compliance records) get timestamping and the strongest available defaults first — they carry the longest-lived risk. One product, one codebase: no customer tier receives weaker cryptography.
19. Internal governance?
A named crypto owner, with decisions recorded publicly as they're made. Honest scale note: we are a small vendor; governance is one accountable owner, not a committee, and we state that plainly rather than describe a review cadence we don't run.
Implement
20. Which PQC algorithms, and GA when?
Planned: ML-DSA-87 (ASD's named preference), hedged variant per ISM-1992, pure (not pre-hashed) signing with domain-separated context; digest agility to SHA-512 where pre-hashing is ever used (ISM-1994). GA: not yet, and we're not committing to a date here — tracked publicly as omitly#533. SLH-DSA codepoints would be reserved in the format registry as a lattice-independent fallback (not shipped). ML-KEM: not applicable — no asymmetric encryption in the product.
21. Is the PQC implementation production-ready and available?
No, and that's deliberate. No production-grade (audited or FIPS-validated) ML-DSA backend exists in our stack today; shipping experimental lattice code into a legal-evidence trust path would create exactly the risk this questionnaire screens for. What is production-ready and available today is the seal itself — Ed25519, algorithm-tagged, versioned — and the transition machinery (registry slot, WASM-shared verify core) that ML-DSA-87 will plug into. It will activate as a supported, default-on release, never a preview flag, once a backend passes a published admission bar. Support arrangements are stated plainly: email support with a response target we publish separately.
22. How do you validate and maintain cryptographic libraries?
Reputable, actively-maintained libraries only, tracked in the CBOM — an audited Rust Ed25519 implementation is what ships today. For the post-quantum backend, before we ship it, we intend to hold it to a public admission bar: FIPS 204 known-answer vectors in CI, negative-vector regression tests, a cross-implementation sign/verify matrix, and fail-closed defaults. One verify core compiled to WASM already, so the npm verifier and the desktop app share a single implementation rather than maintaining two that can drift — the same discipline the PQ backend will join, not a new one invented for it.
23. Key management / sizes / lifecycle changes under PQC?
ML-DSA-87's sizes are fixed by FIPS 204 (2,592-byte public keys, 4,627-byte signatures) regardless of vendor — carrying them without breaking PDF readers is part of the seal-container work planned for omitly#533, not yet shipped. Today's Ed25519 seal uses much smaller keys stored as 32-byte seeds; per-install keys with generation, storage, loss and rotation documented in the spec. Licence chain sizes are unaffected either way.
24. How do customers enable PQC?
There's nothing to enable yet — hybrid sealing hasn't shipped (omitly#533). The plan, when it does, is default-on for every new seal, with verification tooling (app and npm verifier) released version-aware ahead of any PQ-signed document existing, so no customer coordination is required. Today, Ed25519 sealing is already on by default and needs no customer action.
25. Is PQC included in base licensing?
There's no separate PQC feature to license yet. Our commitment: when hybrid signing ships (omitly#533), it will be included in the same one-time licence at no additional cost, consistent with how every other cryptographic capability — including today's Ed25519 sealing — is licensed. Security isn't sold as a premium add-on.
Communicate and educate
26. How are customers notified of cryptographic changes?
Release notes and, for security-relevant changes, published advisories; format/policy changes carry advance transition notices.
27. Customer-ready PQC transition guides?
Not yet needed — there's nothing to transition to until omitly#533 ships. What exists today: the seal specification and verifier documentation for the current Ed25519 seal, and a plain-language guide to what a seal proves and doesn't (see CLAIMS-POLICY.md's canonical scope paragraph, reflected in our own copy). When ML-DSA-87 ships, the plan is to publish updated spec, verifier docs and test vectors — including expected-failure vectors — alongside the release, not after it.
28. How will traditional crypto be deprecated (incl. hybrid)?
There's no hybrid or classical-required policy live yet — today there is one algorithm, Ed25519, with no deprecation event pending. The plan for when omitly#533 ships: (a) hybrid ML-DSA-87 + ECDSA-P384 lands as a new capability, classical-required by default; (b) a later dated cutover moves to ML-DSA-required; (c) eventually a PQC-only verification policy, tracked against ASD's 2030 line. Warning periods and support windows would be stated in advance, and the format is designed so historical documents keep their evidence rather than needing re-signing.
29. Support and engineering trained for PQC?
Honest scale answer: a small engineering-led vendor. The people designing the omitly#533 transition are the same people who'd be the support escalation path once it ships. Runbooks and known-issue registers are maintained today for what's already shipped; the PQC-specific versions are part of the #533 rollout, not live yet.
30. Roadmap aligned with ASD guidance / transition by end-2030?
Yes, as a roadmap — not yet as shipped capability, and we're explicit about the difference. By control number: ISM-1917 (ML-DSA-87 and SHA-384/512 support, targeted well before 2030, tracked as omitly#533), ISM-1990 (validated modules preferred — our intended admission bar, see Q22), ISM-1992 (hedged variant, planned), ISM-1994 (SHA-512 digest agility, planned), ISM-1996 (hybrid composition rules, planned), ISM-2073 (a maintained transition plan — this page and #533 are the current form of that plan; a standalone published document is on the pre-merge checklist, not live).
31. Do you track/contribute to PQC standards bodies?
We track — we do not claim formal liaison seats: NIST (FIPS 204/205, IR 8547), ASD ISM releases, ETSI ESI (the PQ algorithm catalogue and PAdES work) and the PDF Association's ML-DSA/SLH-DSA formalisation effort. Our current seal specification (Ed25519) is published, and we intend to publish the ML-DSA-87 spec and test vectors alongside its release, evaluating alignment with ISO 32000 post-quantum work as it lands.
Take these questions to every vendor
ASD's questionnaire is CC BY 4.0 — anyone can use it. Ask every vendor for artifacts, versions and dates, in writing. General assurances and deferred timelines are the two response patterns ASD's guidance explicitly warns about — if that is all a vendor can produce, weigh it accordingly.
Related reading: NIST's post-quantum standards · ASD-approved cryptography · The ISM controls for documents · What is Ed25519?
Questions reproduced from Australian Signals Directorate, Post-quantum questions to ask your vendors (first published July 2026), licensed under CC BY 4.0. Answers are Omitly's own.