Cyber Resilience Act: designing compliant connected products

Regulation (EU) 2024/2847, the Cyber Resilience Act, entered into force on 10 December 2024 and becomes fully applicable on 11 December 2027. Part of the obligations is already in effect: from 11 June 2026 the chapter on the notification of conformity assessment bodies applies, and from 11 September 2026 Article 14 applies, with the European system for reporting actively exploited vulnerabilities and severe incidents. These obligations also cover products already placed on the market.

One distinction is needed before going into the substance. The CRA sets requirements and outcomes, often proportionate to risk; it does not prescribe technologies such as secure boot, dm-verity or a specific TLS version. Throughout this article we therefore keep four things apart: legal obligations, the Commission’s interpretations, operational guidance and our own design choices.

1. Scope: which products fall under the CRA

The definition in Article 3 of the CRA is broad: any software or hardware product, and its remote data processing solutions, whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

Three practical consequences.

Indirect connection counts. A data logger with no network interface, which offloads its data over USB to a PC or is configured over Bluetooth from an app, falls within scope. The criterion in the definition is the exchange of data, not presence on the Internet.

The backend follows the product. The regulation includes in the product the remote data processing solutions designed and developed by the manufacturer or under its responsibility, whose absence would prevent the product from performing one of its functions. The guidelines on the application of the CRA adopted by the Commission on 27 July 2026 as document C(2026) 5252, which are not binding but express the interpretation that market surveillance authorities and notified bodies look to, propose a three-condition test: the processing takes place remotely, its absence would prevent the product from performing one of its functions, and the software was designed and developed by the manufacturer or under its responsibility. The same guidelines add that a web application used only through a browser, or a website that merely presents information, is not normally a product with digital elements, and falls within scope only where it qualifies as remote data processing supporting a function of the product.

CRA and NIS2 are complementary and can affect the same organisation on different planes. A SaaS service used only through a browser may remain outside the CRA, unless it constitutes remote data processing of a product; NIS2 instead depends on how the entity and the service are qualified, not on the nature of a product. A manufacturer can therefore be subject to the CRA for its products and to NIS2 for its organisation, with distinct reporting obligations that cannot substitute for one another.

The regulation excludes products covered by equivalent sector legislation: medical devices (Regulations 2017/745 and 2017/746), motor vehicles (Regulation 2019/2144), civil aviation (Regulation 2018/1139), marine equipment (Directive 2014/90/EU), and products developed exclusively for national security, defence or the processing of classified information. The exclusion works per product, not per company.

Free and open-source software supplied outside a commercial activity is out of scope. The CRA introduces the figure of the open-source software steward, with proportionate and lighter obligations. Whoever integrates open-source components into a commercial product remains fully the manufacturer of that product.

Who the manufacturer is (even unknowingly)

The regulation qualifies as manufacturer whoever places the product on the EU market under its own name or trademark. This therefore covers private label (buying a control unit from a third-party supplier, applying one’s own brand and selling it brings the obligation to produce the technical documentation and manage vulnerabilities), the importer or distributor who modifies the product or markets it under its own name, and anyone who carries out a substantial modification on a product already placed on the market.

According to the Commission’s non-binding guidelines, the substantial-modification test looks at the impact on cybersecurity risk, not at the size of the change. A software update that introduces new threat vectors or materially alters the attack scenarios can be substantial even if it touches a few lines of code; an extensive refactoring that leaves the attack surface unchanged may not be. The regulation provides that, where the modification is substantial, the product is considered newly placed on the market and requires a new conformity assessment, at the expense of whoever carries out or commissions the modification.

2. Classification and conformity assessment

Until mid-2026 this section was written by reading Annex III of the CRA. That is no longer enough.

