INDUSTRY · Telecom
Telecom: connected infrastructure and CRA/NIS2 overlap
Telecom sits at the intersection of infrastructure-operator regulation and product-manufacturer regulation, often within the same organisation.
LAST REVIEWED
Regulatory picture
NIS2 explicitly lists telecommunications among the sectors covered, meaning network operators and providers of publicly available electronic communications services must implement risk management measures and report significant incidents under the directive's national transpositions. Equipment vendors — of routers, base stations, customer premises equipment, IoT gateways — are manufacturers under the CRA and must meet its essential requirements for any product with digital elements placed on the EU market. Radio-connected equipment additionally intersects with the RED and its cybersecurity delegated act. Sector-specific technical standards, such as those from ETSI, including ETSI EN 303 645 for consumer IoT baseline security, inform good practice and can support CRA conformity arguments.
Typical engineering challenges
- Managing a fleet of deployed CPE across many hardware and firmware generations, some no longer under active development, against a single set of security expectations.
- Coordinating vulnerability disclosure and patch delivery across networks with heterogeneous, sometimes end-of-life, customer equipment.
- Distinguishing operator-level incident reporting duties (NIS2) from product-level vulnerability reporting duties (CRA) when the same organisation both operates and supplies equipment.
- Securing supply chains for network equipment where components originate from multiple vendors with varying security maturity.
- Ensuring remote update mechanisms for CPE and network equipment are themselves secure, since they are a high-value attack target.
How CRA interacts with sector rules
A telecom operator that also designs or private-labels its own CPE carries CRA manufacturer obligations for that equipment in addition to its NIS2 operator obligations for its network. The two reporting obligations are legally separate but should share an incident and vulnerability intake process, since a single compromised piece of equipment can trigger both a CRA product notification and a NIS2 operator incident report. Where equipment is radio-connected, CRA and RED delegated act essential requirements are coordinated to avoid duplicate conformity assessment.
What a typical engagement covers
- CRA scoping and classification for network equipment and CPE product lines, including RED interaction where relevant.
- Vulnerability handling and patch delivery process design across a heterogeneous deployed fleet.
- Alignment of NIS2 operator incident response and CRA product reporting into a single intake and escalation path.
- Technical documentation and secure development lifecycle evidence for equipment manufacturer obligations.
Frequently asked questions
Is a telecom operator subject to the CRA?
A telecom operator is subject to NIS2 as an operator of digital infrastructure. It becomes subject to the CRA specifically for any products with digital elements it manufactures or has manufactured under its own brand, such as private-labelled CPE, in addition to its NIS2 obligations.
Do CRA and RED cybersecurity requirements both apply to a Wi-Fi router?
A Wi-Fi router is radio equipment under the RED and a product with digital elements under the CRA. The essential requirements of both are coordinated so that meeting one can generally be treated as satisfying the corresponding requirements of the other, avoiding duplicate assessment for the same aspects.
How should end-of-life CPE be handled under the CRA?
Manufacturers must define and communicate a support period for products with digital elements, and vulnerability handling obligations apply for that stated period. Equipment past its defined support period falls outside active vulnerability handling duties, provided the support period and its end were properly communicated to users at the point of sale.
Does ETSI EN 303 645 satisfy CRA requirements?
ETSI EN 303 645 sets baseline security provisions for consumer IoT and can support a CRA conformity argument as evidence of good practice, but it is not itself a harmonised standard automatically conferring a presumption of CRA conformity; its role in conformity assessment depends on future harmonised standards mapping.