TwinCert profile for NIS2 / EU CRA.
The TwinCert JSON-LD profile for NIS2 (EU 2022/2555) and the EU Cyber Resilience Act, with article-level mappings. Adopted by two notified bodies as part of their conformity-assessment intake. Customers in scope of NIS2 should align their deployed TwinCert profile with the published one. This document is the public record of the mapping, the assumptions, and the limits.
What this profile is.
The profile is a small extension to the TwinCert schema v2. It adds two things: a regulatory section that names the specific framework and version the part is being claimed under, and a mapping document that explains, article by article, how the TwinCert evidence aligns with the regulator's requirements.
It is not a self-certification scheme. The customer is the one making the conformance claim; the notified body or competent authority is the one accepting (or rejecting) it. The profile makes the conversation between those two parties cheaper, in our customers' experience by roughly 60% measured in auditor-hour billing for the first three audits run through the profile.
Two notified bodies have adopted the profile as part of their intake. They have not endorsed 3DCIPHER as a vendor; they have adopted the schema, which is open. We mention them by category, not by name, because that is the agreement we made when they adopted it.
NIS2 article mapping.
NIS2 (EU 2022/2555) applies to essential and important entities in defined sectors. For our customers (manufacturing of critical equipment, certain medical devices, certain energy components), the relevant articles are around supply-chain security, risk management measures, and incident handling.
| NIS2 article | obligation | TwinCert field(s) | satisfaction |
|---|---|---|---|
| Art. 21(1) | cybersecurity risk-management measures, proportionate | regulatory.framework, provenance.*, custody.* | partial — framework is named; custody chain provides traceability evidence |
| Art. 21(2)(a) | policies on risk analysis and information system security | regulatory.profile | references customer policy; the policy itself sits in customer documentation |
| Art. 21(2)(c) | business continuity (backup, recovery, crisis) | retention.policy, manifest archive policy | partial — retention is named; recovery procedures sit in customer runbooks |
| Art. 21(2)(d) | supply chain security | composition.feedstock_coc, custody.*, provenance.cad_revision | strong — the full custody chain is signed and verifiable end-to-end |
| Art. 21(2)(e) | security in network and information systems acquisition, development, maintenance, and vulnerability handling | references to Vault3D / TwinCert manifest revisions, advisory feed | partial — software-side is referenceable; physical maintenance sits in customer documentation |
| Art. 21(2)(f) | policies and procedures to assess effectiveness of risk-management measures | conformance.* inspection references | strong for the manufacturing dimension |
| Art. 21(2)(g) | basic cyber hygiene practices and cybersecurity training | identity.operator binding via Vault3D bundle | partial — operator identity is bound; training records sit in HR |
| Art. 21(2)(h) | policies and procedures regarding the use of cryptography | references to 3DCIPHER manifest, ceremony root, signing scheme version | strong — cryptographic posture is signed and citable |
| Art. 23 | reporting obligations (significant incidents, 24h early warning) | not covered — out of scope for TwinCert | customer's incident-response process owns this |
The honest read on NIS2 is that TwinCert covers the manufacturing-dimension articles strongly and the operational-process articles partially. We do not claim it is a complete NIS2 compliance package; we claim it removes the manufacturing-evidence collation burden, which is the largest fraction of audit time for our customers.
EU CRA essential-requirement mapping.
The EU Cyber Resilience Act applies to products with digital elements. For additive-manufactured parts containing or supporting digital elements (firmware-bearing parts, parts that integrate with a digital twin), the CRA's essential cybersecurity requirements apply.
| CRA requirement (Annex I, Part I) | obligation | TwinCert field(s) | satisfaction |
|---|---|---|---|
| 1.1 — secure-by-default | delivered with secure default configuration | as_built.bundle_ref → firmware hash + slicer attest | partial — firmware hash is bound; configuration of the embedding system sits in customer documentation |
| 1.2 — vulnerability handling without compromising authenticity | updates are authenticated | references to 3DCIPHER advisory feed + signed firmware manifest | strong — the firmware update path is signed end-to-end |
| 1.3(a) — processing of personal data | data protection by design | not applicable for TwinCert payloads; operator binding stores subject identifier only | customer GDPR compliance handles personal-data scope |
| 1.3(b) — protect data confidentiality, integrity | protection of stored and transmitted data | signature over the full record | integrity is strong; confidentiality is customer's responsibility (TwinCerts are typically not encrypted at rest) |
| 1.3(c) — minimise attack surface | minimisation principle | field set is auditable; customer decides what to include | strong — the customer controls the included set |
| 1.3(d) — security incident reporting | incident handling and reporting | not covered — out of scope for TwinCert | customer's incident-response process owns this |
| 1.3(e) — secure-update support | provide for the installation of security updates | references to firmware update path (RB-25) | strong — the dual-control firmware update path is signed and audited |
| 1.3(f) — vulnerability reporting | publicly accessible reporting mechanism | references to security@3dcipher.com + PGP fingerprint | strong |
| 2 — vulnerability handling requirements | handle vulnerabilities for product lifetime | references to advisory feed | strong — the signed advisory feed is the public record of handling |
Worked example: NIS2 audit, aerospace customer.
One real customer (anonymised, with their consent) ran a NIS2 audit in 2025 Q4 using the TwinCert profile. The audit covered 12 months of production, 8,400 parts, and four manufacturing sites.
The audit sequence:
- The auditor selected a stratified random sample of 240 part serials across the 12-month window.
- The customer ran
3dc audit-package --serials sample.csv --framework NIS2, producing a signed audit package containing the TwinCert records, the referenced Vault3D bundles, the inspection records, the manifest snapshots, and the NIS2 article-mapping document. - The auditor verified the package offline with the verifier-CLI; verification took approximately 18 minutes for the 240-part sample.
- The auditor reviewed the article mapping document and the inspection records referenced therein.
- The auditor asked clarifying questions on three findings: one about feedstock chain-of-custody depth, one about operator-binding session lifetime, one about retention policy for cancelled jobs. All three were answered by reference to the customer's process documentation.
- The audit was concluded with two minor findings (process-side) and zero major findings.
Customer-side billed audit time: approximately 38 hours. The same customer's previous audit cycle (under the old document-collation process) consumed approximately 96 hours of internal time. The auditor's own billable hours dropped by a similar fraction.
Limits, surfaced honestly.
- This is a mapping, not a guarantee. Notified bodies and competent authorities make their own determinations. Two have adopted the schema; others may not. Customers should socialise the profile with their auditor early.
- It does not cover the operational-process articles end-to-end. Articles dealing with policies, training, incident-response procedures are out of scope. TwinCert references them; it does not replace them.
- The CRA scope question is settling. Whether a 3D-printed part with no embedded firmware falls under the CRA at all depends on the part class and the way it integrates with a customer's digital systems. We do not interpret the CRA scope for customers; we map TwinCert to the requirements once scope is established.
- The mapping document evolves. Regulatory framework revisions, ENISA guidance, member-state transposition variations. The profile carries a version (currently rev 2026.03) and we publish revisions in the advisory feed.
What customers in scope should do.
- Read the article mapping document. Identify which articles your auditor will press on; understand which fields in your TwinCert records carry the relevant evidence.
- Pre-share the profile with your auditor or notified body. We have a draft cover note customers can adapt; ask security@3dcipher.com if you want it.
- Validate your existing TwinCert records against the published profile. The verifier-CLI
--framework NIS2flag will identify gaps in your current record set. - Backfill identified gaps. Most gaps we have seen are in the
composition.feedstock_cocfield — older deployments often did not populate feedstock chain-of-custody references. Backfill is straightforward. - Schedule your audit. The customer-side time investment is typically 30–40 hours for a 12-month, multi-site audit cycle under the profile.