Implementing Regulation (EU) 2025/2392, adopted by the Commission on 28 November 2025 under Article 7(4) of the CRA, published in the Official Journal on 1 December 2025 and in force since 21 December 2025, is binding. Its Annex I contains the technical description of the Class I and Class II categories of Annex III of the CRA, and its Annex II that of the critical product categories of Annex IV, with illustrative, non-exhaustive examples of products whose core functionality falls within each category. It is therefore the reference to use in borderline cases: in 2026 it is no longer enough to compare the product against the bare category name listed in Annex III.

The criterion is the product’s core functionality, and it is through the category that the conformity assessment route is determined. Category and procedure do not coincide, however: for Class I, internal control remains available under the Article 32 conditions set out below; for Class II and for critical products the regime is third-party assessment.

Default category. The vast majority of products. Internal control (module A of Annex VIII): the manufacturer verifies conformity with the essential requirements itself, draws up the technical documentation, issues the EU declaration of conformity and affixes the CE marking. No notified body.

Important products, Class I. Annex III of the CRA, read together with the technical descriptions in Regulation 2025/2392. Among others, they include:

• operating systems, browsers and physical and virtual network interfaces;
• password managers, identity and privileged access management, PKI and certificate-issuing software, boot managers;
• VPNs, SIEMs, network management systems, anti-malware;
• routers, modems for Internet connection and switches;
• microprocessors, microcontrollers, ASICs and FPGAs with security-related functions;
• some categories of home automation, surveillance, voice assistants, connected toys and wearables.

For this class, Article 32 allows internal control when the product conforms to harmonised standards, common specifications or European cybersecurity certification schemes that fully cover the applicable essential requirements. Failing that, a notified body is required (modules B+C or H).

Important products, Class II. Hypervisors and container runtimes, firewalls, IDS/IPS, tamper-resistant microprocessors and microcontrollers. Always third party: EU-type examination plus conformity to type, full quality assurance, or European certification at assurance level at least “substantial”.

Critical products. Annex IV of the CRA: hardware devices with security boxes, smart meter gateways, smart cards and secure elements, as described in Annex II of Regulation 2025/2392. Article 8 allows the Commission to impose mandatory certification under a European scheme by delegated act. In the absence of that obligation, critical products do not fall under internal control: Article 32 still subjects them to a third-party route (B+C, H) or to European certification.

Components and finished products. A component marketed on its own is itself a product with digital elements and is classified in its own right. The component’s class does not, however, transfer to the finished product that integrates it: a data logger that mounts a microcontroller with security-related functions does not thereby become a Class I important product, while that microcontroller is one for its own manufacturer.

In our experience, late commercial requests are the point where classification can change without anyone noticing: a VPN function to expose the site network, or a function to manage the other devices installed in the field. An ancillary function does not automatically move the product to another category, because classification follows core functionality, and a control unit that measures noise and incidentally has a VPN tunnel does not thereby become a VPN product within the meaning of Annex III. Requests of this kind do, however, require the classification to be re-examined, in particular when they change the core functionality or the declared intended purpose, and it is advisable to guard them at the requirements-gathering stage: moving from internal control to the involvement of a notified body has significant effects on project timing and cost.

Penalties

Article 64 sets three bands: up to EUR 15 million or 2.5% of total worldwide annual turnover for non-compliance with the essential requirements of Annex I and the obligations of Articles 13 and 14; up to EUR 10 million or 2% for the other obligations; up to EUR 5 million or 1% for incorrect, incomplete or misleading information supplied to notified bodies and market surveillance authorities.

Paragraph 10 of the same article introduces two derogations to be aware of. The administrative fines of paragraphs 3 to 9 do not apply to manufacturers qualifying as micro or small enterprises for failure to meet the 24-hour deadline in Article 14(2)(a) and 14(4)(a), nor to open-source software stewards for any infringement of the regulation. Recital 120, which guides the reading of the operative provisions without being a stand-alone obligation in itself, indicates that Member States should not impose other pecuniary penalties on these entities.

