CRA for network & security hardware

When your product is the defensive line

Firewalls, VPN gateways, IDS/IPS sensors, SIEM appliances, PKI systems: if you build these products, you sell trust. Customers place them at the edge of their networks, give them visibility over all traffic and make them the central control point. That is precisely why the Cyber Resilience Act (Regulation (EU) 2024/2847) treats this device category differently from an ordinary connected coffee machine. Security products are deliberately classified higher in the CRA because their failure can undermine the protection of entire infrastructures.

For makers and importers in this sector, applicability is quickly settled: a device is generally in scope if it is made available on the EU market in the course of a commercial activity and its intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network (Article 2(1)) - schematically the case for network devices (this is a general classification, not case-specific legal advice). The real pain lies elsewhere: in the depth of proof. A security appliance today consists largely of open-source components, integrates crypto libraries, signature feeds and a Linux base - and must be able to respond to zero-days for years while being the target of motivated attackers itself.

On top of that: firewalls, IDS/IPS, VPN products and routers are explicitly listed in the "important" categories of Annex III. That shifts the question from "do we meet the requirements?" to "who confirms it - we ourselves or a notified body?". Settle this question early, because assessing a class II product involves a notified body and needs corresponding lead time.

Typical PDE products and their likely Annex III class

The CRA names numerous products in this sector explicitly in Annex III; the technical descriptions of the important and critical categories are detailed by Implementing Regulation (EU) 2025/2392. What counts for the classification is the product's core function (Article 7(1)). The following classification is schematic and does not replace a product-specific assessment:

The practical difference is significant: with class I you can run the procedure internally (Module A) - but only if you fully apply harmonised standards, common specifications or a European cybersecurity certification scheme (assurance level at least “substantial”). If none of these is available or you apply it only partially, class I also leads through a notified body (Module B+C or H). For class II, the route runs through a notified body (Module B+C or H) or a European scheme of at least “substantial”. Annex IV products need a European scheme where a delegated act requires one; otherwise the same applies as for class II.

Sector standards and delineation from adjacent regimes

The substantive content for the CRA evidence in this sector comes from established sector standards. IEC 62443 structures security for connected automation and control environments and is the natural reference frame for appliances touching OT; product-level Common Criteria evaluations and hardening evidence substantiate concrete security functions. The national BSI guideline TR-03183 (in particular TR-03183-2, v2.1.0) gives recommendations on SBOM format and vulnerability management. These standards do not replace the CRA, they fill it out. Harmonised standards for the CRA have been requested (M/606) but were not yet published in the Official Journal on 9 October 2026.

The delineation from neighbouring regimes matters so you neither duplicate work nor aim at the wrong target:

• RED Delegated Regulation 2022/30 (radio equipment): for radio-capable appliances that can communicate over the internet (Wi-Fi routers, cellular gateways) there is overlap in cybersecurity requirements; the CRA is the cross-product roof, the RED-DA the radio-specific detail until it is repealed with effect from 11 Dec 2027.
• NIS2 governs the cybersecurity of entities, the CRA that of products. As a manufacturer of electronic products, your company can itself fall under NIS2 from medium size upwards (Annex II point 5); that concerns your organisation, not the conformity of your products. Separate legal acts, do not equate them.
• DORA concerns financial-sector resilience; relevant only if your customers sit there, not for product conformity itself.
• AI Act applies in addition as soon as an AI system is built in, such as AI-based anomaly detection; the scope of duties depends on the risk level.
• Sectoral 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 classic network security hardware this does not apply in principle.

SBOM and supply-chain reality of this sector

A security appliance contains a large amount of third-party code. Typical are a Linux kernel and userland, OpenSSL or other TLS/crypto libraries, rule and signature engines (Snort/Suricata-like components), web UI frameworks, logging stacks and possibly an embedded database. Each of these components has its own lifecycle - and that is where the risk sits: end-of-life libraries, overlooked transitive dependencies and OSS projects without an active maintainer are the typical entry points.

A machine-readable SBOM is the prerequisite for responding to the next zero-day in hours rather than weeks. 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 (no general obligation to publish). 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. In practice the following works well:

• A machine-processable format such as CycloneDX or SPDX; a PDF list is not machine-readable.
• At least the top-level dependencies with unambiguous component identity (name, version, supplier, ideally hashes and identifiers such as CPE/PURL).
• Currency across the support period: the SBOM should match the respective firmware/software state so a CVE hit can be mapped to the affected release immediately.

