CRA Class I Compliance Guide: Routers, Modems and Switches

Classification basis

The CRA treats routers, internet modems and switches as Important Class I products, which is not the same as Class II firewall status. Extra security features do not move a router into Class II as long as routing and internet connectivity remain its core marketed function.

The product is not Critical merely because it sits at the network edge. The Critical list is narrower and does not include consumer routers or ISP CPE as a whole.

What counts as the router product?

A router, modem or switch product can include more than the plastic box:

• bootloader, operating system, kernel, wireless drivers, WAN stack and LAN services;
• modem, ONT, Ethernet switch silicon, management VLAN behaviour and PoE control where present;
• web admin UI, mobile app pairing and local setup portal;
• TR-069, USP/TR-369 or other remote-management channel;
• vendor or ISP cloud used for remote access, parental controls, telemetry, mesh coordination or update orchestration;
• firmware update service, signing keys, recovery image and support process.

The evidence file should also record what is outside the product: the customer's ISP account, third-party smart-home devices, customer-authored network rules, the user's modem where sold separately, and downstream operator systems not supplied by the manufacturer.

Which conformity route should the manufacturer plan for?

Important Class I does not automatically mean that every router needs third-party assessment, but internal control should not be assumed. If the manufacturer can use the general internal-control route and has fully applied the relevant harmonised standards, common specifications or an appropriate European cybersecurity certification scheme at assurance level at least substantial for the applicable essential requirements, it may be available. If those references do not exist, are only partly applied, are not applied, or do not cover all relevant requirements, plan for EU-type examination plus internal production control or full quality assurance. The general route mechanics and what the EU declaration of conformity must contain live in the conformity-assessment and declaration-of-conformity guides; this page covers only the router-specific choice.

If the same hardware variant is also marketed as a firewall, VPN gateway, network-management appliance or managed security platform, create a separate classification memo for that SKU.

How does the RED cybersecurity deadline map to the CRA?

Most routers and internet-connected modems contain a radio (Wi-Fi, a cellular modem or similar), and that radio-equipped subset has already crossed one cybersecurity gate before the CRA arrives. From 1 August 2025 the Radio Equipment Directive cybersecurity requirements (RED Article 3.3 points d, e and f, set by Delegated Regulation (EU) 2022/30) apply to internet-connected radio equipment such as Wi-Fi routers, mesh nodes, modem-routers and cellular gateways. A purely wired device, such as an Ethernet-only router or a bare DSL, cable or fibre modem with no radio, sits outside RED's cybersecurity scope, but every one of them is still a product with digital elements under the CRA. CRA reporting duties start on 11 September 2026 and the CRA becomes fully applicable on 11 December 2027, when the Commission's repeal of the RED cybersecurity Delegated Regulation through Delegated Regulation (EU) 2026/339 takes effect so the two regimes do not overlap.

For a router maker the practical reading is:

• Between 1 August 2025 and 10 December 2027, applicable radio equipment meets the RED cybersecurity requirements; the harmonised route runs through the EN 18031 series, with ETSI EN 303 645 as the consumer baseline it builds on.
• From 11 December 2027 the same cybersecurity duties sit under the CRA, with its wider lifecycle obligations: secure-by-default configuration, the vulnerability-handling process, the support-period statement, and the reporting duties that already start on 11 September 2026.
• A router already placed on the market before 11 December 2027 comes under the CRA only if it is substantially modified after that date. The one exception is the reporting duty, which applies to every in-scope product, including units already sold.
• The router-specific CRA harmonised standard in preparation is ETSI EN 304 627 (Routers, Modems and Switches), which maps to Class I item 12 and the essential cybersecurity requirements. It is still a draft, so plan the conformity route on the standards actually cited at the time, and reuse the controls built for RED (secure defaults, signed updates, access control) as the basis for the CRA file rather than starting a separate project.

What evidence should be ready?

Which router architecture details should not be missed?

