On 11 September 2026, one of the earliest operational duties under the Cyber Resilience Act (CRA) starts applying to manufacturers of products with digital elements: actively exploited vulnerabilities and severe security incidents must be reported through the new central platform. This is more than another compliance date. Within hours, teams will have to connect product identity, affected markets, a technical assessment and corrective measures.
A Digital Product Passport or a QR-linked product page can help identify a device and later tell users about an update. It is neither the statutory reporting channel nor a suitable repository for confidential exploit details. Manufacturers should therefore separate three data paths now: the authority report, public product information and the internal update history.
The new trigger: guidance published on 27 and 31 July
On 27 July 2026, the European Commission published its first comprehensive guidance on the CRA. It covers reporting obligations, risk assessments, support periods and substantial modifications, among other topics. The guidance is non-binding, but its 67 examples help explain how businesses can apply the regulation in practice.
Four days later, on 31 July, ENISA updated its information on the Single Reporting Platform. It now sets out the intended workflow, proposed data fields and registration guidance. The platform is scheduled to be operational by 11 September 2026; according to the Commission, functional and security testing is already under way.
The staggered timetable matters. Most CRA obligations apply from 11 December 2027, but Article 14 on reporting applies from 11 September 2026. This is stated in Article 71 of Regulation (EU) 2024/2847 and in the Commission's CRA reporting overview, updated on 31 July.
Three data spaces instead of an overloaded product passport
A CRA report and a public product page serve different purposes. Combining both in a single record risks either starving the incident team of necessary detail or exposing sensitive information on the public web.
1. Confidential reporting to the SRP, CSIRT and ENISA
The Single Reporting Platform is the statutory entry point. Two event types must be reported: an actively exploited vulnerability for which there is reliable evidence of unauthorised exploitation, and a severe incident affecting the availability, authenticity, integrity or confidentiality of data or functions.
A notification contains more than a product name. ENISA lists fields for affected Member States, an initial assessment, corrective measures already taken, steps users can take and the sensitivity of the information. Later stages may include severity, impact, threat-actor information and technical details of the security update. That material does not automatically belong on an openly accessible DPP page.
2. Public product and security information
The public path answers a different set of questions: Which product and version do I have? Is it still supported? Is a security update available? What should I do? A stable product page reached through a QR code or another data carrier can be useful here.
The public page should contain only approved information: affected model and version ranges, the safe version, installation guidance, a support contact and the publication date. Exploit details, internal detection rules, unpatched attack paths and personal incident data remain within the protected process. A QR code does not determine whether to warn the public. Under Article 17 CRA, the coordinating CSIRT may inform the public or require the manufacturer to do so when disclosure is needed to prevent or mitigate a severe incident.
3. Internal update and evidence history
The third path is the auditable working record. It connects the product ID, hardware and software versions, software bill of materials, time of awareness, triage decisions, reporting stages, patch approval and public communication. It should version changes instead of silently replacing earlier assessments.
This distinction is essential in DPP operations: the public view shows the current approved state, while the internal history proves how that state was reached. Teams that already maintain product data through events can apply the same principle used for DPP updates and webhooks: one event triggers follow-up actions, but each recipient receives only the fields appropriate to its role.
The CRA clock starts with awareness
Article 14 establishes staged deadlines. For an actively exploited vulnerability, an early warning is required without undue delay and no later than 24 hours after the manufacturer becomes aware. A fuller vulnerability notification follows within 72 hours. The final report is due no later than 14 days after a corrective or mitigating measure becomes available.
A severe security incident also triggers a 24-hour early warning and a 72-hour incident notification. Its final report is due within one month of the 72-hour notification. The clock does not start when a CVE is published or at the next scheduled release. It starts when the manufacturer is considered aware.
A practical workflow should therefore be explicit:
- Record input from support, monitoring, research or the supply chain with a timestamp.
- Resolve the product and version to a stable internal product ID.
- Have the responsible team assess exploitation or incident severity.
- Generate the 24-hour record from confirmed minimum data and submit it through the SRP.
- Add technical findings for the 72-hour stage without losing the original state.
- Approve the patch, user action and public information separately.
- Link the final report to the internal history.
This chain should be rehearsed before September. ENISA says organisations may automate their internal workflows and integrate reporting requirements into their systems and databases, but no application programming interface will be offered for the platform at this stage. A reviewed export and four-eyes process is therefore more realistic than an unchecked direct integration.
One product ID with separate access rights
Separation does not mean maintaining three disconnected copies. A better design uses one immutable product reference and role-specific views.
At minimum, teams should be able to map:
- the internal product ID and its model, batch or serial scope;
- hardware, firmware and software versions;
- Member States where the affected version was made available;
- security-assessment status and time of awareness;
- references to the 24-hour and 72-hour notifications and the final report;
- approved user action and the safe target version;
- publication status of the public product page.
Authorisation should be considered at field level. The incident team and CRA owner need the full file. Support and sales need an approved action note. Users see only the public advisory. Ideally, the QR code carries only a stable product address; the platform behind it uses status and role to decide which information to return.
What manufacturers should test before September
A useful drill does not require a real vulnerability. Select one connected product, an affected firmware version and three Member States. Simulate awareness on a working day and test the following:
- Can the team confirm product coverage and minimum data within 24 hours?
- Is it clear who will act as the representative accessing the SRP through EU Login?
- Can the 72-hour information be added without making confidential details public?
- Does patch approval trigger a reviewed user advisory in all required languages?
- Does the public URL remain stable when versions and measures change?
- Can the organisation prove who approved each state and when?
The final point depends on disciplined, versioned data maintenance. The qr3 article on keeping DPP data current explains the underlying pattern: identity remains stable while subject-matter data is updated under control. The CRA process adds a stricter confidentiality and approval layer.
Conclusion: the product passport is a distributor, not a reporting desk
The new guidance makes the September deadline operationally tangible. Manufacturers do not need to turn a Digital Product Passport into a confidential vulnerability database. They need a reliable bridge between three clearly separated domains: authority reporting, internal evidence and approved user information.
A shared product ID keeps those domains connected. Roles, approvals and versioning prevent confidential detail from leaking while ensuring users are not told too late about an available remedy. The QR code remains useful but intentionally unremarkable: it points permanently to the right product context. CRA compliance is created by the processes behind it.
