Who it is for
CRA readiness for network and security products.
Routers, switches, VPNs, firewalls, identity and access management, SIEM and network management products are important products under Annex III. What Class I and Class II change, why these products carry the highest Article 14 exposure, and how to operationalise both.
The direct answer. If you manufacture network infrastructure or security products for the EU market, the Cyber Resilience Act generally treats them as important products under Article 7 and Annex III where the listed function is the product’s core functionality. That changes the conformity route from 11 December 2027 — harmonised standards or third-party assessment for Class I, mandatory third-party assessment for Class II — and it does nothing to soften Article 14: since 11 September 2026 you must report actively exploited vulnerabilities and severe incidents with an early warning within 24 hours of awareness and a notification within 72 hours.
Network and security products are also the category most often found in exploitation catalogues, because they sit at the perimeter, run with high privilege and are reachable from the internet. That makes awareness discipline, a version-accurate component inventory and a rehearsed reporting path more urgent here than for most software. The scope guide covers the manufacturer question in general; the rest of this page is specific to this segment.
Classification
Which network and security products are important products?
Annex III lists the categories; Article 7 attaches the consequences. A product is classified by what it is for, not by every feature it contains.
Annex III Class I covers identity management and privileged access management systems, VPN products, network management systems, security information and event management systems, physical and virtual network interfaces, and routers, modems intended for connection to the internet and switches. Class II covers firewalls and intrusion detection and prevention systems, alongside hypervisors and tamper-resistant microcontrollers and microprocessors. Products with a security function that are not listed remain default products, subject to the same essential requirements with manufacturer self-assessment.
| Category | Class | Conformity route from 11 December 2027 | Category page |
|---|---|---|---|
| Routers, modems, switches | Class I | Harmonised standards / certification scheme, otherwise third-party assessment | Routers, modems and switches under the CRA |
| VPN products | Class I | As above | VPN products under the CRA |
| Network management systems | Class I | As above | Network management systems under the CRA |
| SIEM systems | Class I | As above | SIEM systems under the CRA |
| Identity and access management | Class I | As above | Identity and access management under the CRA |
| Physical and virtual network interfaces | Class I | As above | Network interfaces under the CRA |
| Firewalls, IDS and IPS | Class II | Third-party assessment: Module B + C or Module H, or a certification scheme | Firewalls, IDS and IPS under the CRA |
Class I products that fully apply harmonised standards, common specifications or a European cybersecurity certification scheme may self-assess; otherwise they need third-party assessment. Class II products always need third-party assessment. The conformity assessment guide explains the modules; the Commission may amend the annexes by delegated act, so the stored classification records which rule version produced it.
Exposure
Why do network products carry the highest Article 14 exposure?
Perimeter devices are attacked at scale, patched slowly in the field and often reachable without authentication. The reporting duty has been in force since 11 September 2026.
Edge devices, VPN gateways and firewalls appear regularly in the CISA Known Exploited Vulnerabilities catalogue because a single flaw can be exploited across every deployment reachable from the internet, without user interaction and before administrators notice. For a manufacturer that pattern has a direct regulatory consequence: exploitation of a vulnerability in your product is precisely the event Article 14(1) requires you to report. A KEV listing naming your product or a component you ship is, at minimum, a trigger for an immediate reportability review.
The 24-hour early warning must state that an actively exploited vulnerability exists and whether malicious acts are suspected. The 72-hour notification adds the product, the nature of the vulnerability, an initial assessment and the corrective or mitigating measures taken or available to users. The final report is due no later than 14 days after a corrective or mitigating measure is available — for appliance vendors that usually means a firmware release plus a documented mitigation for customers who cannot patch immediately. A severe incident affecting the product’s security, such as a compromised update server or signing key, follows the same 24-hour and 72-hour stages with a final report within one month after the notification.
What network vendors need in place today:
- An awareness rule covering KEV listings, customer incident reports, honeypot or telemetry observations and researcher disclosures, with the timestamp recorded by a named reviewer.
- Firmware SBOMs per version so the affected component can be traced to every shipped build, including third-party base images and embedded open-source stacks.
- A prepared mitigation playbook — configuration workarounds, exposure reduction, indicators of compromise — because the 72-hour notification asks what users can do before a fix ships.
- A rehearsed submission path to the ENISA single reporting platform with an assigned representative and deputy who have access today.
The Reporting Command Center starts the clocks only after a human confirms reportability, and drill mode lets the team rehearse a KEV-triggered case without touching live metrics.
Essential requirements
What do secure-by-default and secure updates mean for a network product?
Annex I applies from 11 December 2027 to products placed on the market from that date. For appliances the hardest requirements are configuration defaults, update channels and the support period.
Annex I Part I requires products to be made available with a secure-by-default configuration, including the possibility to reset to that state; protection against unauthorised access with appropriate authentication; no known exploitable vulnerabilities at release; minimised attack surfaces including external interfaces; and security updates that can be installed automatically where appropriate, with a clear opt-out. For a router or firewall that translates into no default credentials, management interfaces closed to the WAN unless deliberately opened, signed firmware with rollback protection and an update mechanism that works for devices installed years ago.
Annex I Part II adds the vulnerability-handling process for the whole support period: an SBOM covering at least top-level dependencies, remediation without delay, regular testing, public disclosure of fixed vulnerabilities, a coordinated vulnerability disclosure policy with a contact address, and free, secure distribution of security updates. The support period is at least five years unless the product is expected to be in use for a shorter time — and network equipment is routinely in service far longer, which shapes the period you record and publish. Technical documentation under Annex VII must exist before placing the product on the market and be kept for ten years or the support period, whichever is longer.
Penalties for breaches of the essential requirements or of Articles 13 and 14 reach up to €15 million or 2.5 % of worldwide annual turnover. Market surveillance authorities can also restrict or withdraw products. The disclosure policy guide and the free security.txt generator cover the contact-point requirement.
Operations
How does this map to Vellaci workflows?
Appliance vendors usually have a build system, a PSIRT mailbox and a support portal. Vellaci connects them into one product-level record with deadlines and evidence.
Registry with class and route. Each appliance, firmware line and management product is registered with its Annex III class, the reasoning and approver, its support period and end-of-support alerts, so the conformity route and the customer-facing support commitment are explicit.
Firmware SBOMs matched continuously. Push CycloneDX or SPDX from the build pipeline through the REST API or CLI; SBOM management keeps every document attached to its version and matches components against OSV, GitHub advisories, CISA KEV and EPSS, so a new KEV entry surfaces against the exact builds that contain it.
Reportability review and reporting case. A KEV-flagged finding goes to a named reviewer who confirms or rejects reportability with a rationale and awareness time. Confirmation opens a reporting case with server-computed 24-hour, 72-hour and final-report deadlines, staged forms prefilled from the finding, escalation alerts and a recorded ENISA SRP submission with receipt — see vulnerability management and incident response for the two case types.
Evidence for the notified body. Test reports, configuration baselines, update-signing procedures, the disclosure policy and drill reports are stored as checksummed evidence linked to products and Annex I requirements, with a readiness framework showing gaps per product and a hash-chained audit log that an assessor can follow. Plans and the Vellaci Readiness implementation are on the pricing page.
- Our router includes a firewall. Is it Class I or Class II?
- Classification follows the product’s core functionality. A router, modem or switch is listed in Annex III Class I; a firewall or intrusion detection and prevention system is listed in Class II. A router that happens to include packet filtering is generally classified as a router, while a product marketed and used primarily as a firewall is generally Class II. The determination is yours to record with reasoning and your advisers to confirm; Vellaci stores the decision, the rationale and the approver on the product.
- What does Class II change compared with Class I?
- Both classes are important products under Article 7, and both must meet the same Annex I essential requirements. The difference is the conformity assessment route from 11 December 2027. Class I products can rely on harmonised standards, common specifications or European cybersecurity certification schemes, and otherwise need third-party assessment. Class II products must undergo third-party conformity assessment — EU-type examination followed by conformity to type (Modules B and C) or full quality assurance (Module H) — or a certification scheme at the required assurance level. Self-assessment alone is not available for Class II.
- A CVE in our appliance appears in the CISA KEV catalogue. Is that automatically reportable?
- A KEV listing is a strong exploitation signal, not an automatic determination. Article 14 requires reporting when the manufacturer becomes aware of an actively exploited vulnerability in its product. Your reviewer must confirm that the exploited condition applies to a shipped version in a configuration you support, and record the awareness time. Vellaci flags the KEV listing and EPSS score against your SBOM, asks a named person to confirm or reject reportability with a rationale, and starts the 24-hour clock only after confirmation.
- We ship management software for our appliances separately. Is it a separate product?
- Software placed on the market separately is a product with digital elements in its own right, and network management systems are themselves listed in Annex III Class I. In practice many vendors record the appliance firmware, the management platform and any cloud-side remote data processing as separate products with their own versions, SBOMs and support periods, then link them. Your advisers decide the product boundaries; the registry keeps the relationships explicit.
- Does Vellaci submit our notification to ENISA or certify our firewall?
- No to both. Vellaci is not a notified body, not a CSIRT and not an authority. It prepares submission-ready early warnings, notifications and final reports, tracks the deadlines from a confirmed awareness time, and records the submission your representative makes through the ENISA single reporting platform. Conformity assessment is carried out by your organisation and, where required, by a notified body.
Last reviewed 13 September 2026 · Operational guidance, not legal advice.
Read next
- Guide
CRA product classification: default, important (Class I / II) and critical
How Annex III and Annex IV categories work, the core-functionality test, what changes for conformity assessment under Article 32, edge cases, and how to document a classification decision that will survive scrutiny.
- Guide
CRA conformity assessment: Modules A, B + C and H, notified bodies and CE marking
The conformity assessment procedures of Article 32 and Annex VIII explained by product class, how harmonised standards give a presumption of conformity, when a notified body is needed, and what the declaration of conformity and CE marking require.
- Guide
CRA Article 14 reporting obligations: a practical guide for manufacturers
What must be reported under Article 14 of the Cyber Resilience Act, by whom, to whom and when — the 24-hour early warning, 72-hour notification and final report — and how to operationalise it now that the obligation is in force (since 11 September 2026).
Know your class, your exposure and your evidence gap.
A preliminary scope and gap assessment in about eight minutes, then a 20-minute readiness review with a Vellaci operator if you want one.