Console.

AI workbench for quality and security teams.

The console shows AI findings beside the signed evidence they came from. Operators can approve, reject, annotate, or export findings; every decision is logged to the customer manifest.

Fleet view.

One screen, every printer in your deployment. Each row is a printer; each cell is a posture field.

fleet  // 41 printers, 3 sites, all green
┌──────────────────┬───────────┬──────────┬───────────┬────────────────────────────────────┐
│ printer            │ site       │ firmware  │ hsm state  │ last sign / posture                  │
├───────────────────┼───────────┼──────────┼───────────┼────────────────────────────────────┤
│ BAY-A4-PRINTER-07 │ warwick-A │ 2026.05r3 │  unlocked  │ 12 min ago / 7.40 prints/h           │
│ BAY-A4-PRINTER-08 │ warwick-A │ 2026.05r3 │  unlocked  │ 04 min ago / 6.81 prints/h           │
│ BAY-B2-PRINTER-11 │ warwick-B │ 2026.05r3 │  unlocked  │ 22 min ago / 5.10 prints/h           │
│ ROC-01-PRINTER-03 │ rochester │ 2026.05r3 │  unlocked  │ 09 min ago / 8.02 prints/h           │
│ … (37 more)      │            │            │             │                                       │
└───────────────────┴───────────┴──────────┴───────────┴────────────────────────────────────┤

Posture cells are colour-coded; the console UI does not bury anything. Yellow means action recommended; red means action required and the manifest has a corresponding advisory. We have not shipped a colour beyond red.

Signed inbox.

Every operational message you receive from 3DCIPHER appears in the inbox: advisories affecting your deployment, build-key rotations, ceremony events, scheduled firmware updates, support ticket updates. Signed by the build keys; ceremony-anchored.

The inbox is also exposed as a signed Atom feed for ingest into customer SIEMs. Signed Atom is unusual; we wrote a small reference parser in Python and Go to make integration trivial.

Audit-package builder.

One workflow, two clicks for typical audits.

1. Select sample (CSV upload, manifest-query, stratified random, or a saved sample profile from a prior audit).
2. Select framework (NIS2, EU CRA, AS9100, FDA 21 CFR 820, ISO 13485 if scoped, or "custom evidence package").
3. Optionally adjust retention horizon, redaction profile, and verifier-CLI version pinning.
4. Sign & build. The package is built on a customer-owned compute (audit-builder daemon, ships with the SDK); 3DCIPHER does not see the contents.
5. Hand to auditor. The auditor verifies offline with the verifier-CLI. We have observed median verification time of 18 minutes for a 240-part sample.

The audit-package builder is opinionated: it does not let you produce a package that the verifier will reject. If a TwinCert record is missing a required field for the chosen framework, the builder refuses to build and tells you exactly which field on which record. We do not let auditors discover that during the audit.

Ceremony participation.

Customer roots are typically created during a witnessed enrolment ceremony at deployment time. The console exposes the ceremony participant role for customers who choose to participate in the routine ceremony events: build-key rotation observation, firmware-release attestation, and (every 36 months) the ceremony-root rotation.

• Build-key rotation observation. Customers can observe quarterly build-key rotations live. The signed observation event is attached to the customer's audit timeline.
• Firmware release attestation. Customers in scope of regulated frameworks can opt into per-release attestation; their TwinCert profile then records the attestation reference.
• Ceremony-root rotation participation. Customers can nominate observers for the 36-month root rotation. We require at least one independent observer beyond the 5-of-9 custodians; customers have provided this observer for the last two rotations.

Customer key rotation.

Customer roots rotate on a customer-defined schedule, typically 36 months. The rotation workflow is in the console; the actual signing happens in the customer's HSM. We never touch customer key material.

1. Schedule a rotation event in the console (date, custodian quorum, optional observer).
2. The console pre-flights the customer's deployment: open prints, scheduled firmware updates, pending TwinCerts.
3. At ceremony time, custodians authenticate over hardware tokens; the new root is generated inside the customer HSM; a signing-key transfer document is signed by the previous root, the new root, and (if elected) the observer.
4. The customer manifest is rolled forward; in-flight artifacts are countersigned by both roots during the migration window (default 30 days).
5. After the window, the previous root retires from active signing. It remains valid for verifying historical artifacts forever.

Access and roles.

Roles bind to your IdP groups; we publish a SCIM reference for Okta, Entra, JumpCloud, and Keycloak. SSO is required — we do not issue passwords. Hardware tokens are required for fleet-engineer and above; we recommend YubiKey 5 series and Solo 2 series; full compatibility matrix in the customer documentation.

Public preview.

We do not run a sandbox account on the public site — the console runs against signed live data and there is no useful sandbox view. What we offer instead:

• A recorded walkthrough (12 minutes, narrated) covering fleet, inbox, audit-package, and ceremony observation. Available on request to qualified customers via contact.
• The console source — client-side — is published under the same reproducible-build process as the verifier-CLI. You can inspect the UI before signing a contract.
• A reference deployment in a customer lab (one customer has authorised this with their console version frozen at a prior release); ask for access.