The scope of the derogation must be read carefully: it concerns the early warning only. The 72-hour notification and the final report remain due, and the other penalty bands remain applicable. In all other cases, moreover, the size of the enterprise is a criterion for calibrating the penalty, not for exemption.

3. From essential requirements to design choices

Annex I of the CRA is in two parts: Part I concerns the properties of the product, Part II vulnerability handling. It opens with a principle that conditions everything else: products must be designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks, and the requirements that follow apply to the extent that they are relevant to the product, with explicit qualifiers (where applicable, where appropriate, where technically feasible).

There is therefore no checklist of controls to be applied mechanically. There is a risk assessment to be carried out, documented and maintained, from which the choices follow. A market surveillance authority opening the file looks for consistency between the risks identified and the countermeasures adopted, not for the presence of a specific technology.

In the table below, the left column gives the requirement as the regulation states it; the right column a possible implementation on an embedded product, which is one design choice among many and not a legal prescription.

On updates it pays to be precise, because the wording often circulates in simplified form. Annex I, Part II, requires that vulnerabilities be addressed without delay, including through security updates; that security updates be distributed without delay and free of charge, with the exception provided for tailor-made products; that, where technically feasible, they be provided separately from functionality updates; that they come with advisories describing the vulnerability and the action required of the user; and that they remain available for at least 10 years from release or for the remainder of the support period, whichever is longer. The mechanism of automatic distribution by default, with an opt-out and notification to the user, is required where applicable, and the regulation acknowledges contexts, typically industrial and professional, in which automatic updating is not reasonable.

Separability between security patches and functionality updates, even if conditioned on technical feasibility, is an architectural constraint that costs dearly if addressed late: it requires repositories, release channels and versioning designed for it from the start.

Part II further requires manufacturers to identify and document components (SBOM), carry out periodic tests and reviews, publish information on fixed vulnerabilities, adopt a coordinated vulnerability disclosure policy, facilitate reporting by third parties and provide a contact address for reports.

4. Components and supply chain

Article 13(5) imposes due diligence on third-party components, including open-source ones, verifying that they do not compromise the security of the product. Article 13(6) adds a less well-known obligation: when a vulnerability is identified in an integrated component, it must be reported to whoever maintains that component, and the fix shared if developed by the manufacturer.

This moves the supplier relationship from the commercial plane to the contractual one. The questions we ask before freezing the BOM:

• is there a coordinated disclosure policy and a documented security contact?
• with what notice and what SLA are security patches released, and under what written commitment?
• until what date is software support for the component guaranteed, as distinct from silicon availability: BSP, modem firmware, protocol stacks?
• does the supplier deliver an SBOM of its component, in machine-readable form, updated at every release?
• are VEX documents or equivalent available to declare non-exposure to CVEs that show up in scans but are not reachable in the context of use?
• how will the supplier behave under Article 14 when the vulnerability is in its component inside our product?

The most frequent knot on embedded products is the mismatch between the declared support period and the life cycle of the suppliers’ software. A ten-year support period on a product that mounts a module whose BSP is based on a kernel whose LTS ends in four years is a commitment that the initial configuration cannot sustain. There are three viable routes, not mutually exclusive: budget for the migration, choose platforms with contractually declared longevity programmes, or isolate the updatable part so that it can be replaced without redesigning the product. The choice belongs to the architecture phase.

The CRA requires the support period to be determined in relation to the reasonably expected time of use of the product, with a minimum of five years unless the expected useful life is shorter, and to be communicated to the user clearly and comprehensibly before purchase. The Commission’s guidelines insist on this point, correcting the reading whereby five years would be a standard value: they are a floor, not a default. For a measuring instrument installed in the field, the expected life we encounter rarely falls below ten years.

5. Harmonised standards: where things stand

The distinction that matters is between what exists as a draft and what is cited in the Official Journal: only citation triggers the presumption of conformity under Article 27.

