Implementing the CRA technically: SBOM, patch process, reporting within 24 hours

What the CRA asks of engineering

Regulation (EU) 2024/2847 applies to manufacturers of products with digital elements placed on the EU market. The essential requirements are set out in Annex I. Part I covers properties of the product itself: no known exploitable vulnerabilities at delivery, secure default configuration, protection of data, logging. Part II covers vulnerability handling across the whole support period: knowing your components, fixing vulnerabilities without delay, distributing updates securely and maintaining a coordinated vulnerability disclosure policy.

Lawyers decide whether and in which category a product is in scope and how conformity assessment works. Almost everything else is engineering. The harmonised standards that will later describe what acceptable evidence looks like are not finished yet. The requirements themselves do not change because of that. This article is not legal advice. The legal assessment stays with your lawyers. It describes what a team can build now, without waiting for the standards.

For context: non-compliance with Annex I or the obligations in Articles 13 and 14 can draw administrative fines under Article 64 of up to EUR 15 million or 2.5 percent of total worldwide annual turnover. The higher amount applies.

Default, important or critical: which class applies?

The CRA has three tiers: the default category, which covers most products, important products under Annex III (split into class I and class II) and critical products under Annex IV. Under Article 7 the deciding factor is the core functionality of the product: only what itself provides one of the listed functions is important. A machine does not become an important product because an operating system or a router is built into it. Commission Implementing Regulation (EU) 2025/2392 of November 2025 describes the categories in more technical detail.

Class I includes, among others, identity and access management, browsers, password managers, VPN functionality, network management, SIEM, boot managers, PKI, network interfaces, operating systems, routers, modems and switches, microprocessors, microcontrollers, ASICs and FPGAs with security-related functions, plus certain smart home products, connected toys and health wearables. Class II: hypervisors and container runtimes, firewalls, intrusion detection and intrusion prevention systems, tamper-resistant microprocessors and microcontrollers. Critical under Annex IV are hardware devices with security boxes, smart meter gateways and other devices for secure cryptographic processing, and smart cards and secure elements.

For machine and plant builders and for most business software this means: PLCs, HMIs, SCADA systems and industrial automation systems are not in the final version of the annexes. The 2022 Commission proposal still listed them as class II. They fall into the default category. It can look different when you place a component with its own security function on the market separately. Examples are a router module, an operating system or a microcontroller with security functions. Industry associations such as the VDMA provide classification aids to their members. The classification itself remains a legal assessment.

Why the class matters technically: it determines the conformity assessment procedure under Article 32. Manufacturers assess default products themselves (internal control, module A). For class I, self-assessment is only possible if harmonised standards, common specifications or a European certification scheme are applied in full. Otherwise a notified body is required (modules B and C, or module H). Class II always needs a notified body or a European scheme at assurance level "substantial" or higher. For critical products the Commission can mandate European certification by delegated act. Until then the class II procedure applies. If you need a notified body, plan early: the bodies are only now being designated and demand rises towards the deadline.

• Write down the core functionality of each product in one sentence and check it against Annex III and IV and the technical descriptions in Implementing Regulation 2025/2392
• Record the result with reasoning in the technical documentation, including a classification as a default product
• For class I, decide early which harmonised standards you will apply once they are published. That decides between self-assessment and a notified body
• Classify separately marketed components with their own security function on their own

Generating the SBOM automatically in the pipeline

Annex I Part II No. 1 requires manufacturers to identify and document the components of the product. That includes a software bill of materials (SBOM) in a commonly used, machine-readable format that covers at least the top-level dependencies. Two formats are established: CycloneDX from the OWASP Foundation and SPDX from the Linux Foundation. Both are read and written by the common tooling. Germany's BSI specifies in Technical Guideline TR-03183 Part 2 which fields an SBOM should contain. It does not replace the regulation, but it is a usable checklist.

An SBOM that someone maintains by hand is outdated after the next release. It therefore belongs in the build pipeline: every release build generates it from the artefact that actually ships, not from the source code alone. Typical tools are Syft or Trivy for container images and file systems, and the CycloneDX plugins for Maven, Gradle, npm, .NET or Python. The SBOM is tied to the version number and commit and archived together with the artefact.

Top-level dependencies are the minimum. For vulnerability assessment, transitive dependencies are what matters, because many of the critical vulnerabilities of recent years sat in libraries no developer had included directly. Generate the full SBOM and decide only when sharing it how much depth the recipient needs.

• Pick a format (CycloneDX or SPDX, as JSON) and document it in the repository
• Generate the SBOM from the artefact on every release build; never maintain it by hand
• Link it to version, commit and build date, and archive it for the support period
• Check the required fields against TR-03183 Part 2, such as creator, timestamp, component name, version, dependencies, licence and hash

Assessing vulnerabilities continuously

