// EVIDENCE · NO_LOGIN_REQUIRED
What You Can Check Before You Contact Us.
Standards reviewers and red teams are both trained to distrust assertion and reward reproduction. So this page leads with the boundary, the vector sources, the refusals and the limits — not with what the product can do. Nothing here is behind a token, and the gaps are listed alongside the results rather than after them.
// ARTIFACT_INDEX
Every Artifact on This Site, in One List.
In plain terms
Each of these is a separate page about one specific thing you can check. Start wherever your question is.
The per-case conformance report is the largest of them; the rest cover the boundary, the inventory, the audit format, the evaluation environment and the one end-to-end lab result. Where an artifact is not published yet, its page says so and says why rather than being left out of this list.
236 cases · 195 excluded
The Per-Case Conformance Report
Every executed vector case with its upstream tcId, every published vector that did not run and the reason, and the A3E9 software primitives with no vector coverage yet. Downloadable as PDF, XLSX or the raw run record.
Open/evidence/boundary
Where A3E9's Software Ends
The three-way split a FIPS-literate reader looks for first: the cryptography A3E9 owns and vector-tests in software, the operations delegated to a vendor module that A3E9 does not certify, and the things neither side claims. Includes which vendors have been exercised against real modules and which are written but unvalidated.
Open/evidence/cbom
The Cryptographic Bill of Materials
A CycloneDX 1.6 CBOM generated from a source scan, with a CI gate that fails the build when a PKCS#11 mechanism is added without accounting for it. The inventory, its detached signature and the public key are all downloadable, with a five-command verify that needs nothing but OpenSSL. The signature was made with a development key, which the page states next to the download rather than in a footnote.
Open/evidence/audit
The Audit Record and Its Chain
Every ALLOW and DENY is written to an HMAC-chained trail before the hardware is touched. This is the field-by-field schema, the chain rule that links each record to its predecessor, and synthetic sample records showing the shape. The live trail is not published here, and the samples are labelled as fabricated so no reader mistakes them for a run.
Open/evidence/kit
What the Evaluator Kit Actually Is
The map of the environment a token opens: the pinned signing-server image, the two software PKCS#11 modules in the pool, which acceptance tests a reviewer drives from the browser and which need a command on the VM, and — stated plainly — what driving the whole plan still does not prove.
Open/evidence/rwa
The Multi-Chain Run That Reached a Real Sign
Track C drove a multi-chain demo run that ended in a real Sign on the evaluator's SoftHSM2 token, with correlated evidence on both sides. One of its three checks was deliberately not attempted and the reason is recorded here rather than omitted. This is a lab result on software modules over an SSH tunnel — not a product.
Open// CRYPTOGRAPHIC_BOUNDARY
Where A3E9's Software Ends and the Module Begins.
In plain terms
A3E9 is software that sits in front of the tamper-proof hardware that actually holds your keys. Some of the maths runs in our software, and the rest runs inside that hardware. This shows which is which — because we can only vouch for our half.
The known-answer suite covers only the cryptographic code A3E9 owns in software — not code delegated to the HSM, which is certified separately by its vendor. That split decides which claims are ours to make and which are not, so it is stated before any result below.
A3E9 software scope
Owned, tested, and covered by the known-answer suite.
Ed25519 verify
RFC 8032 §6.1 · 5 vectors
RIPEMD-160
Published reference vectors · 6 vectors
ML-DSA / ML-KEM via liboqs
NIST ACVP vectors · 225 pass
195 more not reachable via the liboqs API · liboqs is not FIPS certified
Policy · normalization · audit chain
evaluated before any PKCS#11 call
Vendor module scope
Certified separately by the vendor. Not A3E9’s claim to make.
Key generation and storage
CKA_EXTRACTABLE=CK_FALSE, set by A3E9, not caller-overridable
The signing operation
the key never leaves the module
Module certification
exercised against real modules: SoftHSM2 · Craton
written, not hardware-validated: Thales · AWS CloudHSM · Utimaco
// CONFORMANCE_MATRIX
Which Primitive, Which Parameter Set, Which Vector Source.
In plain terms
Standards bodies publish official test inputs with known correct answers. Running them proves the maths is right. This lists every algorithm we use, whether we have run those official tests on it yet, and how many we ran.
One row per primitive. A row with no vector count has no conformance vector wired — that is recorded here rather than omitted, because an inventory that lists only its successes is not an inventory.
| Primitive | Parameter set | Vector source | Vectors | Status | Note |
|---|---|---|---|---|---|
| Ed25519 verify | raw EdDSA | RFC 8032 §6.1 | 5 | Live | License-file authentication. A3E9 never signs Ed25519 in software, only verifies. |
| RIPEMD-160 | — | Dobbertin et al., 1996 | 6 | Live | Required for Bitcoin P2WPKH addresses since OpenSSL 3.0 deprecated it under FIPS mode. |
| BIP-340 Schnorr | secp256k1 | BIP-340 test vectors | — | Live | Correctness pinned against the published vectors; signing is refused at runtime regardless. |
| ML-DSA | 44 / 65 / 87 | ACVP FIPS 204 — sigVer | 45 | Partial | Signature verification is checked against NIST's published vectors across all three parameter sets, external interface, pure. 36 of the 45 expect rejection — modified message, commitment, hint or z — which carry as much weight as the 9 accept cases. Partial, not live: key generation and signature generation cannot be vector-tested at all, because the liboqs public API exposes no seed or per-signature randomness injection. Signing and re-verifying with our own implementation would be a round trip, not a known-answer test, and is deliberately not substituted. |
| ML-KEM | 512 / 768 / 1024 | ACVP FIPS 203 | 180 | Live | Key generation (75), encapsulation (75) and decapsulation (30) all match NIST's published vectors across every parameter set, using the derandomised entry points so the results are reproducible rather than merely self-consistent. The 60 published key-validity-check vectors are excluded: liboqs performs that check internally and exposes no standalone entry point to invoke it. |
| SLH-DSA | — | — | — | Roadmap | Not implemented. There is no request enum and no wired PKCS#11 mechanism for it, and none is claimed. |
The 11 Ed25519 and RIPEMD-160 vectors run with make test-kat and need no HSM and no post-quantum library — reproducible on a clean checkout. The 225 post-quantum vectors run with make test-kat-pqc against NIST’s published ACVP files, vendored at a pinned upstream commit so the run works offline and a reviewer checks the same bytes we did. Neither is CAVP or CMVP validation.
// FULL_CONFORMANCE_REPORT
236 vector cases with their upstream tcIds, 195 published vectors excluded with a stated reason, and the 14 A3E9 software primitives that have no vector coverage yet — downloadable as PDF, XLSX or the raw run record.
Per-case detailSignature primitives
Ed25519 (RFC 8032) with raw EdDSA, ECDSA over secp256k1 with Keccak-256 for EVM payloads, and ECDSA over P-256 with SHA-256. Curve selection is read from the key's own stored EC parameters — the request does not choose the algorithm.
Known-answer tests
A dedicated KAT suite covers Ed25519 against RFC 8032 §6.1 and RIPEMD-160 against its published vectors. BIP-340 correctness is pinned against BIP-340's own test-vectors file even though Schnorr signing is refused at runtime — the maths is verified, the capability is not offered.
Post-quantum
ML-DSA-44/65/87 and ML-KEM, reached either through a vendor's native PKCS#11 v3.1 mechanism, a proprietary vendor extension, or software liboqs. Evaluation uses the liboqs path, which is not FIPS certified; a declared vendor capability is additionally checked against whether the binary was actually built with PQC support.
Cryptographic bill of materials
A CycloneDX 1.6 CBOM is generated from a source scan and HSM-signed, with a blocking CI gate: adding a PKCS#11 mechanism to the code fails the build until the inventory accounts for it, either by mapping it or by recording a reasoned exemption.
Banned primitives
A blocking scan rejects MD5, SHA-1, DES and RC4 anywhere in the source tree.
Test surface
Roughly 1,377 unit tests across six binaries with no HSM required, 130+ integration tests against a live token, 11 classical known-answer tests and 225 NIST ACVP vector cases, 47 attestation tests and 9 audit-module tests, plus AddressSanitizer and static-analysis targets.
// REFUSALS
What A3E9 Refuses to Do, and Why Refusing Is Enforced.
In plain terms
Things A3E9 will not do, on purpose — and where the code stops you rather than the manual asking you not to. Some of these lose us features we could otherwise advertise.
Each of these is a refusal implemented in code with a test behind it, not a policy statement. Several of them cost capability that would be easier to advertise than to decline.
BIP-340 / Taproot spends
Refused on every vendor, with no software fallback. BIP-340 needs the private scalar; no PKCS#11 mechanism computes it inside the boundary and CKA_EXTRACTABLE=CK_FALSE will not release it. The RPC exists, resolves the capability before borrowing a session, records the denial, and returns UNIMPLEMENTED. A3E9 derives Taproot addresses but cannot spend from one — the asymmetry is stated rather than hidden behind a flag.
Cross-vendor duplication of signing keys
Never attempted. KeySync synchronizes transportable key material — a transit KEK — through an attested wrap/translate/unwrap ceremony. A FIPS 140-2 Level 3 signing key is non-extractable by design, so its resilience comes from multi-vendor failover and MPC vendor-bound custody, not from copying it. Any claim that keys are replicated across vendors would be false.
The FIPS boundary in the evaluator kit
SoftHSM2 and Craton are software PKCS#11 modules with no FIPS 140-2 Level 3 chassis. Level 3 describes hardware a production deployment brings; it is not what an evaluator is driving. Thales, AWS CloudHSM and Utimaco paths are written but have never been exercised against real hardware.
Post-quantum, honestly scoped
ML-DSA and ML-KEM run through software liboqs on the evaluation path and are not FIPS certified. Native vendor PQC mechanisms are declared per vendor profile but unexercised. The operating-mode policy that gates PQC signing is real and enforced before any session is borrowed — the certification is what is absent, not the enforcement.
Attribute reads are an allowlist, not a denylist
The evidence RPCs accept attribute names, not numeric CKA_ values, and an unlisted name never reaches a PKCS#11 call. CKA_VALUE and every private-key component are permanently unreadable — on a non-sensitive object an unrestricted passthrough would be a key-exfiltration primitive. Denials are recorded before a session is borrowed.
The HSM serial number never leaves memory
It is read once, folded into a SHA-256 hash with a random salt and the tenant id, and the in-memory copy is wiped. Only the salt and the hash are ever written to a licence or binding file. No tool logs, serializes or transmits the raw serial.
Signing is never blocked commercially
No licence status, expiry or quota can prevent a signature. Key generation is the only gated operation, and a suspended licence — the integrator has not paid — bypasses even that, because the bank did nothing wrong and must see zero operational effect.
// OPERATIONAL_POSTURE
How It Starts, How It Fails Over, What Has Been Run.
In plain terms
What happens when the system starts, what happens when a piece of hardware fails, and how much real traffic we have actually pushed through it rather than just designed for.
Resilience and continuity evidence, ending with the blunt version of what has actually been exercised against real modules rather than written and left unvalidated.
Startup sequence
Binary self-attestation before any PKCS#11 call, then library load and pool initialisation, then an HSM-verified Merkle root over every loaded shared object, then audit configuration, then the gRPC port, then a continuous re-verify watchdog. A failure at either attestation step aborts in production rather than degrading.
Session pooling and failover
Pre-opened sessions behind an abstract pool, in either single-slot or health-checked multi-slot HA form, plus a heterogeneous multi-vendor pool for substitutability testing. Borrow/return is per RPC and RAII-scoped.
Key synchronisation
A durable ledger (SQLite or RocksDB) with incremental catch-up on startup, an async worker plus a retry/backoff sweep so key generation is never blocked on a secondary vendor, and a status RPC for operational visibility.
Observability
Three separate pipelines: an HMAC-chained compliance audit trail, a fail-open Prometheus endpoint that can never block a cryptographic operation, and signed GRC attestation reports for regulatory reporting.
Process hardening
A seccomp syscall filter, no new privileges, and a capability set reduced to memory locking only. Syscall observability runs out-of-process in a separate sidecar precisely so the signing daemon never acquires the tracing capabilities it would otherwise need.
What has actually been exercised
SoftHSM2 and Craton, against real modules, including a sustained concurrent-load run of roughly 12,400 signing and 300 key-generation operations with no crashes and a clean sanitiser report. Thales, AWS CloudHSM and Utimaco are written but unvalidated on hardware. The evaluator kit runs on Docker Compose on a single VM; no Kubernetes deployment exists today.
// OBLIGATION_TO_CONTROL
Which Control Addresses Which Obligation.
In plain terms
Financial regulators require specific safeguards. This lists each requirement, the part of A3E9 that answers it, and how far along that part actually is. We are not certified against any of these — this is a map, not a certificate.
A3E9 holds no certification against any of these regimes. This table says which control addresses an obligation and how complete that control is — nothing more. No row is a conformance verdict.
| Obligation | Control | Status |
|---|---|---|
| DORA Art. 9 — ICT risk, traceability | Every ALLOW/DENY is written to a fail-secure HMAC-chained trail before the hardware is touched, including refusals that never reach a session. | Live |
| DORA Art. 17 — incident evidence | The same chained trail plus runtime attestation records; a read-only internal service serves entries back byte-identically so a verifier re-checks the chain itself. | Live |
| DORA Art. 29 — substitutability | Normalized PKCS#11 across five vendor shims with health-checked failover. Bounded: non-extractable signing keys are deliberately not duplicated, and only two vendors have been exercised on real modules. | Partial |
| MiCA Art. 70 — authorization & record | Signing is gated on a verified caller identity and key class before the HSM is called, and the decision is recorded either way. The proof bundle a client would disclose is only partly built. | Partial |
| GDPR Art. 5 — data minimisation in proofs | Identity-scoped and zero-knowledge proof scoping is filed IP with no implementation. | Roadmap |
| FIPS 140-2 L3 — module boundary | Depends entirely on the hardware a deployment brings. The evaluator kit runs software modules with no certified chassis. | Partial |
| FIPS 203/204 — PQC migration | Hybrid classical + ML-DSA signing and a server-wide operating-mode policy are enforced; the algorithms themselves run on uncertified software liboqs today. SLH-DSA (FIPS 205) is not implemented — there is no request enum and no wired PKCS#11 mechanism for it. | Partial |
// WHAT_THIS_DOES_NOT_PROVE
The Limits, Stated Up Front.
In plain terms
The honest limits of everything above, in one place. If something elsewhere on this site sounds like a bigger claim than what is here, this section is the one that is right.
Listed here rather than discovered three documents in. If any claim elsewhere on this site appears to exceed one of these, the limit is what is correct.
No certification is claimed, anywhere
A3E9 holds no FIPS, DORA, MiCA or GDPR certification. The tables here say which control addresses an obligation and how complete that control is. They are not a conformance verdict, and no row should be read as one.
Post-quantum conformance is real but partial
225 of the 420 vectors NIST publishes for these algorithms now run against our implementation and pass. The other 195 are unreachable through the liboqs public API — key-validity checks, pre-hashed ML-DSA, the ML-DSA internal interface, and all of ML-DSA key and signature generation, which need randomness injection the API does not accept. They are excluded with a stated reason rather than silently skipped. None of this is CAVP or CMVP validation, and liboqs is not a FIPS-certified module.
Two vendors, not five
SoftHSM2 and Craton are the only PKCS#11 modules exercised against real implementations. Thales, AWS CloudHSM and Utimaco shims are written and load, but no claim here rests on hardware they have never run on.
The evaluator kit is not a production topology
It runs on Docker Compose on a single VM. There is no Kubernetes deployment, and the software modules it drives have no certified hardware chassis. What the kit demonstrates is the control plane and the evidence it produces, not a hardware security boundary.
// NEXT
The Live Stack Is the Part That Needs Provisioning.
Everything above is checkable without talking to anyone. What sits behind the evaluator token is the running system — cryptographic operation metrics, submitted test payloads, the audit trail those payloads produce, and the reproducible walkthroughs. That needs a provisioned environment, which is the only reason it is gated.