With standardisation request M/606, adopted by Implementing Decision C(2025) 618 of 3 February 2025 and accepted by CEN, CENELEC and ETSI in April 2025, 41 harmonised standards were commissioned, structured as type A standards (horizontal principles), type B (specific horizontal topics, first of all vulnerability handling) and type C (product-specific, mapped onto Annexes III and IV).

The main families:

• EN 40000 (CEN-CLC/JTC 13 WG 9), horizontal layer: vocabulary, principles, generic security controls, vulnerability handling. It builds on the work of the EN 18031 series developed for the RED directive.
• EN 50770, vertical OT profiles: firewalls and IDS/IPS, network management systems, VPN products, routers and switches, largely based on the IEC 62443 framework.
• EN 304 6xx (ETSI TC CYBER, EUSR group), software categories and consumer connected products. These are the most advanced, and the drafts are public.
• EN 5076x and the work of CEN/TC 224 for semiconductors, secure elements and identity management.

Status verified on 17 September 2026 As of this update, no CRA harmonised standard is cited in the Official Journal of the European Union, and the presumption of conformity is therefore not available for any product category.

The original deadlines have slipped; the vulnerability-handling part, prEN 40000-1-3, is indicated as the closest to citation, while the parts on principles and generic controls follow a longer trajectory. This is the information that ages fastest in this article, and it must be checked at the source before basing a decision on it.

The existing standards the drafts build on — IEC 62443-4-1 and -4-2, ETSI EN 303 645, the EN 18031 series — confer no presumption of conformity with the CRA in their currently published form.

The presumption remains an evidentiary convenience, in any case, not the only road: internal control can be pursued by demonstrating conformity with the essential requirements by one’s own means, and Article 27 also provides for common specifications that the Commission may adopt by implementing act if the standards do not arrive on time. Our choice, in the meantime, is to design against IEC 62443-4-1 for the secure development process and 62443-4-2 for component technical requirements, adding ETSI EN 303 645 on consumer connected products, ISO/IEC 29147 and 30111 for vulnerability disclosure and handling, and BSI TR-03183-2 for the SBOM. The last is a technical guideline of the German BSI, hence voluntary and national in origin, and remains the most detailed technical interpretation of the SBOM available pending the implementing act provided for in Article 13(24). The body of evidence produced this way is largely reusable once the harmonised standards are cited, but it does not amount to the presumption of conformity.

6. The technical documentation

Annex VII of the CRA lists the content of the technical documentation. Summarising it is useful provided one says that it is a summary and not a complete list: when drafting, the text of the annex must be read. The main contents:

• general description of the product, intended purpose, software and hardware versions, photographs or illustrations of external features, marking and internal layout;
• the information for the user under Annex II;
• description of design, development and production, including software architecture, interfaces and information on production and monitoring processes;
• the cybersecurity risk assessment against which the product is designed;
• justification for the determination of the support period;
• list of harmonised standards, common specifications or European certification schemes applied in full or in part, and description of the solutions adopted where they are not applied;
• reports of the tests carried out, including validation tests;
• description of the solutions adopted for secure distribution of updates;
• SBOM in a commonly used, machine-readable format, covering at least the top-level dependencies;
• coordinated vulnerability disclosure policy and contact address for reports;
• description of the vulnerability handling processes for the support period;
• copy of the EU declaration of conformity.

The documentation must be kept for at least 10 years after placing on the market, or for the support period if longer. For a series in production until 2035 with ten years of support, that means keeping, and being able to retrieve, the exact SBOM version of every build until the mid-2040s. It is a documentation-infrastructure requirement: versioned archiving, protected integrity, the ability to tie a serial number to a build.

Annex II defines the information to be provided to the user: identification and contact details of the manufacturer, single point of contact for vulnerability reports, intended purpose, cybersecurity functionality, end date of the support period expressed comprehensibly and available before purchase, how to obtain updates, instructions for secure decommissioning. The end-of-support date therefore also reaches the pre-contractual material, not just the manual.

