Spherity Research Topic Page

CRA-Capable Digital Product Passports

From static compliance to continuous cyber assurance for connected products, critical infrastructure, and resilient supply chains

Author

Dr. Carsten Stöcker

Affiliation

Spherity GmbH

Published

2026-08-23

Updated

2026-08-24

Research cut-off

2026-08-23 · Management brief status checked to this date; full research evidence cut-off: 2026-08-15

This version

https://spherity.github.io/spherity-research/cra-capable-digital-product-passports.html

Latest version

https://spherity.github.io/spherity-research/cra-capable-digital-product-passports.html

Share ↗

Browse this paper

Management brief: from static compliance to continuous cyber assurance

The management brief frames the Cyber Resilience Act as a board-level operating-model change. CRA implementation is not only a legal documentation exercise. It requires a manufacturer to govern cybersecurity evidence across design, development, production, vulnerability handling, updates, support, customer communication, and post-market corrective action.

The brief translates this into five management decisions:

1. Appoint one accountable executive owner for CRA evidence governance.
2. Fund a digital evidence backbone for CRA conformity, DPP infrastructure, and secure product operations.
3. Adopt the five-subject model: product type, build, instance, deployment state, and remote service.
4. Bound automation explicitly so that legal and safety decisions remain attributable.
5. Prove the model before full CRA application by piloting a high-value product-service scope.

The business value is practical. A CRA-capable DPP helps an OEM answer affectedness, authenticity, support, configuration, update, and remediation questions faster. For customers, especially in critical infrastructure and regulated supply chains, it creates a governed channel for authentic OEM information, authorised updates, current support status, and product-specific security documentation.

Full research: the verifiable evidence architecture

The full research paper develops the CRA-capable DPP as a legal-technical design artefact. It does not present the DPP as a static certificate, compliance badge, or public website. It defines it as a distributed, versioned, and access-controlled evidence architecture that can connect:

• product identity, product type, build, release, instance, deployment state, and remote data-processing service;
• hardware and software composition, including SBOM records;
• vulnerability handling, exploitability status, and VEX statements;
• security updates, update receipts, rollback, recovery, and support status;
• conformity evidence, technical documentation, assessment results, and post-market corrective action;
• functional-safety interfaces and essential-availability considerations; and
• lifecycle events, modification histories, provenance, and current evidence status.

The central contribution is the separation of a control plane from an evidence plane. The control plane establishes legal-person identity, organisational authority, mandate, role, policy, current status, and zero-trust access decisions. The evidence plane carries product claims, assessment results, SBOMs, VEX statements, update receipts, configuration states, modification histories, and evidence paths.

CRA and DPP convergence: legally distinct, operationally connected

The CRA and DPP regimes must not be collapsed. Regulation (EU) 2024/2847, the Cyber Resilience Act, is the EU’s horizontal cybersecurity regime for products with digital elements. It sets requirements for secure design, development, production, vulnerability handling, reporting, updates, documentation, and post-market responsibilities. It does not mandate a Digital Product Passport.

The Ecodesign for Sustainable Products Regulation establishes the Digital Product Passport as interoperable product information infrastructure for sustainability and market-surveillance purposes. A DPP is not automatically evidence of CRA conformity. The strategic opportunity is architectural: product identifiers, versioned data, controlled access, verified economic operators, lifecycle events, and interoperable product information can become a reusable substrate for CRA evidence if cyber evidence, identity, policy, and assurance are added deliberately.

For search and answer engines, the concise answer is:

A CRA-capable Digital Product Passport is product evidence infrastructure for continuous cybersecurity assurance, not a substitute for CRA conformity assessment.

Verifiable evidence graph architecture for CRA-capable DPPs

The evidence graph model is what turns CRA DPP from a document repository into assurance infrastructure. Each material claim should preserve the issuer, subject, version, timestamp, source, signature or proof, validation result, policy context, status, superseding event, conflict, and retention rule. That structure allows a verifier to ask not only “what does the DPP say?” but “which evidence supports this current cybersecurity state, and who is accountable for it?”

This is also where European Business Wallets and eIDAS 2.0 become relevant. A DPP can carry product evidence, but a verifier also needs trustworthy organisational evidence: which manufacturer, importer, distributor, operator, service provider, authority, notified body, or customer representative is acting and whether the mandate is current.

Standards and regulation: CRA, ETSI, ESPR, EBW, and zero trust

The official regulatory baseline is clear. The European Commission states that the Cyber Resilience Act entered into force on 10 December 2024, Article 14 reporting obligations apply from 11 September 2026, and the main obligations apply from 11 December 2027. The Commission also explains that CRA obligations cover planning, design, development, and maintenance across the lifecycle of products with digital elements.

ETSI announced on 13 August 2026 that 17 vertical final draft standards supporting the CRA were under Public Enquiry. Those standards are intended to become harmonised standards that can provide a recognised route toward presumption of conformity once adopted and cited through the relevant EU process. Until then, implementers should treat them as standards in development and avoid overstating legal certainty.

Implementation agenda for product security leadership

The research recommends a staged implementation path.

1. Article 14 readiness by 11 September 2026. Establish roles, vulnerability-reporting procedures, evidence retention, customer communications, and escalation paths.
2. One scoped product-service pilot. Select a connected product or critical-infrastructure product family where SBOM, VEX, update, configuration, support, and customer communication evidence already matter.
3. Five-subject evidence model. Separate product type, build, instance, deployment state, and remote data-processing service so evidence resolves to the right object.
4. Evidence graph backbone. Model SBOM, VEX, updates, conformity evidence, safety constraints, incidents, support, and lifecycle events as versioned evidence objects.
5. Control plane and zero-trust access. Use legal-person identity, role credentials, mandate checks, policy enforcement, selective disclosure, revocation, and action receipts.
6. Customer and authority channels. Support authenticated OEM-customer communication, market-surveillance access, conformity-body workflows, and critical-infrastructure operator assurance.
7. Scale before 11 December 2027. Leave enough time to industrialise evidence capture, policy, tooling, governance, and product-line rollout before full CRA applicability.

This is not only compliance work. It creates product security leadership: an OEM that can prove affectedness quickly, publish authentic updates, preserve support-state evidence, and communicate with customers through governed channels is operationally more credible than a competitor that reconstructs evidence after every incident.

Boundary conditions and interpretive guardrails

The page deliberately separates law, standards, architecture, and strategy.

• A CRA-capable DPP does not itself secure a product.
• A DPP does not automatically prove CRA conformity.
• An SBOM does not, by itself, prove exploitability or remediation.
• A VEX statement is useful only when it is issuer-bound, scoped, current, and connected to the correct product subject.
• Access control is mandatory for sensitive cybersecurity evidence; public transparency and confidential assurance must be distinguished.
• Automation can verify integrity, status, policy, and consistency, but legal and safety decision authority must remain attributable.
• ETSI CRA standards in Public Enquiry should be treated as emerging implementation references until the applicable legal citation and harmonisation process is complete.

Open research

License and citation

CRA-Capable Digital Product Passports is licensed by its named author under the Creative Commons Attribution 4.0 International License (CC BY 4.0). Reuse must credit every named author, link to this canonical version and the license, and indicate whether changes were made.

How to cite this work

Dr. Carsten Stöcker (2026-08-23). “CRA-Capable Digital Product Passports: From static compliance to continuous cyber assurance for connected products, critical infrastructure, and resilient supply chains.” Spherity GmbH. https://spherity.github.io/spherity-research/cra-capable-digital-product-passports.html. Licensed CC BY 4.0.

Copy citation