CRA in electronics manufacturing, EMS & supply

EMS, ODM, OEM suppliers: the CRA hits you at an unfamiliar point

If you populate assemblies, supply communication modules or build complete devices to customer order, the Cyber Resilience Act (Regulation (EU) 2024/2847) is not first a question of the "right product class" — it is a question of role. The CRA allocates duties along the role at the moment of placing on the market: whoever places a product with digital elements on the EU market under their own name or brand is the manufacturer and carries the main responsibility. Pure build-to-print to customer specification generally does not make you the manufacturer — but that boundary does not run where intuition assumes, but where contracts, labels and firmware ownership draw it.

The real pain of the sector: you sit at the upstream end of the supply chain and deliver fragments — a populated board, a LoRa module, a white-label enclosure with finished firmware. The end customer (the OEM or brand manufacturer) has to assemble the full technical documentation, the risk assessment and the SBOM from these. If they cannot, because you do not hand over the building blocks in machine-readable form, their conformity fails on your delivery. Conversely, if a contract inadvertently makes you the manufacturer (because your brand is on the type plate or you maintain the firmware), you inherit manufacturer duties nobody budgeted for.

This creates dual pressure: downward (your own software components and sub-suppliers) and upward (the evidence your buyer needs from you). SBOM hand-off, update responsibility and reporting paths therefore move from technical detail to contractual and competitive feature. This article provides orientation — it is not legal advice and makes no binding individual determination.

Typical PDE products of the sector and their likely Annex III class

Products with digital elements (PDE) in electronics manufacturing range from the plain populated assembly to the secure element. One principle upfront, often misunderstood: the CRA class follows the end product and its security function, not the manufacturing depth. A standard assembly does not become "critical" because it is complex to build. Conversely, a single component — such as a tamper-resistant microcontroller — may sit in a higher class on its own.

For the majority of standard products, self-assessment under Module A suffices. For class I products (Annex III, "important"), self-assessment is only permitted if the relevant harmonised standards are fully applied — otherwise a notified body must be involved. For class II a notified body is always required, likewise for Annex IV products, possibly with a mandatory EU certification scheme. The technical descriptions of the important and critical categories are specified by Implementing Regulation (EU) 2025/2392. As a supplier you should know your OEM customer's target class — because delivering into a class II end product raises the evidence requirements on your contribution.

Sector standards and demarcation from adjacent regimes

The relevant sector lever is the IEC 62443 family of standards: IEC 62443-4-1 describes the secure product development lifecycle and IEC 62443-4-2 the technical security requirements for components. With documented processes to 62443-4-1 plus secure-coding and hardening evidence, you as a supplier demonstrate your contribution to the CRA conformity of the end product — exactly what an OEM needs in its technical documentation. Going forward, harmonised standards under the CRA will provide the concrete presumption of conformity; IEC 62443 is already the established basis today.

Clean demarcation from neighbouring legal acts matters, because your products often touch several regimes:

• RED Delegated Regulation 2022/30 (Radio Equipment Directive): for radio-capable modules (BLE, Wi-Fi, cellular) the RED cybersecurity requirements apply. There is overlap with the CRA; the requirements are to be considered alongside one another, not played off against each other.
• NIS2 addresses operators of essential and important entities — the organisation, not the product. Your manufacturing IT may be NIS2-relevant; that is a different legal act from the product-focused CRA.
• AI Act applies where a module contains AI functions regulated there — in addition, not instead.
• Automotive type-approval, civil aviation, marine equipment, MDR/IVDR medical devices are separately regulated by sector; corresponding products are exempt from the CRA. Whoever supplies into such end products follows the sector regime.

SBOM and supply-chain reality of this sector

The typical software stack in an assembly is a layer cake of third-party code: bootloader, real-time operating system or embedded Linux, TCP/IP and crypto libraries, radio stacks, vendor drivers and chip suppliers' SDKs. This is exactly where the silent risks sit: end-of-life components with no more security updates, outdated open-source libraries (OSS) with known vulnerabilities, and binary blobs shipped by the chip vendor without provenance. An OEM cannot see these layers — you as EMS/ODM sit at the source and are the only party that fully knows them.