Router evidence has to follow the edge device that is actually shipped. A retail Wi-Fi router, ISP modem-router, PON ONT, cable modem, mobile hotspot, mesh node and managed switch have different WAN exposure, remote-management and firmware-branch risks.

The WAN side is where the device first parses unauthenticated input, and that side changes with the access technology. A retail Ethernet-WAN router, a cable modem-router, a fibre ONT and a cellular hotspot do not share the same provisioning channel or the same upstream peer.

What does a real router risk assessment look like?

Use this as an example of the depth expected in a technical-file risk assessment. The manufacturer still needs to run the assessment against the real router, modem chipset, wireless stack, remote-management channel, supplier SDKs, update ownership, sales claims, and support-period promise.

Example product profile

Example product: ExampleCo HomeRouter R1, a Wi-Fi 7 home router sold in the EU through retail and ISP white-label channels. It has Ethernet WAN, four LAN ports, guest Wi-Fi, a local web admin UI, mobile-app onboarding, optional ISP remote management, signed OTA firmware, automatic update checks, DNS/DHCP services, parental-control profiles, and a recovery image.

The product boundary includes the router hardware, bootloader, kernel, Wi-Fi drivers, WAN services, LAN services, firewall defaults, local web UI, mobile-app pairing, vendor cloud for remote access, optional ISP remote-management agent, OTA service, recovery image, support website, coordinated-disclosure intake and advisory process. It excludes the customer's modem when sold separately, the ISP subscription, third-party smart-home devices, the user's identity provider, and downstream ISP OSS/BSS systems unless the same economic operator supplies them as part of the product.

Release gate: firmware engineering owns the first-boot baseline, product security owns the exposure test, and support owns the reset and RMA evidence. Artifact: provisioning record, post-setup exposure scan, downgrade-rejection test and transfer or unbind result.

Asset Inventory

Trust Boundaries

Threat Scenarios

Initial Risk Register

Control and Evidence Mapping

Residual Risk After Controls

How Should Support, Updates and Reporting Work?

For the HomeRouter R1 example, the practical CRA file should include the support-period operating model, not only the pre-market release evidence.

Which validation gates run before release?

A router release should not pass on a blanket "security reviewed" note. List the specific decisions that can hold the shipment, and give each one the failure it guards against, the control that closes it and the artifact that proves the control actually runs.

Who owns router development from concept to support?

Ownership of a router release changes hands as it goes from a product definition to a fleet running in customers' homes and on ISP networks. The rail below gives each stage a single accountable lead, the record that lead keeps current, and the gate that has to close before the next stage starts.

Each transition is a freeze point: the boundary is fixed before architecture starts, the design intent before code, the build before verification, and the release before it ships, after which the firmware is kept running through the support window. A vulnerability report, an ISP or supplier advisory, or a field failure reopens the next boundary memo, threat list and component inventory rather than the one that already shipped.

Which evidence records belong in the file?

The file should let a reviewer follow the router decision from product identity to security controls. Each row points to a maintained record, not a folder of disconnected screenshots.

What goes in a router SBOM?

The CRA requires a machine-readable SBOM that identifies the product's components and covers at least top-level dependencies, without naming one fixed format yet. Router makers normally choose CycloneDX or SPDX. The cross-product detail on SBOM mechanics lives in the dedicated SBOM guide; this section covers the router-specific tree.

A router release ships several digital elements with separate update cycles, not one binary. Two patterns meet the CRA minimum: one product-level component inventory with element-separated sections (bootloader, kernel, Wi-Fi firmware, WAN-PHY stack, network daemons, TLS, remote-management agent and web UI each version-pinned), or one inventory per shipped element refreshed at each release. Either is acceptable so long as it is machine-readable and top-level dependencies are covered.

What does the release sign-off check?

Sign-off before the EU release should be able to close four record folders, shown as Q1 to Q4 below. The complete file index sits in the evidence map above; the four questions here are only the ones that block the release when a folder is empty.

Evidence: pin each of the four records to the exact firmware version it signs off, so the same release can be reopened later without re-deriving the answer.

How does the router hand off to importer, distributor, ISP and operator?