EU Cyber Resilience Act Guide for Enterprise Networking Equipment Vendors
Important Class I — network infrastructure products are explicitly listed in Annex III
Enterprise networking equipment vendors — including manufacturers of switches, routers, firewalls, load balancers, and network management appliances — face Important Class I classification under the CRA for virtually all product lines. Network infrastructure products are explicitly named in Annex III as Important Class I by default due to their critical role in enabling network security and connectivity for organisations across the EU.
CRA Scope and Classification for Networking Products
Enterprise switches, routers, firewalls, VPN concentrators, wireless access points, and network management platforms are all within CRA scope as products with digital elements. Annex III of the CRA explicitly identifies network infrastructure equipment as Important Class I, meaning the classification is determined by product category rather than requiring a case-by-case functional analysis.
This means virtually every product in an enterprise networking vendor's portfolio will be Class I, requiring third-party conformity assessment before CE marking. The only exception would be passive network components (patch panels, cable trays) with no embedded software or network management capability. Vendors should audit their entire product catalogue against the Annex III list immediately and plan conformity assessment capacity accordingly. Products sold exclusively for professional/enterprise installation are not exempt; the CRA does not distinguish between consumer and professional market products in terms of classification.
Key Technical Security Obligations for Networking Equipment
For enterprise networking equipment, CRA Annex I Part I requirements translate directly into product security features that sophisticated customers already expect but that the CRA now mandates:
- Secure default configuration: Management interfaces (SSH, HTTPS, SNMP) must be disabled or restricted by default. SNMPv1/v2c community strings using default values are prohibited.
- Cryptographic integrity: Firmware images must be signed and verified before installation. Management protocols must use current cryptographic standards.
- Vulnerability disclosure: Vendors must publish a formal CVD policy and maintain a public disclosure channel.
- SBOM: A comprehensive SBOM covering the network OS, management plane libraries, and all bundled open-source components must be maintained and updated with each firmware release.
- Support lifetime declaration: The expected security support period must be declared at point of sale, including the commitment to provide firmware updates addressing security vulnerabilities.
Vendors already publishing CVEs and issuing security advisories through PSIRT processes are operationally well-positioned; the CRA formalises and makes mandatory what best-practice vendors already do voluntarily.
CVD Policy and Article 13 Requirements
Enterprise networking vendors typically already operate PSIRT programmes and may publish security advisories through Cisco-style Security Advisory frameworks or FIRST-style CVD policies. Article 13 of the CRA formalises and standardises these requirements across all EU manufacturers.
- Clear scope definition covering all products with digital elements
- Submission channels that are accessible without prior registration or NDA
- Defined acknowledgement timeline (best practice: 5 business days)
- Commitment to coordinated disclosure including a reasonable embargo period for researchers
- Publication of advisories that enable customers to assess and remediate risk
CVD Portal can complement an existing PSIRT by providing a standards-compliant intake channel, security.txt generation, and CSAF 2.0 advisory publication — ensuring that enterprise customers who monitor CSAF feeds receive structured machine-readable security data.
Article 14 Incident Reporting Obligations
Networking equipment vendors are at elevated risk of exploitation: enterprise routers and firewalls are high-value targets for nation-state actors and cybercriminal groups who routinely exploit vulnerabilities in network infrastructure to gain persistent access to corporate environments.
- Monitoring threat intelligence sources for exploitation of product vulnerabilities (Shadowserver, CISA KEV, national CSIRTs)
- Maintaining PSIRT escalation procedures that can generate an ENISA notification within hours of confirmed exploitation intelligence
- Coordinating the 24-hour ENISA notification with any concurrent CISA/national CERT advisories where the vulnerability has international significance
The 72-hour detailed report must include the affected product versions, the nature of the vulnerability, available mitigations, and the patch timeline. The 30-day final report must confirm resolution. CVD Portal's Article 14 tool provides timeline tracking and notification draft templates aligned with ENISA's reporting format.
Conformity Assessment for Class I Networking Products
All enterprise networking equipment classified as Important Class I requires third-party conformity assessment. Vendors with large product portfolios — potentially hundreds of SKUs across switching, routing, wireless, and security product lines — face a significant conformity assessment programme management challenge.
- Product family assessment: Notified bodies may assess a representative product from each family where the underlying architecture and security controls are common, with a declaration covering the family.
- Continuous assessment models: Some notified bodies offer ongoing assessment relationships rather than per-release point-in-time assessments.
- Harmonised standards: Once the European Commission publishes harmonised standards for the CRA (expected 2025–2026), products conforming to those standards will have a presumption of conformity that reduces formal assessment burden.
Vendors should begin notified body engagement immediately and prioritise products entering new development cycles, so that CRA conformity can be designed in rather than retrofitted. Build-in vs bolt-on compliance is dramatically cheaper at scale.
CVD Portal handles your CRA Article 13 obligations automatically.
Public CVD submission portal, 48-hour acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Free forever for Enterprise Networking Equipment Vendors.
Start your free portalFrequently asked
Are cloud-managed networking products (e.g., cloud-managed switches) subject to the CRA?+
Yes. Cloud-managed networking products — where configuration, monitoring, and firmware management occur via a vendor-operated cloud platform — involve both a hardware product with digital elements (the switch or access point) and a software component (the cloud management agent embedded in the device). Both are within CRA scope. The hardware device must meet Annex I technical requirements; the cloud management connectivity must be secured and authenticated. The vendor is responsible for both dimensions, including the security of the cloud management channel and the integrity of cloud-pushed firmware updates.
How do we handle zero-day vulnerabilities discovered in our products?+
Under Article 13, you must have a CVD policy that provides a channel for researchers to report zero-days. Under Article 14, once you become aware that a zero-day is being actively exploited — even before a patch exists — you must notify ENISA within 24 hours. The initial notification can confirm the existence of the issue and describe any available mitigations (e.g., disable affected feature, restrict management access) without requiring a complete technical root cause analysis. The 72-hour and 30-day follow-up reports provide the mechanism for communicating patch availability and full resolution.
Does our existing PSIRT programme satisfy Article 13 requirements?+
A mature PSIRT programme provides an excellent foundation for Article 13 compliance but may need specific additions. Key gaps to check: (1) Is the CVD policy publicly accessible without requiring NDA or registration? (2) Does the policy cover all CRA-scoped products explicitly? (3) Is there a `security.txt` file linking to the policy? (4) Does the policy commit to a defined acknowledgement timeline? (5) Are advisories published in machine-readable CSAF 2.0 format? If all five are satisfied, your existing PSIRT is substantially Article 13 compliant with minor documentation additions.
Compliance checklists for your products
Key CRA articles for Enterprise Networking Equipment Vendors
Need a CVD policy template for Enterprise Networking Equipment Vendors?
Download a free CRA-compliant vulnerability disclosure policy and deploy it in minutes.