Regulation (EU) 2024/2847 has required manufacturers of products with digital elements to report actively exploited vulnerabilities since 11 September 2026. The first deadline is 24 hours from the moment the manufacturer becomes aware. The obligation applies to every in-scope product made available in the EU, including units sold years before that date.
Most coverage of the Cyber Resilience Act has focused on December 2027, when the essential requirements, conformity assessment and CE marking apply. That framing misses the part that is already running. A manufacturer selling an industrial control board into the EU today owes an early warning within 24 hours if a vulnerability in that board is being exploited, regardless of when the board was built.
The practical question for a buyer is narrower than compliance. It is whether the evidence needed to file that warning can be assembled inside the deadline. That evidence is largely production data, and production data sits with the assembly supplier rather than the brand owner.
What has applied since 11 September 2026
The regulation entered into force on 10 December 2024. Its obligations are staged rather than simultaneous, and the staging is the source of most confusion in procurement conversations.
| Date | What applies |
|---|---|
| 10 December 2024 | Regulation enters into force |
| 11 June 2026 | Rules for notified bodies apply |
| 11 September 2026 | Article 14 reporting of actively exploited vulnerabilities and severe incidents |
| 11 December 2027 | All remaining obligations, including Annex I requirements, conformity assessment and CE marking |
Two points about the September date are frequently missed. The first is that reporting is not limited to new products. Article 14 covers products already placed on the market, so a control board shipped in 2023 falls inside the reporting regime even though it never underwent a CRA conformity assessment. The second is that the reporting duty does not end when the support period ends. Vulnerability handling under Annex I Part II stops at the end of the support period, but the Article 14 duty continues.
Reporting goes through the Single Reporting Platform operated by ENISA, which became operational on the same date. A manufacturer files once. The notification reaches the CSIRT of the Member State where the manufacturer has its main establishment and is made available to ENISA at the same time. A non-EU manufacturer with no Union establishment follows the order set out in Article 14(7), which starts with the Member State of its authorised representative and then its importer.
What the three deadlines actually require
The clock starts at awareness, not at confirmation. A manufacturer that receives a credible report of exploitation on a Tuesday morning has 24 hours to file an early warning, whether or not the root cause is understood by then.
| Stage | Deadline | What it contains |
|---|---|---|
| Early warning | Within 24 hours of awareness | Notification that an actively exploited vulnerability is suspected, with the product identified |
| Full notification | Within 72 hours | Initial assessment of severity, affected versions and any measures taken or planned |
| Final report | Within 14 days of a fix being available | Root cause, corrective measure and the versions covered |
| Final report, severe incident | Within one month of the 72-hour notification | Description of the incident and the mitigation applied |
The 24-hour stage does not demand a fix. It demands identification: which product, which version, and whether the component named in the report is present in shipped units. That last item is where the deadline is usually lost, because answering it requires a component inventory tied to a specific production version.
Three questions a buyer cannot answer alone
When a customer forwards a vulnerability report to an assembly supplier, the supplier either has the answers or does not. There is no way to construct them retroactively inside a day.
The first question is which firmware or configuration image was programmed into the affected units. The image itself belongs to the customer, but the record of which image went into which build belongs to the production floor. A supplier that records the image checksum and version against the work order can answer within minutes. A supplier that records only a date code cannot answer at all.
The second question is whether the named component appears in the affected build, and under which manufacturer and date code. A BOM revision is not sufficient on its own, because approved substitutes may have been used. The record that matters is the as-built list, not the as-designed BOM.
A concrete case shows why. A board released in 2024 specifies a particular EEPROM. During an allocation shortage, an approved alternative from a second manufacturer is fitted to three of eleven lots. If that alternative is named in a vulnerability report two years later, the affected population is three lots, not the product line. Without the substitution record, the only defensible answer is every lot, and the notification becomes an order of magnitude larger than the incident.
The third question is which production lots and shipping dates are in scope. Without lot-level traceability from incoming inspection through reflow to final test, the affected population cannot be bounded, and an unbounded population has to be reported as the whole product line.
These three records are ordinary quality system artefacts. They are not new work created by the regulation. What changed in September is that they are now on a 24-hour critical path rather than a periodic audit path.
The SBOM deadline is a BOM problem
Annex I Part II point 1 requires manufacturers to identify and document the components contained in a product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies. The SBOM does not have to be published, but it forms part of the technical documentation and a market surveillance authority can request it.
For a board with a microcontroller, a wireless module and a vendor-supplied bootloader, the top-level dependencies are determined at the BOM and the supplier approval stage. An SBOM generated after the fact from a released BOM will be wrong in exactly the cases that matter, because the parts that were substituted during a shortage are the ones most likely to carry a vulnerability.
The applicable date is 11 December 2027. Article 69(2) removes units placed on the market before that date from the Annex I Part II obligation, so a board shipped in 2023 does not acquire a retrospective SBOM duty. New units of the same model shipped after that date do. The result is an asymmetric window. Reporting already applies to the old units, while the inventory obligation only arrives for the new ones.
For a buyer, the consequence is that the SBOM cannot be treated as a document to be assembled in 2027. It is a by-product of how the BOM, the substitute approvals and the engineering change notices are maintained now. A supplier that cannot produce a versioned BOM snapshot per build will not be able to produce an SBOM per release either.
Where this overlaps with the Machinery Regulation
A control board inside an industrial machine can fall under both Regulation (EU) 2023/1230 and the Cyber Resilience Act. The CRA addresses this directly in recital 53. A manufacturer subject to both has to meet the essential health and safety requirements of the Machinery Regulation and the essential cybersecurity requirements of the CRA, and the same recital notes that compliance with the CRA can support compliance with the machinery requirements on protection against corruption and on the safety and reliability of control systems, set out in sections 1.1.9 and 1.2.1 of Annex III to that regulation.
The two dates do not coincide. The Machinery Regulation applies from 20 January 2027. The main CRA obligations apply from 11 December 2027. A machine builder therefore has one technical file that will be examined against two regimes eleven months apart, and the cybersecurity evidence assembled for the earlier date is the natural input for the later one.
This is the practical argument for treating the two as one documentation exercise rather than two. A board supplier asked in early 2027 to support a machinery technical file will be asked again in late 2027 for the same underlying records, restated in SBOM form. Preparing them once, in a structure that serves both, avoids doing the work twice.
The support period is longer for industrial boards
Article 13(8) requires a support period that reflects how long the product is expected to be in use, with a minimum of five years. The recitals are explicit that products intended for industrial settings, such as industrial control systems, are often in use for significantly longer periods, and that longer support periods are expected for such products. Article 13(9) requires each security update to remain available for at least ten years after issue, or for the remainder of the support period if that is longer. Article 13(19) requires the end date, at least to the month and year, to be clear at the time of purchase.
A five-year floor on a board that carries an eight-year field life has a direct consequence for component sourcing. Over that window, at least one memory device, one power device and one interface IC in a typical industrial BOM will reach end of life or change die. Each change is a potential substantial modification, and each one resets part of the evidence trail unless the substitution was documented at the time.
The support period also sets the retention requirement. Records that support a ten-year update archive have to survive longer than the people who created them, which is a data management problem rather than a documentation problem.
What an assembly supplier can and cannot provide
The boundary is worth drawing clearly, because buyers often assume an assembly supplier carries obligations that belong to the manufacturer placing the product on the market.
| Item | Assembly supplier | Manufacturer placing on the EU market |
|---|---|---|
| BOM revision and as-built component list per lot | Provides | Receives and keeps |
| Substitution approval record with customer signature | Provides | Approves |
| Programming image version and checksum per work order | Provides as a production record | Defines and owns the image |
| Lot traceability from incoming inspection to final test | Provides | Receives |
| Firmware development, maintenance and vulnerability response | Not provided | Owns |
| SBOM authorship and maintenance | Supplies component data | Owns and signs |
| Cybersecurity risk assessment and CE conformity assessment | Not provided | Owns |
| Vulnerability monitoring and Article 14 notifications | Not provided | Owns |
Kilandu does not develop or modify customer firmware and does not issue CE declarations under the CRA. The supplier-side contribution is the production record: which components were fitted, from which manufacturer and date code, under which approved substitution, with which programmed image, in which lot, shipped when.
Inspection records are held against a workmanship standard such as IPC-A-610, but an inspection result only helps in this situation if it is attached to the lot rather than to the model.
That contribution sounds modest until the 24-hour clock starts. At that point it is the difference between a notification that names an affected population and one that names an entire product line.
What changes in the supplier agreement
The regulation places no obligation on an assembly supplier. It places obligations on the manufacturer, and the manufacturer meets them through its supply chain. That gap is normally closed in the purchase agreement, and most agreements written before 2026 do not close it.
Four clauses cover most of the exposure. The first fixes a retrieval obligation rather than a retention obligation: not only that records are kept, but that a specified record can be produced within a stated period, typically one working day, on request. Retention without retrieval is the failure mode that shows up on the morning a report arrives.
The second requires the supplier to pass on any vulnerability information it receives about components it fitted, without waiting for the customer to ask. Device makers and distributors issue these notices routinely. A supplier that receives one and files it without forwarding it has broken the chain at the only point where the information existed.
The third makes substitute approval a written precondition rather than an operational convenience. Where an approved alternative was fitted under a documented approval, the as-built record supports the customer. Where a substitute was fitted under a verbal understanding, the supplier has created an unrecorded population that the customer cannot describe in a notification.
The fourth sets a notice period for end-of-life and change notifications on components inside the declared support period. A product change notice received with ninety days of runway can be absorbed into a planned build. The same notice received with three weeks leaves the choice between an unapproved substitute and a line stop.
None of these clauses makes a supplier compliant on the customer's behalf, and none should be drafted as a compliance warranty. They describe what the supplier will hand over and how fast, which is the only part of the chain the supplier controls.
What to ask before the next build
Four questions cover most of the exposure, and all of them can be settled before an order is placed rather than after a report arrives.
1. Can the supplier produce an as-built component list, not just a BOM revision, for a specific work order, and how long does retrieval take.
2. Are approved substitutes recorded against the customer approval that authorised them, and can that record be retrieved by lot.
3. Is the programming image version recorded per work order, including a checksum that can be matched against the customer's released image.
4. How long are production records retained, and do they survive the support period the customer intends to declare.
A supplier that answers these four without hesitation is already most of the way to the evidence structure the regulation assumes. A supplier that answers them with a promise to check is describing a retrieval problem that will not be solved inside 24 hours.
Sources
- European Commission, Cyber Resilience Act reporting obligations.
https://digital-strategy.ec.europa.eu/en/policies/cra-reporting - European Commission, Safer and more secure digital products, 11 September 2026.
https://commission.europa.eu/news-and-media/news/safer-and-more-secure-digital-products-2026-09-11_en - Regulation (EU) 2024/2847 of 23 October 2024 (Cyber Resilience Act), OJ L 2024/2847, 20 November 2024.
https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng - ENISA, CRA Single Reporting Platform, frequently asked questions.
https://www.enisa.europa.eu/topics/product-security/vulnerability-services/eu-incident-response-and-cyber-crisis-management/single-reporting-platform-srp/frequently-asked-questions
Reporting dates and deadlines checked against the European Commission pages on 8 November 2026. Article and annex references follow the consolidated text of Regulation (EU) 2024/2847. This page describes the assembly-supplier side of the evidence chain and is not legal advice or a conformity assessment.
Related resources
-
Welcome customers to visit our branch companies for factory inspection and guidance
-
ExpeElectronica2024 in Munich, Germany
-
Connecting Infinite Possibilities | Bao'an District New Union 'Ignite Learning' Class (including our Shenzhen Jintianlei Innovation Technology Co., Ltd.) visited Biz Link to discuss new
-
Welcome French customer PACE to visit our factory for audit
-
PCBA industry global prospects