EECC Art. 40 vs NIS2 Art. 21: The 7 Security Gaps Telecom Operators Must Close Before Enforcement

On 18 October 2024, the European Electronic Communications Code’s security chapter ceased to exist as an independent regulatory framework. NIS2 Directive Article 43 deleted Articles 40 and 41 of Directive (EU) 2018/1972 on that date, replacing them with the obligations of Directive (EU) 2022/2555.

For providers of public electronic communications networks and services, this is not a rebranding exercise. EECC Article 40 organised security around eight domains and 29 high-level objectives. NIS2 Article 21 expands that to ten sub-measures under an all-hazards scope that includes supply chain security, cryptography, multi-factor authentication, and formal effectiveness testing — none of which appeared in the EECC framework.

The practical question compliance teams now face: which EECC controls carry forward, and which seven areas require new documentation and programmes from the ground up?

This guide answers that question using Commission Implementing Regulation (EU) 2024/2690 (CIR 2024/2690) as a benchmark. The CIR does not directly apply to electronic communications providers — its scope covers DNS providers, cloud services, data centres, and managed service providers. However, its 13 Annex sections define the technical standard against which national competent authorities increasingly measure NIS2 Art. 21 compliance across all Annex I sectors, making it the most detailed publicly available map of what full Art. 21 compliance requires at control level.

Who This Applies To: Scope, Entity Types, and Classification

Electronic communications providers are treated differently from every other NIS2 sector. The Directive’s default rule in Article 2(1) sets a medium enterprise threshold — 50 employees or €10 million annual turnover — before obligations apply. Article 2(2)(a)(i) carves telecoms out of that threshold entirely: providers of public electronic communications networks or of publicly available electronic communications services must comply regardless of size.

That size-independence places all in-scope operators directly in the Essential entity tier from day one. Essential entities face proactive ex-ante supervision by the national competent authority (NCA), independent security audits under Article 32(4)(b), full Article 21 and Article 23 obligations, board-level personal accountability under Article 20, and administrative fines up to €10,000,000 or 2% of total worldwide annual turnover — whichever is higher — under Article 34.

Entity type	NIS2 applies?	Classification	Supervisory model
Fixed-line network operator (public service)	Yes — regardless of size	Essential	Ex-ante (proactive)
Mobile network operator	Yes — regardless of size	Essential	Ex-ante
Internet service provider (public broadband)	Yes — regardless of size	Essential	Ex-ante
Satellite communications operator (public service)	Yes — regardless of size	Essential	Ex-ante
Private corporate network (not public service)	No — Art. 2(2)(a)(i) does not apply	Out of scope	N/A
ICT managed service provider serving telecoms	Potentially — if meeting CIR 2024/2690 entity type	Important or Essential by separate rule	Ex-post or ex-ante

In most EU member states, the national regulatory authority for electronic communications (the NRA designated under the EECC framework) is jointly designated as an NCA under NIS2 alongside the national cybersecurity authority. Telecom operators should confirm the dual notification channel with their national authority before their first Art. 23 incident: failing to notify the CSIRT while only informing the NRA does not satisfy the Directive’s reporting requirements.

The Transition: What NIS2 Article 43 Did to EECC Article 40

EECC Article 40 was never a vague general-security clause. The ENISA Guideline on Security Measures under the EECC (4th edition, 2021) structured it into eight security domains covering 29 high-level security objectives, each broken into three levels of implementation sophistication (basic / industry standard / state-of-the-art):

1. Governance and risk management — security policy, risk assessment methodology, organisational accountability structures
2. Human resources security — pre-employment screening, role-based security responsibilities, security clauses in employment contracts
3. Security of systems and facilities — physical premises, equipment security, operational technology protection
4. Operations management — change management, capacity planning, malware protection, logging
5. Incident management — detection, response, notification to national regulatory authority
6. Business continuity management — continuity plans, backup procedures, recovery testing
7. Monitoring, auditing and testing — continuous monitoring, security testing, compliance auditing
8. Threat awareness — security awareness programmes for staff and management

Properly implemented, these eight domains created a credible compliance posture. As the IBA analysis of the transition observed, the EECC security chapter was “not only complemented, but entirely replaced” by NIS2 — making this a structural change, not a relabelling.

NIS2 Article 21’s all-hazards scope extends well beyond the EECC’s primarily network-focused framework. It adds explicit obligations for supply chain security that EECC never contemplated, formal cryptography policies that go beyond EECC’s confidentiality requirement, and MFA requirements that EECC’s general network access security never specified. The core compliance question is identifying which of the 13 control areas CIR 2024/2690 defines — as the most detailed available Art. 21 benchmark — have adequate foundation in the EECC’s eight domains, and which seven do not.