An SBOM on its own is just an inventory. It becomes useful when it is checked against vulnerability databases regularly, not only at build time but daily for every supported version in the field. A library that was clean at release can have a critical vulnerability three months later. Scanners such as Trivy or Grype check a stored SBOM without rebuilding the product. Platforms such as Dependency-Track ingest SBOMs and flag new findings.

Every finding needs triage: Is the affected function reachable in the product? Is there a public exploit? Which versions in the field are affected? The outcome is recorded with a justification, including a reasoned not affected. CycloneDX supports the VEX format for this, which attaches the assessment to the SBOM in machine-readable form.

The regulation does not set a number of days for remediation. It requires vulnerabilities to be addressed without delay. So define internal deadlines that match severity, for example assessment within one working day and remediation of critical vulnerabilities within a few days. A documented process with measurable deadlines is the evidence that without delay means more than a statement of intent.

The 24-hour process: detect, assess, report

Article 14 has applied since 11 September 2026. Once a manufacturer becomes aware of an actively exploited vulnerability in the product or a severe security incident, an early warning is due within 24 hours. A notification with an initial assessment follows within 72 hours. For vulnerabilities, a final report is due no later than 14 days after a corrective measure is available. Reports go through the single reporting platform to the competent CSIRT and ENISA.

The 24 hours start when you become aware, not on the next working day. That requires three things. First, an intake channel through which external reports reliably arrive: a security address and a security.txt that are actually monitored. Second, on-call coverage: who decides at the weekend whether a case is reportable, and who submits the report? Third, templates: the early warning needs little content, but the fields must be known in advance so that nobody is researching at two in the morning what belongs in it.

• Name the roles: detect (monitoring, support), assess (engineering), report (one named person plus a deputy)
• Write down the decision criteria: what counts as actively exploited, what counts as a severe incident. Involve legal when in doubt
• Keep templates for early warning, notification and final report in the repository and rehearse them once a year
• Set up and test access to the reporting platform in advance, not during an incident

Patch process: hotfix, signature, delivery

Annex I Part II requires three things: remediate vulnerabilities without delay, provide security updates separately from functionality updates where technically feasible, and distribute updates through a secure mechanism. In engineering terms: you need a release path that completes in hours, not weeks.

A hotfix must not depend on a full manual regression run. That only works if the automated tests are reliable enough to ship a build on a green pipeline. Teams that lack this today will find their biggest lever here. Add maintenance branches per supported version, so the fix for 2.3 does not drag in every change from 3.0.

Updates are signed, and the recipient verifies the signature before installing. Cosign for container images or classic GPG signatures for packages are established. More important than the tool is that private keys never sit in plain text in the pipeline, but in a secret store or an HSM.

Delivery is followed by verification: which installations have received the update? The SBOM of the new version shows that the vulnerable component is gone, and an advisory tells users about the fixed vulnerability, as Annex I Part II Nos. 4 and 8 require. All of this has to keep working across the support period: generally at least five years, with every security update remaining available for at least ten years afterwards.

Evidence: what the documentation can take from the pipeline

The technical documentation under Annex VII describes the product, the risk assessment and how the requirements are met. Much of it can come from the pipeline if the pipeline generates and retains it: SBOM per version, scan results with timestamps, triage decisions, build logs, signatures and provenance data, release notes with security advisories. What matters is that these artefacts stay versioned and retrievable for the support period, not in a pipeline history that is purged after 90 days.

The SBOM itself is part of this documentation. You do not have to publish it. Recital 77 makes that clear. Market surveillance authorities can request it, and customers increasingly ask for it. Decide who hands it out on request and at what depth.

• SBOM and signature per release
• Scan reports and triage log with dates
• Evidence of when which version was delivered to which customers
• Coordinated vulnerability disclosure policy (Annex I Part II No. 5) and a contact point for reports

Sequence for a small team

A team of five developers has no security department. The order of work therefore decides whether the CRA remains a bounded project or becomes a permanent burden. I consider the following sequence, roughly in months, realistic for a small team.

A team that starts in early 2027 still has room before December 2027 for product-specific work and for the harmonised standards once they are available. The CRA self-check on this website gives a first bearing: a few questions on SBOM, vulnerability process, updates and reporting, with an indication of where the largest gaps are.

• Month 1: set up the reporting process, because it already applies. Roles, on-call, templates, contact address, access to the reporting platform.
• Months 1 to 2: SBOM in the pipeline for every product, archived per version.
• Months 2 to 3: scanning against the SBOM, triage rules, internal deadlines. Start clearing the backlog of known findings.
• Months 3 to 6: shorten the release path for hotfixes, signing, maintenance branches, raise test coverage where it blocks a hotfix.
• Months 6 to 9: consolidate documentation from the pipeline, coordinated vulnerability disclosure policy, define and communicate the support period per product.