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) starts for you with a question of role; the "right product class" comes after that. 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 does not, in principle, make you the manufacturer. Where that boundary runs is decided by contracts, labels and firmware ownership - and intuition can easily misplace 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: the class follows the core function of the product you place on the market, not the depth of manufacturing (Article 7(1)). A standard assembly does not become "critical" because it is complex to build. Conversely, a single component supplied separately - such as a tamper-resistant microcontroller - may sit in a higher class on its own.

For standard products, self-assessment under Module A suffices. For class I products (Annex III, "important"), self-assessment is only permitted if harmonised standards, common specifications or a European cybersecurity certification scheme (assurance level at least “substantial”) are fully applied - otherwise a notified body must be involved (Module B+C or H). Class II requires Module B+C, Module H or a European scheme of at least “substantial”. Annex IV requires a European scheme where a delegated act prescribes one; otherwise the same applies as for class II. The technical descriptions of the important and critical categories are specified by Implementing Regulation (EU) 2025/2392. Important for suppliers: a class I or class II component built into a device does not raise the device's classification (Article 7(1), second sentence); conversely, the class of the end product does not determine the class of the component you supply separately.

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. Harmonised standards for the CRA have been requested (M/606) but were not yet published in the Official Journal on 9 October 2026; IEC 62443 is already the established basis today.

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

• RED Delegated Regulation 2022/30 (Radio Equipment Directive): since 1 August 2025 RED cybersecurity requirements have applied to certain radio equipment, in particular equipment that can communicate over the internet; this can concern radio-capable modules (BLE, Wi-Fi, cellular). There is overlap with the CRA; until Reg. 2022/30 is repealed with effect from 11 Dec 2027, consider both sets of requirements alongside one another, after that the CRA covers them.
• NIS2 addresses essential and important entities - the organisation, not the product. Manufacturers of electronic products can themselves fall under NIS2 from medium size upwards (Annex II point 5), including their manufacturing IT; that is a different legal act from the product-focused CRA.
• AI Act applies in addition as soon as an AI system is built in; the scope of duties depends on the risk level.
• Sector exemptions: exempt are products to which the MDR, the IVDR or Type-Approval Regulation (EU) 2019/2144 apply, aviation products certified under Regulation (EU) 2018/1139, and marine equipment (Article 2(2) to (4)). For suppliers the component itself decides: if it falls under one of these acts, for example as a component for motor vehicles, it is exempt. A general-purpose module you supply to a medical device maker, by contrast, remains a product with digital elements under the CRA.

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 software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies (Annex I Part II(1)), as part of the technical documentation. The Regulation does not prescribe a specific format; the Commission may specify format and elements by implementing act (Article 13(24)). The German BSI guideline TR-03183-2 (v2.1.0) recommends CycloneDX 1.6 or later or SPDX 3.0.1 or later; it is a national recommendation, not a CRA obligation. A PDF with a component list is not machine-readable. A useful 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. The CRA does not create a legal duty for the supplier to hand it over; a structured SBOM exchange does, however, make it easier for customers to provide evidence and thus becomes a selling point.

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: without undue delay and in any event within 24 hours of becoming aware;
• 72 hours - notification: without undue delay and in any event within 72 hours of becoming aware, with the general information available and the corrective or mitigating measures taken;
• Final report: for an actively exploited vulnerability, within 14 days of a corrective or mitigating measure becoming available; for a severe incident, within one month of the 72-hour notification.

The shorthand "24h/72h/14 days" is therefore wrong - the 14 days and the one month apply to different cases. Reporting goes via the single reporting platform (Article 16), through the endpoint of the CSIRT designated as coordinator in the Member State of the main establishment, simultaneously accessible to ENISA - a single submission. 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 (as a rule at least five years, shorter only where the expected period of use is shorter, Article 13(8)).

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

Two dates structure the preparation. First, since 11 September 2026, the reporting and notification duties under Article 14 have applied, the first hard manufacturer duty. Since 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, because the duty already applies, 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), provided routing is not its core function. 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 (early warning, notification, final report) so that the manufacturer can actually fulfil its Art. 14 duty, which has applied since 11 September 2026. This makes the supply a traceable building block in the manufacturer's documentation.

What Blackfort Technology does for you

Blackfort Technology supports EMS, ODM and OEM suppliers along exactly these points - vendor-neutral and without any official mandate:

• Applicability and role analysis: a technical assessment of the constellations in which you are manufacturer, importer or pure contract manufacturer, and what schematically follows (scope per product line), for review by your legal department.
• SBOM setup: building automated SBOM generation, for example in CycloneDX or SPDX, 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: building the documentation under Annex VII so that your buyer can reuse it.

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.