EECC Art. 40 vs NIS2 Art. 21: The Dual Compliance Table

This table maps EECC Article 40’s eight security domains against NIS2 Article 21(2)’s ten sub-measures using CIR 2024/2690’s 13 Annex sections as the control-level benchmark. “EECC credit applies” means existing EECC documentation provides an adequate foundation that can be updated and relabelled for NIS2 purposes. “New build required” means the EECC framework created no equivalent obligation and new documentation must be produced.

CIR 2024/2690 Annex section	NIS2 Art. 21(2) sub-measure	EECC Art. 40 domain	EECC credit?
§1 — Policy on security of NIS	(a) Risk analysis and information security policies	Domain 1: Governance and risk management	Yes
§2 — Risk management policy	(a) Risk analysis and policies	Domain 1: Governance and risk management	Yes
§3 — Incident handling	(b) Incident handling procedures	Domain 5: Incident management	Yes
§4 — Business continuity and crisis management	(c) Business continuity, backups, DR, crisis management	Domain 6: Business continuity management	Yes
§5 — Supply chain security	(d) Supply chain security	No EECC equivalent	No — new build required
§6 — Secure acquisition, development and maintenance	(e) System acquisition, development, maintenance; vulnerability management	Domain 3 (partial only: systems/facilities)	No — SSDLC and VDP are new
§7 — Effectiveness assessment	(f) Assessment procedures for effectiveness	Domain 7 (partial only: monitoring/auditing)	No — structured effectiveness testing and peer review are new
§8 — Basic cyber hygiene and security training	(g) Cyber hygiene practices and cybersecurity training	Domain 8: Threat awareness	Yes
§9 — Cryptography	(h) Cryptography and encryption policies	No EECC equivalent (EECC had confidentiality, not crypto policy)	No — new build required
§10 — Human resources security	(i) HR security, access controls, asset management (HR component)	Domain 2: Human resources security	Yes
§11 — Access control (incl. MFA)	(j) MFA, continuous authentication, secured communications, emergency systems	No EECC equivalent for MFA specifically	No — MFA and formal access control policy are new
§12 — Asset management	(i) HR security, access controls, asset management (asset component)	Domain 3 (partial only: systems/facilities)	No — formal asset inventory and lifecycle management are new
§13 — Environmental and physical security	Art. 21(1) all-hazards approach (physical threats)	Domain 3 (partial only: security of systems/facilities)	No — documented all-hazards physical security is new

Reading the table: Six of the thirteen control areas have adequate EECC antecedents: security policies, risk management, incident handling, business continuity, cyber hygiene, and HR security. Seven do not. The seven gaps represent compliance work that cannot be satisfied by pointing a national competent authority to existing EECC documentation.

The 7 NIS2 Gaps: What Telecoms Need to Build From Scratch

Gap 1 — Supply chain security (CIR §5 / Art. 21(2)(d))

EECC Article 40 said nothing about supplier relationships. NIS2 Art. 21(2)(d) obliges entities to address “the security of the supply chain, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” For a major operator, that means every network equipment vendor, cloud platform provider, CDN, and OSS/BSS supplier requires documented risk assessment and contractual security requirements. The EU Cooperation Group’s coordinated risk assessment process for 5G supply chains adds a further layer for mobile operators: the EU 5G Toolbox’s CM14 measure requires operators to apply appropriate restrictions for suppliers classified as high-risk. EECC created no equivalent obligation at any sophistication level.

Gap 2 — Secure acquisition, development, and maintenance (CIR §6 / Art. 21(2)(e))

EECC Domain 3 covered the physical and operational security of systems in the aggregate. CIR §6 goes substantially further: it requires secure development lifecycle (SDLC) practices, configuration baselines, security-gated change management, patch management with defined SLAs, and a vulnerability handling procedure including a coordinated vulnerability disclosure (CVD) policy. Operators purchasing third-party network software must now specify security requirements in procurement contracts and test configurations against baselines before deployment — none of which EECC Domain 3’s 29 objectives required.

Gap 3 — Effectiveness assessment (CIR §7 / Art. 21(2)(f))

EECC Domain 7 required monitoring, auditing, and testing as compliance activities. NIS2 Art. 21(2)(f) requires procedures specifically to “assess the effectiveness” of cybersecurity risk-management measures — a distinct obligation that demands evidence controls are working, not merely that they exist on paper. CIR §7 translates this into structured measurement metrics, periodic reviews by independent parties, and a corrective-action register. An annual penetration test with no management sign-off on remediation satisfies the EECC; it does not satisfy Art. 21(2)(f).

Gap 4 — Cryptography and encryption policies (CIR §9 / Art. 21(2)(h))