The SBOM does not have to be made public; recital 77 is explicit on this. It must, however, be handed to the market surveillance authority on reasoned request, which presupposes being able to produce it in the correct version within a reasonable time.

7. Article 14: vulnerabilities and incidents to report

From 11 September 2026 manufacturers must report, through the single platform provided for in Article 16 and operated by ENISA, two categories of event.

Actively exploited vulnerabilities. Vulnerabilities the manufacturer becomes aware of, for which there is reliable evidence of ongoing exploitation by a malicious actor in one of its products with digital elements. The discovery or publication of a CVE, on its own, does not trigger this obligation.

Severe incidents having an impact on the security of the product. The definition has two branches: events that negatively affect the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, and events that have led to the introduction or execution of malicious code in the product or in the user’s networks and information systems. The second branch is often left out of summaries, and it changes the perimeter of what has to be assessed.

Article 14(8) adds a distinct and often overlooked obligation: after becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer informs the affected users of the product and, where appropriate, all users, about the event and the corrective or mitigating measures they can take. It is an obligation towards the market, independent of the coordinated disclosure policy and of the report to the authority.

On how the platform works in practice, the ENISA FAQ indicate that the report reaches the competent CSIRT designated as coordinator and is as a rule also made available to ENISA; that a single submission suffices, without replicating it to the authorities of the various Member States concerned; that, if the platform is unavailable, the report is to be submitted once it is restored, and in case of immediate need the CSIRT can be contacted directly, without this replacing the subsequent submission. Again according to the FAQ, the manufacturer’s representative must have a personal EU Login account with two-factor authentication, the association between person and manufacturer is validated by the CSIRT and a pending validation does not block the initial submission, and no API is provided in the initial phase: the process must therefore not be built on an automated integration that does not exist. These are operational indications subject to frequent updates, to be re-checked before freezing an internal procedure.

The 24-hour constraint is, before it is technical, an organisational problem. Twenty-four hours include the night, the weekend and holidays. In our practice we put in place:

1. a public, monitored intake channel: a security@ mailbox forwarded to several people, and a /.well-known/security.txt file per RFC 9116, which is the standard’s canonical path;
2. a written criterion for establishing when “awareness” of the event arises, which is the moment the clock starts, with the time and the reasoning recorded;
3. an on-call person with delegated authority to decide, and a deputy;
4. EU Login accounts already created and tested;
5. pre-filled templates for the three stages, with the product-dependent fields already populated;
6. a tabletop exercise at least once a year, with a stopwatch.

Downstream coordination also has to be considered: customers subject to NIS2 have their own reporting obligations and will ask for information within timeframes compatible with their deadlines. Notification clauses in supply contracts must be aligned with these windows.

The Commission’s guidelines have made it explicit that the reporting obligation applies to all products in scope, including those placed on the market before the regulation becomes fully applicable, and that it continues after the end of support. The installed base is not excluded. Being a non-binding interpretation, this reading is authoritative but not definitive.

8. The issues that surface in real projects

Legacy. Article 69 subjects to the design requirements the products placed on the market from 11 December 2027, and earlier ones only if they undergo substantial modifications, but extends Article 14 to the base already placed on the market as well. The resulting obligation is to report within the deadlines; the regulation does not require holding a complete field inventory within 24 hours. It remains true that without an inventory linking serial number, customer, firmware version and the matching SBOM, the 72-hour notification is hard to fill in with reliable data, and the estimate of exposed units becomes a guess. We treat it as a priority operational objective, not as a paperwork exercise.

Substantial modification as silent drift. The impact-on-risk criterion implies that a pre-2027 product may cross the threshold after a series of functionality updates, without any single release having raised an alarm. We introduce an assessment gate at every major release, with a documented outcome even when the outcome is “not substantial”: the value lies in the traceability of the decision, not in its content.