The support period follows the expected period of use: as a rule at least five years, shorter only where the expected period of use is shorter (Article 13(8)) - for security hardware that stays long in the field, correspondingly longer. Across this entire period vulnerability handling must be evidenced, and the SBOM is the tool for it.

Reportability and PSIRT: the Art. 14 cascade correctly

Since 11 September 2026, the reporting obligation under Article 14 has applied. For security hardware it is particularly sharp, because actively exploited vulnerabilities in a firewall or VPN gateway are immediately safety-critical. The deadline chain reads - and the shortening to "24h/72h/14 days" is wrong here:

• 24 hours - early warning: without undue delay and in any event within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident.
• 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.
• 14 days - final report for an actively exploited vulnerability, counted from the availability of a corrective or mitigating measure.
• 1 month - final report for a severe incident, counted from the 72-hour notification.

Reporting is done via the single reporting platform (Article 16), through the endpoint of the CSIRT designated as coordinator in the Member State of your main establishment, simultaneously accessible to ENISA - a single submission. Manufacturers should set up and maintain their internal PSIRT processes independently of the tooling. For this sector, concretely: a named PSIRT contact, a published Coordinated Vulnerability Disclosure (CVD) policy, defined escalation and release paths and rehearsed deadline tracks.

Which deadline counts first: 2026 before 2027

Two dates structure the preparation, and they are easily confused:

• 11 September 2026 - reporting obligations (Art. 14). The first hard manufacturer obligation. Since then you must be able to report actively exploited vulnerabilities and severe incidents on time. This also applies to products already on the market.
• 11 December 2027 - full product requirements. From here all Annex I requirements, the completed conformity assessment, CE marking and EU declaration of conformity apply.

For a maker of network security hardware this means: the PSIRT/CVD process is the first construction site, because it must already be live. In parallel runs the longer build-up of threat modelling, technical documentation and - for class II - the scheduling with a notified body; plan the notified body early. Technical documentation, by the way, must be retained for at least ten years after placing on the market or for the longer support period (Article 13(13)).

A worked example

A mid-sized manufacturer places a next-generation firewall with integrated IDS/IPS and an optional VPN module on the market. Schematically the firewall falls into Annex III, class II - so the route runs via Module B+C, Module H or a European scheme of at least “substantial”; with no scheme available, the notified body is the standard route. The VPN module would be class I on its own, but as a built-in component it does not change the firewall's classification.

The firmware is based on a hardened Linux, OpenSSL, a Suricata-like detection engine and a web management UI. The manufacturer generates a CycloneDX 1.6 SBOM in the build and links it to every release. When an actively exploited vulnerability becomes known in a TLS library, the PSIRT recognises via the SBOM within minutes which firmware states are affected, submits the early warning via the single reporting platform without undue delay and within 24 hours at the latest, notifies within 72 hours at the latest with the information available including a workaround, and - as soon as the patch is available - delivers the final report within 14 days. For market access it relies on IEC 62443 and Common Criteria evidence, runs threat modelling as a documented Annex I risk assessment and schedules the notified body early enough before 11 December 2027. We also use SBOM generation in the build and matching of the bills of materials against vulnerability data in our own build pipelines.

What Blackfort does for you

Blackfort Technology supports makers and importers of network and security hardware along exactly these points - pragmatic, technically grounded and without generic checklists:

• Applicability and scope analysis: a technical assessment of which of your products are PDE, which schematically fall into class I, II or Annex IV and which conformity path follows (Module A vs. notified body).
• SBOM setup: generating machine-readable SBOMs, for example in CycloneDX or SPDX, in the build, linking to releases and continuous maintenance across the support period.
• PSIRT and CVD: building the reporting process with the correct Art. 14 deadlines, CVD policy, escalation paths and connection to the single reporting platform.
• Risk assessment and threat modelling: documented Annex I risk assessment as the methodical basis of the technical documentation.
• Technical documentation: building the documentation under Annex VII up to the EU declaration of conformity, retained for at least ten years or the longer support period (Article 13(13)), and preparing the conformity assessment with the notified body.

A good starting point is the applicability check, which classifies your products schematically (not legal advice). You can go deeper with our overview of the Cyber Resilience Act and the notes for small and medium-sized manufacturers. If you want to walk through concretely where your product stands, reach out via contact.

Note: this presentation serves technical orientation and does not replace case-specific legal advice.