All evidence
// EVALUATOR_KIT · NO_LOGIN_REQUIRED
What the Token Opens, Described Before You Ask for One.
The evaluator kit is a pinned signing-server image driving two software PKCS#11 modules on Docker Compose on a single VM. That sentence contains everything a reviewer needs to know whether it can answer their question — and for a question about certified hardware, the answer is that it cannot. Better established here than after a provisioning round trip.
// WHAT_IS_IN_IT
A Pinned Image and Two Software Modules.
Nothing in the evaluation pool is physical HSM hardware. The pool is SoftHSM2 as primary — a well-known open-source software PKCS#11 token — and A3E9 Craton as secondary, A3E9's own software PKCS#11 module.
The signing server is pinned
The stack runs a specific tagged evaluator image rather than a floating latest, so two reviewers on different days drive the same binary and a result stays attributable to a build.
Two structurally independent modules
SoftHSM2 and Craton are separate implementations, which is what makes vendor failover a real test rather than a restart of the same code. Both are software. Multi-vendor routing, health detection, failover and the resilience trail are the same code path whether a slot is backed by software or silicon — that is the claim, and it is the only one the pool supports.
A third vendor profile that is not what its name suggests
The kit can switch its default pool to a profile named for a hardware vendor. It is a FIPS-mode SoftHSM2 variant, not that vendor's module, and it is excluded from the resilience tests for exactly that reason. It is named here so nobody reads the switch script and concludes hardware was in the pool.
Policy packaging is lab packaging
The kit keeps policy files in one flat directory with a permissive default rule. That is a packaging choice for a lab, not the architecture: policy is segmented, mostly opt-in, and bound to a verified caller identity, and most of it is simply not enabled here. A reviewer inspecting the policy directory is looking at the kit, not the product.
Limit
No hardware security boundary, no tamper detection, and no FIPS 140-2 Level 3 isolation. Every operation is ordinary in-process software. One of the acceptance tests (P7) exists specifically to make a reviewer verify that honesty against the dashboard rather than take it from a paragraph like this one.
// WHO_RUNS_WHAT
Six Tests You Drive, Four That Need the VM.
A browser cannot take an HSM away from a running process, and the kit deliberately exposes no RPC that fakes an outage — an outage the product can trigger on itself is not an outage. So the real-outage tests need one command run on the VM by whoever operates it, while the reviewer observes and judges every result from the portal.
| Test | What it establishes | Driven from |
|---|---|---|
| D1 | Multi-vendor failover drill | Portal — you |
| D2 | KeySync — transit KEK synced, signing keys honestly blocked | Portal — you |
| D3 | Sign after failover — primary path and audit trail intact | Portal — you |
| D4 | Real primary outage — routing fails over, keys honestly do not | VM — operator |
| D5 | Real secondary outage — production unaffected | VM — operator |
| D6 | Recovery both sides — secondary automatic, primary by restart | VM — operator |
| P1–P2 | Generate a classical anchor key, then a linked ML-DSA-65 key | Portal — you |
| P3–P5 | Post-quantum sign, verify, and classical sign on the same key family | Portal — you |
| P6 | Disallowed post-quantum modes correctly rejected, both denials at AUDIT level | Portal — you |
| P7 | Vendor path honesty — the dashboard states software, not hardware | Portal — you |
The resilience half passes only if both outage directions pass. One direction is not a bidirectional resilience result, and the acceptance plan records that outcome as incomplete rather than as passed with a caveat.
// WHAT_THE_KIT_DOES_NOT_PROVE
Stated Before You Spend a Day on It.
The kit demonstrates a control plane and the evidence it produces. Several things a reviewer might reasonably hope to conclude from it are not available at all.
Not a hardware security boundary
Both modules are software. Nothing observed here says anything about tamper resistance, physical key extraction, or a certified module's behaviour under attack.
Not a production topology
Docker Compose on a single VM. There is no Kubernetes deployment, no HA control plane and no production PKI in this environment.
Not a compliance determination
Nothing in the kit says a regulation is satisfied, and no summary of it should. Compliance is a determination the reviewing organisation makes; what the kit offers is evidence about specific behaviours.
Not a certified algorithm implementation
The post-quantum path runs software liboqs, which holds no FIPS certification. Vector conformance is published separately and is self-reported — it is not a CAVP or CMVP result.
// WHAT_A_TOKEN_ADDS
Everything on this page describes an environment. A token is what lets you drive it: take a vendor away and watch routing fail over, or have a post-quantum request denied on policy and then allowed.
Everything above is checkable without contacting anyone, and is meant to be read first. The token exists because the remainder needs a provisioned environment — not because the evidence is being held back.