EECC Article 40’s confidentiality obligation covered the secrecy of communications in transit. NIS2 Art. 21(2)(h) requires a formal policy “on the use of cryptography and, where appropriate, encryption.” CIR §9 expands this to include a cryptographic key lifecycle policy covering key generation, storage, rotation, revocation, and destruction. For operators managing network management systems, OSS/BSS platforms, and customer data stores, this is a new documentary requirement. Most EECC compliance programmes addressed confidentiality through network-layer controls and never produced a cryptographic key management policy as a standalone document.

Gap 5 — Multi-factor authentication and access control (CIR §11 / Art. 21(2)(j))

NIS2 Art. 21(2)(j) explicitly requires “multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems.” CIR §11 codifies this into access control policies, privileged account management registers, and documented MFA deployment scope with exception handling. EECC general network access security measures did not require MFA. Operators managing privileged access to core network infrastructure, OSS systems, and network management planes must now document MFA coverage, define where exceptions apply, and maintain a privileged account register — all new compliance artefacts.

Gap 6 — Asset management (CIR §12 / Art. 21(2)(i))

EECC Domain 3 addressed the security of systems and facilities in aggregate. CIR §12 requires a maintained, accurate inventory of assets — hardware, software, data — classified by criticality, with documented lifecycle management procedures for each category including acquisition, maintenance, and decommissioning controls. For a large operator with tens of thousands of network elements, routers, switches, base stations, and management servers, this represents an asset management programme at a granularity EECC never mandated. The classification-by-criticality requirement is particularly new: EECC treated the network as a system, not as a collection of individually classified assets.

Gap 7 — Environmental and physical security (CIR §13 / Art. 21(1) all-hazards)

NIS2’s all-hazards approach explicitly extends to physical threats against network infrastructure. CIR §13 requires documented facility protection measures, perimeter controls, physical access controls for data centres and network facilities, and environmental monitoring covering fire, flood, temperature, and power. EECC Domain 3’s “security of systems and facilities” covered physical premises in its scope but did not require the structured, documented, and tested physical security programme that CIR §13 specifies. Operators who relied on operational best practice rather than documented physical security controls now need to formalise those controls as auditable policy documents.

5G Network Slicing: NIS2 Obligations EECC Never Anticipated

5G network slicing creates isolated logical networks on shared physical infrastructure, enabling operators to offer differentiated service guarantees across enterprise private networks, URLLC slices for critical IoT, and eMBB slices for broadband. EECC Article 40 was written for homogeneous public electronic communications networks. NIS2 Art. 21’s all-hazards approach applies to sliced architectures without modification — but the compliance implications are more complex than a standard rollout.

Art. 21(2)(e) — slice isolation as network security obligation. Each slice is a logical boundary that must be security-enforced. Breach of one slice’s management plane creates risk for co-located slices even where physical separation exists. Under Art. 21(2)(e), operators must document network security controls for slice boundaries, including the virtual network function (VNF) isolation mechanisms and orchestration plane access restrictions. This applies to both slice creation and teardown — a slice decommissioned without proper cryptographic material revocation leaves keys accessible to subsequent tenants.

Art. 21(2)(d) — slice vendors as critical supply chain. Network slice infrastructure depends on virtualisation platforms, orchestration software, and slice management functions supplied by third parties. Each of these is a direct supplier under Art. 21(2)(d). The EU 5G Toolbox’s CM14 measure requires operators to perform supplier-specific risk assessments for slice infrastructure vendors and apply appropriate restrictions for suppliers classified as high-risk. EECC Article 40 created no framework for vendor-level security classification at any level of sophistication.

Art. 21(2)(a) — per-slice risk analysis. An operator offering multiple slice types to enterprise customers cannot apply a single risk analysis across all of them. A healthcare slice carrying patient monitoring data carries a materially different threat model from a media streaming slice. NIS2’s risk analysis obligation applies to each slice type’s threat model separately. National competent authorities in mobile-dense jurisdictions are beginning to ask for slice-by-slice risk documentation at first audit contact, making this an early compliance priority for 5G operators rather than a future consideration.

Enforcement, Penalties, and Competent Authority Reporting

Electronic communications providers — as Essential entities under Annex I — face the higher tier of NIS2’s penalty framework and the stricter ex-ante supervisory model.

Category	Essential entity maximum	Important entity maximum	Source
Administrative fine	€10,000,000 or 2% global annual turnover (higher applies)	€7,000,000 or 1.4% global annual turnover (higher applies)	NIS2 Art. 34
On-spot checks	Permitted for essential entities (ex-ante)	Reactive only (ex-post)	NIS2 Art. 32
Management body sanction	Temporary management ban possible for repeated negligent breach	Not applicable under Art. 32(5)	NIS2 Art. 32(5)
Deadline to comply	18 October 2024 (Art. 41)	18 October 2024	NIS2 Art. 41