Silicon that cannot be updated. Microcontrollers without secure boot, radio modules with closed, unpatched stacks, components reaching end of life before the end of the support period. These are decisions taken years ago that determine whether the product can be brought into line or must be redesigned, and there are no documentary shortcuts here. The residual risk, when the component cannot be replaced in the short term, must be declared in the assessment and compensated at system level, in the awareness that perimeter compensation does not remove the component’s vulnerability.

Open source inside the product. Due diligence on open-source components cannot be transferred to a supplier. Selection criteria (active project, published security policy, historical response times), an internal mirror of dependencies, and the ability to produce the patch when upstream does not. The last point is the one small organisations underestimate: it requires competence on third-party code, not only on one’s own.

CVE noise. A typical embedded image generates a number of hits far greater than the vulnerabilities that matter in the context of use. Without a structured VEX process, triage saturates the team. Triage must be documented: the authority may ask why a known CVE was not fixed, and the answer “not reachable in our context” must be supported with evidence, not asserted.

Fixed cost for SMEs. Processes, tooling, documentation and 24-hour coverage have a cost that is largely independent of volumes, and therefore weigh on whoever places a few thousand units on the market. The workable lever is a single compliance framework reusable across the whole range, instead of a hand-crafted file per product.

Notified body capacity. For Class II and critical products the number of notified bodies under the CRA is still limited, and the queue will lengthen as December 2027 approaches. Contact should be made well ahead of the launch date.

9. Worked example: a noise monitoring station

The technical choices in this section are ours: one possible configuration, not the only compliant one. Where a choice follows from an obligation, the source is indicated.

The product. A permanent noise monitoring station for outdoor installation. Measurement chain conforming to IEC 61672-1 class 1 (1/2” microphone, preamplifier, conditioning, dedicated ADC, level computation on a dedicated MCU). Connected part on an embedded Linux module: local web interface for configuration, LTE modem for backhaul, Wi-Fi and BLE for commissioning, MQTT client over TLS towards a cloud platform developed by the manufacturer, over-the-air firmware updates, local storage of levels, spectra and event audio clips.

Declared assumption. We assume a use in which the station is subject to a legal metrology regime, for example in monitoring that serves as a check for the purposes of enforcement measures. The notion of legally relevant firmware does not derive from IEC 61672-1, which defines performance requirements for sound level meters and the related tests, but from the applicable metrology regime and the intended use. In a purely informational or internal-monitoring use the assumption falls, and with it part of the architectural constraints of section 9.3.

9.1 Scope and classification

The station is a product with digital elements. The cloud platform is developed by the manufacturer and without it the product loses the remote transmission and archiving function: it therefore qualifies as a remote data processing solution, and enters the scope and the technical documentation.

The classification check is made against Annex III of the CRA read together with the technical descriptions in Annex I of Implementing Regulation 2025/2392, applying the core-functionality criterion. The product’s core functionality is the acquisition and measurement of acoustic quantities; it is not network management, not traffic routing, not filtering, and it does not fall within the descriptions of the Class I or Class II categories. The fact that the SoC integrates a secure element does not move the finished product, for the reasons given in section 2.

Outcome: default category, internal control. The check must be recorded in the file with the reference to the implementing act and the reasoning, not left implicit.

9.2 Risk assessment, with residual risk

The table gives, for each surface, the countermeasure and what the countermeasure does not solve. The right-hand column is the one the risk assessment has to sustain.

The last row is what distinguishes this product from generic IoT: the two-processor architecture serves at the same time to preserve the integrity of the legally relevant part and to separate the trust domains.

9.3 Architectural choices

• Linux SoM with a contractually declared longevity programme and a BSP on an LTS kernel consistent with the support period.
• Secure boot: public key in OTP, signed bootloader, signed kernel and device tree, verified read-only rootfs, separate encrypted data partition.
• Secure element for the device private key and the mTLS certificate, with on-board key generation during production: the private key never exists outside the chip. The cost is a constraint on production logistics and on repairability in service, which has to be accepted knowingly.
• Minimal image: no network shell, no unnecessary service, diagnostics service that can be enabled only locally and for a limited time.
• Security logs on a dedicated partition, with rotation, exportable, and the user can disable them with notice.

