// 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.
// PROGRAMME_STATUS
What This Surface Is, and What It Is Not.
In plain terms
Real files you can download and check, produced by a lab rather than by a live bank. Read both columns — either one on its own gives you the wrong picture.
Two things are true about this surface at the same time, and either one read without the other gives the wrong answer. The artifacts are generated from real runs and you can check them yourself. The environment that produced them is a laboratory, not a deployment. Both lists below are already evidenced further down this page or on the artifact page named in the map — nothing here is a new claim.
// WHAT_IS_HERE
The artifacts are generated, not written
The cryptographic inventory comes from a source scan of the signing stack, the package inventories come from the build tools that resolved each dependency graph, and the conformance record is the file the known-answer binaries emitted on a run. Every count rendered on this site is read out of those files at build time. None is typed by hand, which is why improving coverage upstream cannot leave this surface quietly overstating it.
The verify path has been run against these bytes
The CBOM ships with its detached signature and the public key beside it, and the check needs nothing but OpenSSL — no A3E9 tooling, no account, no trust in this page. The same reproduction has been run against the bytes served here, so a reader repeating it is confirming a result rather than discovering whether the instructions work.
Refusals are code paths, with tests
Taproot signing, cross-vendor duplication of a non-extractable key, and unlisted attribute reads are refused by the implementation, not discouraged by documentation. Each refusal has a test behind it and records the denial before any hardware session is borrowed. Several cost capability that would be easier to advertise than to decline.
Gaps sit beside results, not after them
Published vectors that did not run are listed with the reason they could not, the repositories with no package inventory are named rather than omitted, and where an artifact does not exist yet its page says so. An index that listed only the sections that turned out well would be a brochure.
// WHAT_THIS_IS_NOT
Not a production deployment
What produced this evidence is not a production deployment: it is Docker Compose on a single VM, driving software PKCS#11 modules with no certified hardware chassis. There is no Kubernetes topology. SoftHSM2 and Craton are the two modules exercised against real implementations; the Thales, AWS CloudHSM and Utimaco paths are written and unvalidated on hardware. What the environment demonstrates is the control plane and the evidence it emits, not a hardware security boundary.
Not a certification
A3E9 holds no FIPS, CAVP or CMVP certificate of its own, and none is claimed anywhere on this site. The obligation tables further down say which control addresses a given requirement and how far that control currently reaches. No row on them is a verdict, and a row should not be quoted as one. The post-quantum path in evaluation runs on software liboqs, which is not a FIPS-certified module.
Not a production attestation
The signature on the cryptographic inventory was made with a development Ed25519 key in a software SoftHSM2 token, not a production HSM key. It is a cryptographically valid signature and it is good for exactly one thing: change detection, proving the bytes served here are the bytes that were signed. It attests to nothing an auditor should rely on, and the artifact page says so beside the verify command rather than in a footnote.
Not a known-vulnerability clearance
The package inventories are published; a dated vulnerability or licence match against them is not. An inventory records what a build resolved — it does not assert those versions are free of known issues. No evaluator token adds a scan that has not been run, and the repositories with no inventory at all could not be matched even if one had been. The absence is stated here because a reader is entitled to assume the opposite of a page that stays quiet about it.
// READING_MAP
This map is a starting point, not a filter. Every page listed here is public, ungated and shown in full to every visitor — this surface has no audience selector, and no page on it is hidden from anyone. The audiences named are lenses: the question each tends to ask first. None of the organisations named has reviewed, endorsed or certified anything on this site.
| Page | The question it answers first | Lenses that ask it |
|---|---|---|
| /evidence/conformance | Which primitives, which parameter sets, which known-answer tests — and which published vectors did not run, with the reason? | NIST / standards conformance |
| /evidence/cbom | Which cryptographic assets are in the stack, and how is that inventory signed — including what the signature is not good for? | NIST / standards conformance · Unit 8200 / adversarial review |
| /evidence/boundary | Which maths runs in A3E9's software, which runs inside the vendor module, and what does neither of them claim? | NIST / standards conformance · IBM / enterprise architecture |
| /evidence/sbom | Which packages did each build resolve, which repositories have no inventory at all, and is there a dated vulnerability match? | Unit 8200 / adversarial review · IBM / enterprise architecture · Bank / multi-vendor HSM · EU supervisor / DORA · Wallet / intent security (TINL) |
| /evidence/audit | What does an audit record actually look like, how does the chain rule work, and why are the samples synthetic? | EU supervisor / DORA · Unit 8200 / adversarial review |
| /evidence/kit | What would an evaluator token open, what runs from the portal versus the VM, and what can the kit not prove? | IBM / enterprise architecture · Bank / multi-vendor HSM |
| /evidence/rwa | Did anything reach a real signature end to end, which correlators exist, and what was deferred? | RWA platform (institutional) · MiCA / crypto-asset regime |
// 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/sbom
The Dependency Inventories, and Their Gaps
CycloneDX SBOMs across eight repositories, listing every resolved component with its version, licence and dependency edges, each with a published digest. The coverage table comes first and names the five in-scope repositories that have no SBOM at all, with the specific reason for each — a C++ build with no generator run, dependencies pinned as git submodules, a service with no lock file to resolve. No dated vulnerability or licence match against these inventories is published, and the page says so as a section rather than leaving it to be inferred.
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.
The files are real; the deployment is a laboratory
Every artifact linked from this page downloads, and the ones that carry a signature verify against the published public key. None of it came from a production system: the environment behind it is Docker Compose on a single VM driving software PKCS#11 modules, and the inventory signature is a development key good only for change detection. Both halves hold at once. Citing the artifacts as a product record, or the laboratory as evidence that nothing was built, are both misreadings of the same page.
// 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.