The CRA for network and telecom equipment

01Typical products

• Home and office routers, modems for internet connection
• Managed and unmanaged switches
• Optical network terminals (ONT) and customer premises equipment (CPE)
• Industrial and IoT gateways
• Wireless access points and network interface cards

02Likely CRA class

Annex III Class I lists "routers, modems intended for the connection to the internet, and switches" and "physical and virtual network interfaces". Most products in this industry are therefore Class I. Where firewalling or intrusion detection and prevention is the core function, Class II may apply.

For a Class I product, internal control (Module A) is possible only when harmonised standards, common specifications or a suitable European cybersecurity certificate have been fully applied. Until harmonised standards for the CRA are published, the internal control route is in practice closed; third-party assessment through Module B + C or H is needed. Details: product classes guide.

The class follows the product's core functionality. A gateway acting as a router may be Class I; a device that only collects sensor data may stay in the default class. Try our class check or talk to us for a firm assessment.

03Other rules that apply

• RED and EN 18031: Cybersecurity requirements for network equipment with a radio interface have been mandatory since 1 August 2025. See the EN 18031 and RED guide.
• NIS2 (EU) 2022/2555: Telecom operators and internet service providers are in NIS2 scope and, as part of supply chain security, ask device manufacturers for security evidence.
• CRA Article 14: Reporting of actively exploited vulnerabilities has applied since 11 September 2026. Network devices often appear in exploitation lists (CISA KEV). See the Article 14 guide.

04Challenges specific to this industry

• Embedded Linux firmware: hundreds of open-source components and older kernels mean long vulnerability lists.
• Long product life: devices that stay in the field for years need security updates throughout the support period.
• Operator and ODM chain: products are often designed by an ODM and sold under an operator's brand; who is the manufacturer and who keeps the evidence must be clear.
• Third-party assessment: notified body capacity is limited, so the technical documentation needs to be ready early.

05What the platform does here

• Opens the firmware image and produces the SBOM; prioritises vulnerabilities with CISA KEV and EPSS.
• Imports the SBOM from your ODM and scans it continuously for new vulnerabilities.
• Tracks Article 14 deadlines from the moment of becoming aware and drafts the reports.
• Signed OTA updates with A/B slots and anti-rollback protection.
• Technical documentation and EU declaration of conformity drafts; CSAF 2.0 and OpenVEX output.
• A signed, RFC 3161 timestamped evidence archive kept unaltered for 10 years; the evidence for your notified body in one place.

06Frequently asked questions