9.4 OTA: A/B and anti-rollback together

The two mechanisms are compatible only if one defines when the monotonic counter is advanced. If it is incremented when the new image is written, rolling back to the previous version, which is the very reason for the A/B scheme, is forbidden by the anti-rollback.

The strategy we adopt is two-phase: install and boot the new image with the previous slot still valid and the counter unchanged; run an application-level health check after boot on a defined set of conditions (measurement chain operational, connectivity, configuration integrity); only when the health check passes, commit, which marks the slot as valid and advances the anti-rollback counter. The counter is advanced only for security fixes that are meant to be irreversible, not at every release, because each increment permanently closes the possibility of going back.

9.5 Trust model of the local UI

“HTTPS with a per-device certificate” does not by itself solve browser trust, and it is a point where many products stop halfway. The realistic options:

• certificate issued by the manufacturer’s private CA, with the CA to be installed on the technician’s machine: works in managed contexts, impractical for the occasional user;
• public certificate on a resolvable DNS name, with renewal that depends on connectivity: introduces an external dependency on an interface that must also work at an isolated field site;
• commissioning app that pins the device certificate, obtained during an authenticated onboarding over BLE or via a printed code: moves the trust to the app and requires a secure provisioning channel;
• administrative access only via the app, with the web UI limited to read-only local consultation.

No option dominates. The choice depends on who installs, on how often local access happens and on whether connectivity is available during commissioning, and it must be documented in the risk assessment together with the residual risk it carries.

9.6 SBOM and pipeline

The Yocto build natively generates the SBOM in SPDX format through the create-spdx class documented in OpenEmbedded. Obtaining CycloneDX as well requires a dedicated layer or a downstream conversion, which must be documented in the build process. The regulation requires a commonly used, machine-readable format covering at least the top-level dependencies; the choice between SPDX and CycloneDX is the manufacturer’s.

The artefact is signed and archived with the image and the build hash, indexed by version.

Before release: correlation of the SBOM with vulnerability databases, a gate that blocks the release in the presence of known exploitable vulnerabilities, production of the VEX document for CVEs that are present but not reachable, with a technical justification for each.

In operation: periodic rescanning of the SBOMs of all versions in the field, not only the latest. The cadence we adopt is daily, and it is our own process choice: the CRA does not prescribe a scanning frequency. The reason is not that a CVE starts the Article 14 clock, which instead runs from awareness of active exploitation, but that without knowing quickly which versions contain a vulnerable component one can neither fix without delay, as the regulation requires, nor respond reliably if active exploitation emerges.

9.7 The support period, turned into a date

Estimated expected useful life: 10-12 years. Company policy: support for 10 years from the placing on the market of the last unit of the series.

That formula, however, cannot be communicated to the user: the CRA requires an end-of-support date expressed comprehensibly and available before purchase, and whoever buys the first unit cannot know when the last one will leave the price list. The operational translation is to declare a firm calendar date from the first placing on the market, computed on the planned end of production, with a public commitment to extend it if production continues beyond. A date that grows over time is admissible; a date that shrinks is not, and this has to be kept in mind when choosing the initial value.

Consequences to be budgeted at design stage:

• a planned maintenance cycle, six-monthly in our case, with the related test and regression activities on the measurement chain;
• regardless of the planned cycle, security fixes must be distributed without delay, as the regulation requires: an exploitable vulnerability does not wait for the next maintenance release. Two distinct channels are therefore needed, one scheduled and one out of cycle, with reduced but defined test procedures for the second;
• at least one kernel/BSP migration over the decade, planned and funded;
• contractual coverage from the SoM and LTE module suppliers checked against the same deadline;
• retention of SBOM and technical documentation under the terms of Annex VII;
• declaration of the end-of-support date in the manual, in the product datasheet and in the pre-contractual material.

