What we defend, what we do not, and how we know.
This is the public version of our internal threat model. The longer-form version, including private attack trees and rejected mitigations, is delivered in signed customer packages rather than listed as a public download. If your security team needs to challenge an assumption below, that is what the security@ inbox is for — we update this document on signal, not on calendar.
Assets we protect.
The threat model is grounded in cryptographic assets and AI-assisted evidence assets. Everything we build is in service of these; anything that does not protect one of them is not in scope.
| AI model bundle integrity | signed model hashes in manifest, customer-pinned deployment policy | a modified model could mis-rank evidence, hide anomalies, or produce misleading audit summaries |
| AI evidence draft provenance | draft id, model id, source references, reviewer approval trail | untraceable AI suggestions would make audit conclusions hard to defend |
AI-specific assets.
AI does not replace the cryptographic root of trust, but AI outputs influence reviewer attention. We therefore treat model bundles, prompt/policy bundles, evidence drafts, and anomaly scores as first-class security assets.
| asset | where it lives | compromise impact |
|---|---|---|
| ceremony root key | 5-of-9 quorum, geographically distributed HSMs | total loss of trust: every 3DCIPHER artifact ever signed becomes unverifiable |
| printer-side signing keys | per-printer HSM, provisioned at enrolment | that printer's bundles can no longer be trusted; all past bundles remain verifiable |
| as-built bundle integrity | printer-side HSM signature, archived to customer manifest | a forged bundle could attribute a part to a printer that never made it |
| watermark embedding key (per customer) | customer-controlled HSM, ceremony-bound | third parties can no longer prove their parts originated from your designs |
| TwinCert attestation chain | customer-controlled storage, root anchored to ceremony | regulatory evidence stops being verifiable; auditors must fall back to manual records |
Adversaries in scope.
A1 — opportunistic counterfeiter
A third party producing unlicensed copies of an OEM's parts using stolen or rebuilt G-code. Capability: standard slicer toolchain, commodity FDM/SLS printers, no specialised cryptanalysis. Goal: visually-indistinguishable parts that pass casual inspection. In scope — this is the MeshGuard use case.
A2 — corrupted insider, single site
A site engineer with physical access to the printer and the local operator console. Capability: can manipulate slicer inputs, swap firmware, suborn a single operator. Goal: produce parts that are signed but materially defective, or parts that are unsigned but appear signed. In scope — the dual-control rotation procedure and the printer-side HSM are the primary mitigations.
A3 — supply-chain attacker, build pipeline
An adversary that has compromised our build infrastructure or a customer's slicer build. Capability: can inject code into a signed binary or a signed slicer. Goal: weaken signature, exfiltrate keys, embed backdoors. In scope — reproducible builds, dual-control firmware signing, slicer attestation are the primary mitigations.
A4 — nation-state, cryptanalytic
A well-resourced adversary attempting cryptanalysis of the signature scheme. Capability: state-of-the-art classical and (in the planning horizon) quantum computational resources. Goal: forge bundle signatures or recover signing keys. In scope — the post-quantum migration plan (advisory 3DC-2026-05-A1) is the primary mitigation; phase-0 shadow signatures are already running.
A5 — regulator, hostile audit posture
A notified body or competent authority approaching audit in bad faith, attempting to retroactively invalidate signed evidence. Capability: legal and procedural. Goal: declare a customer non-compliant on procedural grounds. In scope — the audit-package generator and the TwinCert NIS2/CRA mapping document are the primary mitigations.
A6 — lost customer (3DCIPHER disappears)
The scenario where 3DCIPHER as a company ceases to exist, and customers need to keep verifying past attestations. Capability: customers retain the ceremony root pin and the verifier-CLI source. Goal: ensure past bundles remain verifiable in perpetuity. In scope — the longevity-mirror agreement (see manifest) and the open verifier-CLI source are the mitigations.
Adversaries explicitly out of scope.
We are honest about what we do not defend against. If your threat model includes any of these, 3DCIPHER alone is not sufficient.
- Compromised printer mechanics. If the printer's stepper motors are physically compromised to produce defective geometry, the bundle will sign correctly — the bundle records what was instructed, not what was deposited. Defence is process: in-process metrology (we integrate with it but do not provide it) and post-build inspection.
- Material substitution upstream of the build. If counterfeit feedstock enters the print chamber, the bundle records the build instructions, not the material. Defence is the supplier chain-of-custody record, which TwinCert can encapsulate but cannot itself verify.
- Side-channel attacks on the printer-side HSM. We use HSMs that are FIPS 140-2 Level 3 certified; we do not claim Level 4. If your threat model requires Level 4, we will discuss bring-your-own-HSM under support.
- Coercion of the entire 5-of-9 ceremony quorum. The quorum is distributed across three jurisdictions specifically to make legal coercion of all five custodians implausible. We do not claim it is impossible.
Attack tree (extract).
The public extract of the attack tree we work from. The full version is delivered as a signed customer package when scoped.
goal: produce a part that passes 3DCIPHER verification but was not actually built by the
claimed printer.
├── forge a printer-side signature
│ ├── exfiltrate the printer's HSM key ........ mitigated: tamper-evident HSM, no exfil path
│ ├── extract the key by side channel ........ mitigated by HSM cert; out-of-scope above Level 3
│ ├── cryptanalyse the signature ............. mitigated: Ed25519 today, hybrid PQ in roadmap
│ └── coerce the key holder .................. printer-side key is in the HSM; no human holder
│
├── substitute the bundle after signing
│ ├── replace bundle in transit .............. mitigated: signature includes bundle hash + nonce
│ ├── replace bundle in customer archive ..... mitigated: archive is append-only, signed Merkle root
│ └── replay an old bundle as new ............ mitigated: bundle includes machine-monotone counter
│
├── induce signing of a malicious bundle
│ ├── corrupt the slicer ..................... mitigated: slicer attestation, signed slicer binary
│ ├── inject malicious G-code post-slice ..... mitigated: bundle covers G-code hash
│ ├── coerce a single operator ............... mitigated: dual-control on rotation; print is OK to sign
│ └── corrupt the firmware on the printer .... mitigated: firmware in bundle; verifier rejects unknown
│
└── attack the trust root
├── forge a key signed by ceremony root .... mitigated: ceremony root in offline 5-of-9 quorum
├── compromise >= 5 of 9 custodians ........ unmitigated below quorum; explicitly out of scope
└── publish a fake manifest ................ mitigated: manifest signed against ceremony root
Coverage matrix.
Which adversary each module addresses.
| A1 counterfeiter | A2 insider | A3 supply chain | A4 nation-state | A5 regulator | A6 lost-vendor | |
|---|---|---|---|---|---|---|
| Vault3D | secondary | primary | secondary | secondary | partial | partial |
| MeshGuard | primary | partial | n/a | n/a | n/a | n/a |
| TwinCert | partial | secondary | n/a | n/a | primary | secondary |
| manifest + ceremony | n/a | n/a | partial | primary | n/a | primary |
Residual risk register.
Risks we have decided to accept rather than mitigate further, with the rationale. We re-review this register each surveillance cycle.
- R-01 · printer-side HSM Level-3 not Level-4.
- Decision: accept. Level-4 HSMs at the per-printer price point would multiply deployment cost by ~5× for a threat (sophisticated side-channel attack on an individual printer key) where compromise is bounded to that printer's future bundles and does not propagate. Re-review trigger: a customer with a hostile state-actor in their threat model, or a Level-3 attack demonstrated in literature.
- R-02 · coerced quorum of 5-of-9.
- Decision: accept. Mitigation by jurisdictional distribution is the practical maximum without imposing custody on parties we cannot directly contract. Re-review trigger: change in the political stability of any custodian's host jurisdiction.
- R-03 · operator collusion (two operators conspire).
- Decision: accept with detection. Dual-control prevents single-operator key rotation; two-operator collusion can rotate but produces a ceremony record that is reviewable by the customer's audit role. Re-review trigger: any customer reporting a near-miss.
- R-04 · slicer build attestation gap (closed-source slicers).
- Decision: mitigated, not eliminated. Our slicer-attestation programme covers the open-source slicers (Prusa, Cura, Orca) and one closed-source slicer under a published agreement. Customers using other closed-source slicers run with a degraded attestation; the TwinCert record captures this honestly.
- R-05 · ceremony root cryptanalysis (Ed25519 -> Dilithium migration).
- Decision: in remediation. Phase-0 shadow signatures live; phase-1 hybrid co-signing scheduled for 2026 Q4. Advisory 3DC-2026-05-A1 carries the full plan. Re-review trigger: NIST publication of a Dilithium parameter-set deprecation.
How this document changes.
The threat model is reviewed under three triggers:
- External signal. A vulnerability report, an academic paper, a peer disclosure, or a regulatory change. Acknowledged within four hours during UK working time.
- Internal observation. An incident, a near-miss, a misconfigured deployment that worked anyway. Triaged at the weekly security review.
- Periodic. Full re-review at the SOC 2 surveillance cycle (annually) and at every customer-specific deployment review.
Changes to the published version are listed in the document's changelog and announced via advisory.