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 does not compromise one device — it undermines the protection of entire infrastructures.

For makers and importers in this sector, applicability is rarely the real question — a product with digital elements that has a network interface and is placed on the EU market would schematically fall within scope (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: a large share of these products does not land in the self-assessment majority, but 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?". Those who clarify this switch late regularly underestimate the lead time a class II conformity assessment via a notified body requires.

Typical PDE products and their likely Annex III class

The CRA names many 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. 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 the relevant harmonised standards. If these are not yet available or you apply them only partially, class I also leads through a notified body. For class II, the notified body is the rule; for Annex IV products it is always required — sometimes with a mandatory European certification scheme.

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 BSI guideline TR-03183 (in particular TR-03183-2, v2.1.0) details SBOM format and vulnerability management. These standards do not replace the CRA, they fill it out — and harmonised CRA standards will consolidate this base over time.

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 (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.
• NIS2 does not address you as a manufacturer but the operators of essential/important entities that deploy your devices. Separate legal act — do not equate it with the CRA.
• DORA concerns financial-sector resilience; relevant only if your customers sit there, not for product conformity itself.
• AI Act applies if you market AI-based anomaly detection as a standalone AI system — an additional, not replacing, framework.
• Sectoral exemptions: medical devices (MDR/IVDR), motor-vehicle type approval, civil aviation and marine equipment are exempt from the CRA. For classic network security hardware this generally does not apply.

SBOM and supply-chain reality of this sector

Few product categories carry as much third-party code as a security appliance. 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 often 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 it as part of the technical documentation (no general obligation to publish). Concretely, "machine-readable" under BSI TR-03183-2 means:

• Format CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1 — not a PDF list, but a machine-processable document.
• 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 must match the respective firmware/software state so a CVE hit can be mapped to the affected release immediately.

The support period is based on the expected product lifetime; a guideline value is at least five years — for security hardware that stays long in the field, often considerably longer. Across this entire period the SBOM must be maintained and vulnerability handling must be evidenced.

Reportability and PSIRT: the Art. 14 cascade correctly

From 11 September 2026, the reporting obligation under Article 14 applies. 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 common shortening to "24h/72h/14 days" is wrong here:

• 24 hours — early warning from becoming aware of an actively exploited vulnerability or a severe security incident.
• 72 hours — full notification including available corrective or mitigating measures.
• 14 days — final report for an actively exploited vulnerability, counted from the availability of a corrective measure.
• 1 month — final report for a severe security incident, counted from the 72-hour notification.

Reporting is done via the ENISA Single Reporting Platform (SRP) as a single submission to the responsible CSIRT of the main establishment and ENISA. The platform is to be provided by the date of application; in mid-2026 it is not yet fully operational, which is why manufacturers should set up their internal PSIRT processes now rather than wait for 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 — otherwise the 24-hour mark breaks at the first real incident.

Which deadline counts first: 2026 before 2027

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

• 11 September 2026 — reporting obligations (Art. 14). The first hard manufacturer obligation. From here 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 goes live first. In parallel runs the longer build-up of threat modelling, technical documentation and — for class II — the scheduling with a notified body whose capacity is limited. Technical documentation, by the way, must be retained for ten years from placing on the market.

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 — making the notified body the standard route. The VPN module would be class I on its own but is subsumed in the higher-level class II product.

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, issues the early warning via the SRP within 24 hours, delivers the full notification with a workaround after 72 hours and — as soon as the patch is available — 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. This exact chain — SBOM, PSIRT, evidenced vulnerability handling — is what Blackfort runs for its own products (dogfooding) before recommending it.

What Blackfort does for you

Blackfort Technology UG (haftungsbeschränkt) supports makers and importers of network and security hardware along exactly these points — pragmatic, technically grounded and without generic checklists:

• Applicability and scope analysis: 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 (CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1) 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 ENISA SRP logic.
• Risk assessment and threat modelling: documented Annex I risk assessment as the methodical basis of the technical documentation.
• Technical documentation: building the evidence structure including ten-year retention and preparation for the notified-body assessment.

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.