The CRA requires a machine-readable SBOM as part of the technical documentation, at least at the level of top-level dependencies. Machine-readable means specifically CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1 — the format requirement of BSI TR-03183-2 (v2.1.0). A PDF with a component list does not meet this. A robust SBOM per assembly should contain: component name and version, supplier/origin, unique identifiers (e.g. PURL/CPE), licence and the dependency relationships. There is no general publication obligation — the SBOM belongs in the technical documentation and is passed upstream to the buyer, not into the shop window. Whoever generates SBOM fragments per assembly automatically and hands them over cleanly turns it into a selling point; whoever cannot will drop out of tenders.

Reporting capability and PSIRT: reading the Art. 14 cascade correctly

The reporting duties under Article 14 are delicate for suppliers, because a vulnerability in your delivered firmware becomes the manufacturer's reporting duty — and the clock runs from awareness. The cascade for an actively exploited vulnerability or a severe incident reads:

• 24 hours — early warning from becoming aware;
• 72 hours — full notification including corrective and mitigating measures already taken;
• Final report: for an actively exploited vulnerability, within 14 days of a corrective measure becoming available; for a severe security incident, within one month of the 72-hour notification.

The common shorthand "24h/72h/14 days" is therefore wrong — the 14 days and the one month apply to different cases. Reporting goes via the ENISA Single Reporting Platform (SRP) as a single notification to the CSIRT of the main establishment and ENISA; the platform is to be made available by 11 September 2026. In practice this means: you need a working PSIRT process (Product Security Incident Response Team) and a CVD policy (Coordinated Vulnerability Disclosure) that is contractually interlocked with the OEM — who reports, who builds the fix, who supports across the support period (guideline at least five years).

Which deadline bites first: 11 Sep 2026 before 11 Dec 2027

Two dates structure the preparation. First, on 11 September 2026, the reporting and notification duties under Article 14 apply — the first hard manufacturer duty. From that day, actively exploited vulnerabilities and severe incidents must be reported on time, regardless of whether your product already meets all product requirements. Full applicability of all product requirements (security-by-design, SBOM, technical documentation, CE conformity) follows on 11 December 2027. For suppliers this means: the reporting and PSIRT build-up is the more urgent project, full technical conformity the larger one. Planning both in parallel is sensible, because the SBOM basis is needed for both.

Worked example: EMS builds an IoT gateway

A mid-sized EMS provider builds a LoRa IoT gateway for a brand manufacturer. The brand manufacturer sells it under its own brand — it is therefore likely the manufacturer within the meaning of the CRA, with the EMS supplying. The firmware contains an embedded Linux, a LoRa stack from the chip supplier and several OSS libraries, one of them in a version with a known vulnerability. The gateway itself would likely be a standard product (Module A). Initially unresolved: who generates and maintains the SBOM? Who builds security updates across the lifetime? How do CVD reports flow when a security researcher reports a hole in the LoRa stack?

Without contractual clarification the brand manufacturer inherits a chain it does not control. The workable solution: the EMS generates a CycloneDX SBOM per firmware release automatically in the build pipeline, hands it over machine-readable, and a contract settles update responsibility and the reporting chain (24 h / 72 h / final report) so that the manufacturer can actually fulfil its Art. 14 duty from 11 September 2026. This turns the supply from a liability risk into a robust building block.

What Blackfort Technology does for you

Blackfort Technology (Blackfort Technology UG (haftungsbeschränkt)) supports EMS, ODM and OEM suppliers along exactly these points — vendor-neutral and without any official mandate:

• Applicability and role analysis: clarifying in which constellations you are manufacturer, importer or pure contract manufacturer, and what schematically follows (scope per product line).
• SBOM setup: building automated SBOM generation (CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1) per assembly/firmware release, including EOL and OSS risk review and an upstream hand-off process.
• PSIRT and CVD: building a reporting process including a CVD policy and interlocking the reporting chain with your OEM contracts.
• Risk assessment and threat modelling: a documentation-ready risk assessment to Art. 13/Annex I as the method for the technical documentation.
• Technical documentation: structure and content for conformant documentation your buyer can reuse.

A pragmatic entry point is the applicability check. Smaller manufacturers may find our SME perspective useful; the overview of the Cyber Resilience Act provides the technical frame. For a concrete conversation: get in touch. This is a technical orientation and not legal advice.