A router sits directly on a network trust boundary, so its CRA evidence should be built around how traffic, configuration and privileged administration are protected. The manufacturer should separate the data, control and management planes, minimise exposed services, secure default configuration, protect credentials and keys, verify firmware and updates, preserve recoverability and document how the Class I conformity route was selected. Annex III Class I status does not by itself mean third-party assessment is always mandatory; Article 32(2) determines when Module A remains available and when Module B plus C or Module H is required.
Routers Are Annex III Class I Important Products
Annex III Class I expressly lists routers, modems intended for connection to the Internet and switches. Commission Implementing Regulation (EU) 2025/2392 describes routers by their core routing function and includes wired routers, wireless routers, virtual routers and routers with or without modems. A manufacturer should document why the product meets that technical description rather than relying only on a retail label such as gateway, mesh node or network box.
Class I Does Not Automatically Mean Third-Party Assessment
For an important Class I router, Article 32(2) controls the conformity route. Internal control under Module A can remain available where the relevant harmonised standards, common specifications or qualifying cybersecurity certification schemes are applied as required by Article 32. Where the relevant recognised conformity references have not been applied, have only been applied in part, or do not exist for the relevant requirements, the manufacturer must use Module B followed by Module C or Module H for those requirements.
Model the Router as Three Security Planes
A useful router security model separates the data plane that forwards user traffic, the control plane that makes routing and topology decisions, and the management plane that changes configuration. Security failures in each plane have different consequences. A packet-processing flaw can expose traffic, a routing-control weakness can redirect traffic, and a management-plane compromise can give an attacker persistent privileged control of the entire device.
Treat WAN-Facing Services as a High-Risk Boundary
Internet-facing router interfaces are continuously exposed to untrusted traffic. The manufacturer should inventory services reachable from the WAN, disable unnecessary listeners, constrain remote administration, validate protocol parsers and test malformed or adversarial traffic. If remote administration is supported, the risk assessment should explain authentication, authorization, transport protection, rate limiting and how the feature behaves in its default state.
Secure LAN and Wireless Administration Separately
A router can expose administrative functions through Ethernet, Wi-Fi, local web interfaces, mobile applications, command-line access or vendor discovery protocols. Local network presence should not be treated as equivalent to trusted administrator status. The product should enforce appropriate authentication and authorization, separate guest or client access from management access and avoid default credentials that create shared compromise paths across deployed devices.
Wireless Routers Add Radio and Pairing Attack Surfaces
Wireless routers add radio configuration, wireless authentication, guest networks, mesh backhaul and onboarding mechanisms to the CRA security case. Evidence should address secure defaults for wireless security, management of pre-shared or generated credentials, isolation between guest and trusted networks, pairing or mesh enrolment, and the consequences of resetting or transferring ownership of a device.
Routing and Network Services Need Abuse-Oriented Testing
Routers often implement routing protocols, DHCP, DNS forwarding, NAT, packet filtering, IPv6 functions, tunnelling and discovery services. The manufacturer should identify which functions are present and test security-relevant parsers, state handling, privilege boundaries and configuration inputs. The technical file should distinguish core routing functionality from optional services so that the risk analysis can show which interfaces and controls support each function.
Protect the Firmware and Boot Chain
Router security depends heavily on firmware integrity because compromise below the administration layer can survive configuration changes. Where appropriate to the product and risk, manufacturers should use authenticated firmware images, protect signing keys, verify updates before installation and maintain a boot or recovery design that resists unauthorized firmware. Evidence should include both the security mechanism and tests showing how invalid or interrupted updates are handled.
Update Delivery Must Work for Long-Lived Installed Devices
Routers can remain deployed for years with little direct user attention. The update system should therefore address update discovery, authenticity, integrity, installation, rollback or recovery, supported-version identification and communication when user action is required. If cloud infrastructure or a mobile application participates in update delivery, those dependencies should be included in the product security architecture and failure analysis.
Cloud-Managed Routers Need a Separate Remote-Control Trust Model
A cloud-managed router can create a privileged remote path capable of changing firewall rules, wireless settings, DNS configuration, credentials or firmware. The manufacturer should document device-to-cloud authentication, account authorization, tenant separation, command integrity, administrative logging, service compromise scenarios and what the router can still do if the remote service becomes unavailable. Where the remote service meets the CRA definition of a remote data processing solution, it should be treated as part of the product boundary.
Configuration Backup and Factory Reset Are Security Functions
Configuration export, restoration and factory reset can expose credentials, keys or privileged settings if implemented poorly. Backup files should be protected according to their sensitivity, restoration should not bypass security checks, and factory reset should return the product to a known security state. Ownership-transfer procedures should consider whether old administrator credentials, cloud bindings or user data survive the reset.
Keep Router Evidence Tied to Hardware and Firmware Versions
A defensible router technical file should identify hardware revisions, boot components, operating system or firmware versions, network services, exposed interfaces, cryptographic material, update mechanism, remote dependencies and test results. When a hardware revision changes radios, processors or secure elements, the manufacturer should record whether the existing cybersecurity risk assessment and conformity evidence still apply.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.