See also: NIS2 penalty framework across EU member states.

Article 23 incident reporting differs materially from the former EECC notification regime. The NIS2 cascade is:

• 24 hours from becoming aware: early warning to national CSIRT (or NCA where CSIRT is not separately designated)
• 72 hours from awareness: full notification including initial severity assessment, affected services, and preliminary impact estimate
• 1 month from awareness: final report with root cause, full impact description, and corrective actions taken or in progress

The critical change from EECC: NIS2 notifications go to the CSIRT, not primarily to the national telecom NRA. Most EU member states have jointly designated the CSIRT body and the NRA as co-competent authorities under NIS2 for the electronic communications sector. Operators must confirm the dual notification requirement with their national authority — a report sent only to the NRA while the CSIRT remains uninformed does not satisfy Art. 23.

Article 20 board-level accountability is a new personal liability dimension that existed neither in EECC Article 40 nor in any predecessor framework. The management body must approve the entity’s NIS2 risk-management measures and oversee their implementation. Individual board members can be held personally liable for negligent breach, up to a temporary ban from management functions for essential entities under Art. 32(5).

Role-Specific Action Priorities

Role	Immediate priority	Key documentation required
CISO / IT Security Manager	Gap-assess the 7 CIR-aligned gaps; prioritise supply chain vendor register and MFA rollout across privileged accounts	Gap analysis report against Art. 21(2); vendor risk register; MFA coverage matrix with exceptions
Compliance Officer / Legal	Confirm entity registration with NCA; verify dual CSIRT + NRA notification chain; review Art. 20 board approval status	NCA registration confirmation; Art. 23 reporting SOP; board resolution approving Art. 21 measures
Board / C-Suite	Approve NIS2 risk-management measures (mandatory under Art. 20); understand personal liability exposure under Art. 32(5)	Signed board resolution; Art. 20 training record; board minutes documenting measure approval

Frequently Asked Questions

Does prior EECC compliance count toward NIS2?

Prior EECC compliance is not a recognised NIS2 defence, but existing EECC documentation — risk assessments, business continuity plans, incident procedures — can be repurposed with appropriate updates. The six CIR sections with EECC antecedents allow teams to build on existing work. The seven gaps require new documentation from the ground up.

Does CIR 2024/2690 apply directly to electronic communications operators?

No. CIR 2024/2690 directly binds DNS providers, cloud services, data centres, CDN operators, MSPs/MSSPs, online platforms, and trust service providers. It does not directly bind providers of public electronic communications networks or services. However, national competent authorities increasingly use the CIR’s 13 Annex sections as the detailed benchmark for Art. 21 compliance across all Annex I sectors, making it a practical reference even for out-of-scope entities.

What if we provide both electronic communications and managed services?

Entities qualifying under both categories must comply with the stricter obligation. CIR 2024/2690 applies to the managed service function; NIS2 Art. 21 applies to both. Combined organisations should document which systems fall under which supervisory framework and ensure the audit trail for each is maintained separately.

When are ex-ante audits expected for telecom operators?

Timing varies by member state. Most EU countries with fully transposed NIS2 legislation have indicated initial ex-ante inspections for Annex I essential entities beginning in 2025–2026. ENISA’s telecom sector guidance provides up-to-date information on supervisory timelines and preparation resources.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. NIS2 Directive Article 43 — Amendments to Directive (EU) 2018/1972: nis-2-directive.com
2. NIS2 Directive Article 2 — Scope: nis-2-directive.com
3. NIS2 Directive Article 21 — Cybersecurity Risk-Management Measures: nis-2-directive.com
4. ENISA Guideline on Security Measures under the EECC, 4th Edition, July 2021: enisa.europa.eu/publications/guideline-on-security-measures-under-the-eecc
5. ENISA — Telecom sector and Digital Infrastructure: enisa.europa.eu/topics/cybersecurity-of-critical-sectors/telecom-sector-and-digital-infrastructure
6. IBA — Cybersecurity in the electronic communications sector in Europe: ibanet.org/cybersecurity-in-the-electronic-communications-sector-in-Europe
7. Advisera — NIS2 CIR 2024/2690: Cybersecurity Requirements for EU Digital Infrastructure: advisera.com/articles/nis2-cir-2024-2690-digital-infrastructure-companies/
8. Plan Be Eco — NIS2 for IT & Telecommunications (2026): planbe.eco/en/blog/nis2-for-the-it-and-telecommunications-industry/
9. Directive (EU) 2022/2555 — Official text: EUR-Lex CELEX:32022L2555