Digital Product Passport Security and the Cyber Resilience Act
Article 11 of the Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781, sets the security duties for every digital product passport (DPP): data authentication, reliability, and integrity; a high level of security and privacy, with fraud avoided; access for each stakeholder group (customers, repairers, recyclers, authorities, and others) according to its access rights; and availability after an insolvency, liquidation, or cessation of activity. Article 10 adds a back-up copy held by a DPP service provider, which Article 2 defines as an independent third party. A record that must resist forgery, enforce access by role, and outlive its publisher is a security system as much as a sustainability record.
For connected products, the Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, adds cybersecurity duties for the product itself. Since September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe incidents, starting with an early warning within 24 hours. From December 11, 2027, the essential cybersecurity requirements, vulnerability handling, support period, and software bill of materials (SBOM) duties apply. One security program can meet both regulations if it treats the passport platform, its application programming interfaces (APIs), and its domains as attack surface.
What ESPR requires for passport security
Passport duties reach a product group only through a Commission delegated act. Under Article 9 of the ESPR, a covered product can be placed on the market only if its passport is available and its data is accurate, complete, and up to date. Each act sets the passport content, data carrier, granularity (model, batch, or item), access rights, and an availability period of at least the product's expected lifetime. The Commission's digital product passport page schedules the iron and steel delegated act for Q4 2026, and passports for certain batteries under Regulation (EU) 2023/1542 start on February 18, 2027. Our digital product passport guide covers the full schedule.
Articles 10 and 11 set the operating rules below.
| Provision | What it requires | Security property |
|---|---|---|
| Article 11(b) | Access free of charge for each stakeholder group, based on its access rights | Authorization |
| Article 11(f) | Rights to introduce, modify, or update data restricted by those access rights | Integrity and authorization |
| Article 11(g) | Data authentication, reliability, and integrity ensured | Authenticity and integrity |
| Article 11(h) | A high level of security and privacy, with fraud avoided | Security, privacy, and fraud prevention |
| Article 11(e) | Availability for the set period, including after an insolvency | Availability |
| Articles 10(4) and 2(32) | A back-up copy through an independent third-party DPP service provider | Resilience |
Article 11 also bars DPP service providers from selling, reusing, or processing passport data beyond what their service needs unless the economic operator agrees. It authorizes the Commission to set requirements for those providers and, where appropriate, a certification scheme, and the Commission's DPP page lists that delegated act for 2027.
The DPP standards
Implementing Decision (EU) 2026/1736 cited six harmonized standards in the Official Journal on July 15, 2026, giving a presumption of conformity with Articles 10 and 11. Two carry direct security weight: EN 18222:2026 on APIs and EN 18221:2026 on data storage, archiving, and persistence. CEN-CENELEC lists the two further standards that complete the set as EN 18239, on access rights management, information system security, and business confidentiality, and EN 18246, on data authentication, reliability, and integrity. The Commission's DPP page scheduled the implementing decision on those two for September 2026.
The DPP registry
The EU DPP registry has run since July 20, 2026. Under Implementing Regulation (EU) 2026/1778, a company must become a verified economic operator before it registers passports, using a qualified electronic seal or an electronic attestation of attributes under the eIDAS Regulation, and that status lasts no more than three years (Article 4). The registry records the passport's integrity as evidence of each registration (Article 8(9)). The seal that identifies your company to the registry belongs in the same key inventory as your signing keys.
A threat model for a digital product passport
Passport data moves from suppliers and internal business systems (ERP, PLM, and PIM) into a vendor-hosted DPP platform. Readers reach it by scanning the data carrier on the product, which a resolver links to the right passport view. The figure marks nine attack points along that path, and the table pairs each one with its control.
| Threat | What it looks like | Control |
|---|---|---|
| 1. Falsified supplier data | A supplier reports recycled content, origin, or substance data its records do not support. | Signed submissions with evidence, sample audits, and a claims review before marketing. |
| 2. Tampering after publication | An insider, a stolen admin account, or a platform flaw alters published data. | Signed records, version history, write rights limited under Article 11(f), and change alerts. |
| 3. Key compromise | Someone obtains the passport signing key or the registry seal. | Keys in a hardware security module or cloud key service, split administration, and tested rotation. |
| 4. Unauthorized reads of restricted fields | A public endpoint returns repairer-only or authority-only fields after a user edits an ID or role claim. | Server-side field-level authorization, federated sign-in, and access tests for every role. |
| 5. API abuse and scraping | A competitor enumerates identifiers to harvest data, or floods the API until readers get errors. | Rate limits, per-client quotas, bot detection, and enumeration monitoring. |
| 6. Loss of availability over the product's life | The vendor exits, the brand becomes insolvent, or a migration breaks links years after sale. | The Article 10(4) back-up, tested restores, contractual export rights, and carrier monitoring. |
| 7. Resolver or domain hijacking, lapsed domains | An attacker changes DNS or resolver records, or registers a domain the brand let lapse, so printed carriers point to a lookalike site. | Registrar lock, multi-factor authentication on DNS accounts, multi-year renewals, and resolver change control. |
| 8. Counterfeit or swapped carriers, QR phishing | A sticker with a malicious QR code covers the genuine carrier and opens a phishing page. | Carriers that resolve only to a brand-controlled domain, tamper-evident labels, and takedown monitoring. |
| 9. Cloned identifiers on counterfeit goods | A counterfeiter copies a genuine carrier onto fakes, so each scan shows a valid passport. | Item-level identifiers where allowed, scan analytics for impossible locations or volumes, and lifecycle status. |
The FBI warned about QR tampering in public service announcement I-011822-PSA (January 18, 2022), which describes criminals placing malicious codes over legitimate ones. Cloned identifiers are hardest to catch under a model-level passport, where every genuine unit shares one identifier. Falsified supplier data also creates exposure under Directive (EU) 2024/825, which amended the Unfair Commercial Practices Directive so that false information about a product's environmental characteristics or circularity aspects, such as durability or recyclability, is misleading when it is likely to change a consumer's decision. Member States must apply those rules from September 27, 2026, so an invented recycled-content figure becomes the brand's problem once marketing repeats it.
Controls that hold up
Sign the data and make it verifiable
Article 11(g) requires data authentication, reliability, and integrity without naming a mechanism. A digital signature over each published record lets any reader confirm who issued the data and that nobody changed it. Verifiable credentials, specified in the W3C Verifiable Credentials Data Model 2.0 (a W3C Recommendation since May 15, 2025), express an issuer's claims in a form that holders and verifiers can check for tampering, which suits supplier attestations that travel up the chain. Check either design against EN 18246 before you commit to it.
Federate identity and enforce access by field
Delegated acts set which group sees which field, and Article 11(f) restricts who can change data. Have repairers, recyclers, and authorities sign in through identity federation (SAML or OpenID Connect against their own identity provider) instead of shared accounts. Use roles for coarse groups and attribute rules for field-level decisions, enforce every decision on the server, and keep the rules in configuration, because each delegated act sets its own access rights.
Log every write and watch the reads
Log every write, administrative action, key operation, and read of a restricted field in a store that platform administrators cannot alter, and alert on bulk reads, changes to published fields, and new API credentials. For connected products, the CRA makes this a product requirement: Annex I, Part I requires products to "provide security related information by recording and monitoring relevant internal activity."
Own the domain and the resolver
A QR code carrier encodes a web address that must work for the product's whole availability period, which makes the domain part of the product. Lock the domain at the registrar, renew it years ahead under a named owner, and require multi-factor authentication on every account that can change its DNS records, one of the actions CISA's Emergency Directive 19-01 required after attackers used stolen credentials to alter DNS records. Resolver rules need change control too, because each rule that links an identifier to its online resources under the GS1-Conformant Resolver Standard is a redirect an attacker would like to change.
Back up, escrow, and test the exit
Article 10(4) requires a back-up copy through a DPP service provider, and Article 2(32) makes that provider independent. Restore from the back-up on a schedule, confirm your resolver can be repointed to it, escrow the public keys and certificate chains readers need to verify old signatures, and write export rights and exit timelines into the platform contract.
Assure the platform vendor and the suppliers
When a DPP platform vendor hosts the passport, the vendor's controls decide whether you meet Article 11. Alongside the selection criteria in our guide to digital product passport software, ask for an ISO/IEC 27001 certificate whose scope names the DPP service and a SOC 2 Type II report covering security and availability, and write Article 11's limit on data reuse into the contract. Put data suppliers through the same third-party risk management process, with signed attestations backed by test reports, certificates, or chain-of-custody records.
Test the passport stack
Commission a penetration test of the full passport stack before launch and after major changes: public views, APIs, the resolver, the admin console, and the ERP, PLM, and PIM integrations. Test with an account for each stakeholder role, because unauthorized reads of restricted fields match two entries in the OWASP API Security Top 10: broken object level authorization and broken object property level authorization.
What the Cyber Resilience Act requires
Scope and remote data processing
The CRA applies to products with digital elements made available on the EU market whose intended or reasonably foreseeable use includes a data connection to a device or network (Article 2(1)). Article 3 extends that to their remote data processing solutions, meaning processing at a distance that the manufacturer designs or is responsible for and without which the product could not perform one of its functions, such as the backend a companion app calls (recital 11). Recital 12 explains that cloud services designed and developed outside the manufacturer's responsibility fall outside the CRA, and it points SaaS to the NIS2 Directive (EU) 2022/2555. On those terms, a vendor-built passport platform that the product does not need in order to work sits outside the CRA, while the connected product and its own backend stay in scope.
Reporting since September 11, 2026
Since September 11, 2026, Article 14 has required a manufacturer that becomes aware of an actively exploited vulnerability or a severe incident affecting its product to notify the CSIRT designated as coordinator and ENISA at the same time through the single reporting platform, which ENISA launched that day. Article 69(3) extends the duty to products placed on the market before December 11, 2027. The Commission's CRA reporting page sets out the clock.
| Event | Early warning | Notification | Final report |
|---|---|---|---|
| Actively exploited vulnerability | Within 24 hours of becoming aware | Within 72 hours | Within 14 days after a corrective or mitigating measure is available |
| Severe incident affecting product security | Within 24 hours of becoming aware | Within 72 hours | Within one month after the incident notification |
Main obligations from December 11, 2027
From December 11, 2027, products must meet Annex I, Part I, which includes protection from unauthorized access, data confidentiality and integrity, availability of essential functions, and logging. Annex I, Part II requires vulnerability handling with an SBOM "in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products." Article 13(8) sets a support period of at least five years unless the product's expected period of use is shorter, Article 13(5) requires due diligence on third-party components, and Annex VII puts the SBOM in the technical documentation. Article 64 allows fines of up to EUR 15 million or 2.5 percent of worldwide annual turnover, whichever is higher, for breaches of Annex I and Articles 13 and 14.
Where ESPR and the CRA meet
A connected product can carry both regimes. The DPP registry supports ICT and energy-related products alongside textiles and steel, and those that connect to a device or network meet the CRA's scope test in Article 2(1). When a delegated act requires a passport for such a product, the manufacturer answers to ESPR Article 11 for the passport and to the CRA for the product. The two meet in shared infrastructure: if passport endpoints share an API gateway, identity provider, or code base with the backend the product needs, a flaw in one is a flaw in both.
One program for both rests on three shared processes.
- One asset inventory lists each product model with its identifiers, data carriers, resolver domains, signing keys and qualified seals, APIs, and SBOMs, and names an owner for each.
- One vulnerability process triages findings from the passport stack and the product together, runs on the CRA's 24-hour clock, and feeds the same vulnerability management metrics.
- One supplier assurance process covers component suppliers under CRA Article 13(5), the data suppliers behind the passport, and the DPP platform vendor.
When BD Emerson designs passport security inside an ESPR compliance program, the access model, signing design, and logging plan come from that shared inventory, so one set of evidence serves the passport and the product.
Frequently asked questions
Does ESPR require digital signatures on passport data? ESPR Article 11(g) requires that passport data authentication, reliability, and integrity be ensured without naming a technology. Digital signatures on passport records and verifiable credentials for supplier claims are two ways to meet it. Check either design against EN 18246, the DPP standard on data authentication, reliability, and integrity.
Does the Cyber Resilience Act apply to a digital product passport platform? The CRA covers products with digital elements and the remote data processing they need to perform their functions. Recital 12 explains that cloud services designed and developed outside the manufacturer's responsibility fall outside the CRA, so a vendor-hosted passport platform that the product does not need sits outside it too. The connected product itself stays in scope.
Who can see restricted fields in a digital product passport? Each ESPR delegated act sets access rights by stakeholder group, and Article 11(b) names groups such as customers, professional repairers, recyclers, customs authorities, civil society organizations, and trade unions. Article 11(f) separately restricts who can add, modify, or update data.
When did CRA vulnerability reporting start, and what are the deadlines? CRA reporting under Article 14 has applied since September 11, 2026, including for products already on the market. Manufacturers send an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available for a vulnerability, or within one month after the notification for a severe incident. All three go through ENISA's single reporting platform.
Can a QR code on a product be used for phishing? Criminals use tampered QR codes for phishing, and the FBI warned in January 2022 that they place malicious codes over legitimate ones, including as stickers on physical codes. A passport carrier should resolve only to a domain the brand controls for the whole availability period.
BD Emerson maps products to ESPR obligations and dates, designs the passport data model and access rights, selects the DPP platform, and designs passport security, including access control, signing, and logging, for the platform your vendor hosts. Read how that work runs in our ESPR compliance practice.
About the author