9.8 Reporting, in practice

Scenario. Tuesday, 22:40: the LTE module supplier publishes an advisory on a vulnerability in the TLS stack of its firmware. Wednesday morning a customer reports anomalous traffic towards an external host from two stations on its site, with evidence consistent with exploitation of that vulnerability.

• T0. The clock runs from awareness of active exploitation, hence from the moment the team has reliable evidence, not from the publication of the supplier’s advisory. The criterion is written in the internal procedure and the determination is recorded with time and reasoning, because it is the datum against which compliance with the deadlines will later be measured.
• T0 + 24h, early warning. Identification of manufacturer and product, nature of the vulnerability, exploitation status, Member States potentially concerned.
• T0 + 72h, notification. Technical description, affected firmware versions, estimate of exposed units, mitigation measures communicated to customers, status of the exchange with the supplier.
• In parallel. Information to the affected users and, where appropriate, to all users, as Article 14(8) requires, on the corrective or mitigating measures available. Report to the module supplier under Article 13(6). Communication to customers subject to NIS2 within the timeframes and in the format that allow them to meet their own obligations.
• T_patch + 14 days, final report. Vulnerability and severity, impact, root cause, corrective measure distributed, coverage of the update across the installed base.

The critical point of the scenario is organisational: having field data within a few hours, and having a person authorised to submit the report without waiting for a collective decision. Both conditions are built beforehand.

10. Adaptation plan up to December 2027

Already due. Operational Article 14 reporting procedure and minimum inventory of the installed base, on the terms of section 7.

Within three months. Census of the range with determination of scope and category for each product, recorded against Implementing Regulation 2025/2392. Gap analysis of the technical documentation against Annex VII, focused on software architecture, vulnerability handling and risk assessment. Publication of the coordinated disclosure policy and the point of contact.

Within six months. Automatic SBOM generation in the pipeline for all products in production, correlation with vulnerability sources, VEX process. Contractual review with critical suppliers on patch SLAs, end of software support and notification obligations.

Within twelve months. Determination and declaration of the support period per product, with the related maintenance budget and the two release channels. Alignment of products under development with the Annex I requirements, with tests and the related reports. Contact with a notified body for products classified as Class II important or critical.

By the deadline. Complete technical documentation, EU declarations of conformity, CE marking, user information conforming to Annex II, vulnerability handling processes in operation and verifiable.

The CRA moves part of compliance upstream, into architecture decisions, component selection and maintenance processes. For connected products, tackling it once the design is finished often means finding out too late that some requirements can no longer be solved with documentation alone.

References

Binding sources

• Regulation (EU) 2024/2847 of 23 October 2024 (Cyber Resilience Act), consolidated text on EUR-Lex
• Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025, technical description of the categories of important and critical products
• Implementing Decision C(2025) 618 final, standardisation request M/606

Commission interpretation, non-binding

• Guidelines on the application of the CRA, C(2026) 5252 final of 27 July 2026, with annex and 67 examples
• Commission FAQ on the implementation of the CRA

Operational material, subject to updates

• ENISA, FAQ and factsheet on the Single Reporting Platform

Standards and technical guidelines, voluntary

• IEC 62443-4-1 and IEC 62443-4-2
• ETSI EN 303 645
• ISO/IEC 29147 and ISO/IEC 30111
• BSI TR-03183, parts 1, 2 and 3
• RFC 9116, format and location of the security.txt file
• OpenEmbedded/Yocto Project, documentation of the create-spdx class

Technical and informational content, current as of September 2026. It does not constitute legal advice or a conformity opinion. The status of harmonised standards, Commission guidelines and ENISA operational material evolves rapidly: check the primary sources before taking compliance decisions.