EU Network Code on Cybersecurity for Electricity: High and Critical Impact Entity Duties Explained

The EU Network Code on Cybersecurity for electricity turns cross-border grid security into a fixed cycle of risk assessments, mandated controls, four-hour attack reporting and exercises, and most of its duties start only when a national authority notifies an entity that it is high impact or critical impact. Commission Delegated Regulation (EU) 2024/1366, often shortened to NCCS, was adopted on 11 March 2024 and entered into force on 13 June 2024. It sits alongside NIS2 rather than replacing it, and its long staged timeline means many utilities, market operators and suppliers have not yet felt its full weight. This guide explains who is caught, what each type of entity must do and by when, and how to prepare before notification arrives. It is for security and compliance leads at transmission and distribution system operators, generators, market operators, aggregators and the ICT and managed security providers that serve them. For the wider utility security programme, see the Electric Utility Cybersecurity Programme Guide.

Key takeaways

• Duties follow notification, not sector membership. The code applies to an entity only once its competent authority identifies it as high impact or critical impact by comparing its electricity cybersecurity impact index (ECII) with EU thresholds; notification must happen no later than 13 June 2028.
• Two tiers, two control sets. High-impact entities apply minimum cybersecurity controls inside their high-impact perimeter; critical-impact entities apply advanced controls inside their critical-impact perimeter and must have compliance verified.
• Reportable attacks have a four-hour clock. Article 38 requires reporting to the CSIRT and competent authority without undue delay and at most four hours after becoming aware an attack is reportable; a NIS2 Article 23 report with the same information counts.
• Everything runs on a three-year cycle. Entity risk assessments, the cybersecurity management system review, verification and exercises all repeat every three years, feeding Member State, regional and Union-wide assessments.
• Suppliers are in scope too. Critical ICT service providers, managed security service providers and non-EU entities serving EU operators can be identified directly, and supply chain controls flow into procurement.

Scope: who and what is covered

The code is made under the Electricity Regulation (EU) 2019/943 and covers the cybersecurity aspects of cross-border electricity flows. Article 2(1) lists the kinds of entity that can fall within it, but each one is covered only if it is identified as high impact or critical impact under Article 24.

Non-EU entities: Article 2(3) extends the code to entities outside the Union that provide services to EU entities, where they are identified as high or critical impact. Under Article 15 such an entity must appoint a legal representative in the Union within three months of notification.

Key definitions: a high-impact or critical-impact process is a business process whose ECII values exceed the high or critical threshold set in the Union-wide risk assessment. The perimeter is the set of assets supporting those processes, and it decides where controls apply. The ECII itself is a classification scale for the possible consequences of a cyber-attack on processes involved in cross-border flows, using a common risk impact matrix (loss of load, generation reduction, loss of reserves or black start capability, outage duration and scale).

Relationship with NIS2: most identified entities will also be essential or important entities under NIS2. The code is the sector-specific layer for cross-border electricity, and recital 15 lets authorities treat compliance with its risk management requirements as meeting the corresponding NIS2 requirements, and the reverse. See the NIS2 Directive Guide and the Energy Sector Cyber Regulation Map.

Key obligations

Obligations by tier

Risk assessment and the CSMS

• Four-phase entity cycle: Article 26 sets context establishment, risk assessment, risk treatment and risk acceptance, repeated every three years. The entity uses the ECII in a business impact assessment to decide which processes and assets fall inside its high-impact or critical-impact perimeter.
• What the methodology must address: the methodologies under Article 18 cover supply chain threats, legacy systems, cascading effects, real-time operation and dependency on a single supplier. Expect those topics in your own assessment.
• CSMS content: Article 32 lists 12 elements, from scope and senior management responsibilities to internal audits, and encourages use of European or international standards. An existing ISO/IEC 27001 or IEC 62443-2-1 programme is a natural base. See the IEC 62443-2-1 Asset Owner Security Programme Guide.
• Derogations: Article 30 allows an entity to request a derogation from specific controls where costs clearly outweigh benefits or alternative controls achieve acceptable risk. The authority decides within three months, for up to three years, renewable.

Supply chain and procurement

Article 33 supply chain controls cover procurement requirements, supplier vetting, least-privilege design, supplier access, audit rights and supplier risk management. Advanced controls require security verification during procurement. Non-binding procurement recommendations (Articles 35 and 36) add guidance on European cybersecurity certification schemes. In practice this means contract templates for OT integrators, remote maintenance providers and cloud services need updating once the controls are adopted. See the OT Third-Party and Integrator Access Guide.

Monitoring, information sharing and reporting

• SOC capabilities (Art. 38(1)): for all assets in the perimeter, security logging, monitoring including intrusion detection and vulnerability assessment, incident analysis and response, and participation in information sharing. These can be bought from an MSSP, but the entity stays responsible and must supervise the provider.
• Single point of contact: each entity designates one for information exchange.
• Reportable cyber-attacks: an attack is reportable when the entity's own classification, using the methodology under Article 37(8) with five gravity levels, rates it significant or critical. Report to the CSIRT and competent authority within four hours at most, with the classification and its basis.
• Cyber threats: reportable threats with possible cross-border effects go to the CSIRT without delay, for example where indicators of compromise or attacker techniques could help other operators.
• Unpatched actively exploited vulnerabilities: entities share them with their CSIRT; no deadline is set, and CSIRTs pass them to ENISA without delay.
• Labelling and confidentiality: each submission states that it is made under the code, its category and, for attacks, the classification; information that could itself enable an attack is marked as for the authority or CSIRT only.

The authority side is also timed: competent authorities assess confidentiality and respond within 24 hours, share with other Member States within 24 hours and send anonymised information to identified entities within 24 hours. CSIRTs pass on threat information from entities within four hours.

Timeline and current status

Provisional phase: Article 48 lets authorities build a provisional list of candidate entities using the provisional ECII and invites those entities to apply the obligations voluntarily, using non-binding guidance and a provisional list of standards, until the formal controls are adopted. If you were notified under the provisional process, treat it as early warning of formal identification.

Corrections: the consolidated text on EUR-Lex also lists a corrigendum of 19 May 2026 affecting Articles 7(3), 21(1), 23(4) and 24(7). Read the current consolidated version before relying on those provisions. Several deadlines run from events (methodology approval, notification) rather than fixed dates, so check with your competent authority where your Member State stands.

Enforcement and penalties

The network code does not set its own fine amounts. Enforcement runs through the competent authority each Member State designated under Article 4, using national rules that implement the Electricity Regulation and, for overlapping duties, NIS2 national law, so penalties differ by Member State. Reporting failures that also breach NIS2 Article 23 fall under NIS2 supervision, where essential entities face maximum fines of at least EUR 10 million or 2% of worldwide turnover.

Oversight levers in the code itself include:

• Verification: critical-impact entities must demonstrate compliance on a fixed cycle (Article 31), and Member States may run national verification schemes at least yearly, covering full scope every three years (Article 25).
• Monitoring by ACER: ACER monitors implementation, publishes a report at least every three years and can request information from entities (Article 12).
• Cost recovery: regulators assess the costs of compliance, and reasonable, efficient and proportionate costs of system operators can be recovered through network tariffs (Article 11), which removes a common excuse for delay.

What it means for AI agents and non-human identities

The code is written in terms of assets, processes and perimeters, but the paths that matter in grid incidents run through identities: valid accounts, vendor remote access, service accounts in SCADA and historian integrations, and API credentials between market and scheduling systems.

• Inventory machine identities in the perimeter: the Article 26 asset inventory should list service accounts, certificates, API keys and integration credentials used by assets in the high or critical impact perimeter, not just hosts and devices. See the OT and ICS Identity and Access Guide.
• Supplier access is identity: Article 33 supplier access and least-privilege controls are mostly about vendor accounts, shared maintenance credentials and remote access tokens. Brokered, recorded and time-bound access is the practical answer.
• MSSP credentials are high value: an outsourced SOC under Article 38(1)(b) holds privileged log and often response access across many operators. Treat its accounts and API keys as critical, and remember the MSSP itself can be identified as high or critical impact.
• AI agents and automation: any agent or script allowed to change setpoints, schedules or market bids is part of a high or critical impact process. Give it its own identity, narrow permissions and logging that the SOC capabilities can see, and include it in the entity risk assessment.
• Reporting needs evidence: a four-hour report must state what happened. Logs that tie actions to specific human and machine identities make classification and reporting possible within the clock.

Compliance steps

1. Find your competent authority and status. Confirm which authority your Member State designated, whether you were placed on a provisional list and what timetable it expects for formal notification.
2. Estimate your likely tier. Map business processes that affect cross-border flows (balancing, scheduling, market coupling, large generation or load control) against the provisional ECII to judge whether you are likely high or critical impact.
3. Build the asset and identity inventory. Draw provisional perimeters and list assets, connections, suppliers and machine identities inside them. This is the input to the Article 26 assessment. See the OT Asset Visibility Guide.
4. Run a first entity risk assessment. Use the four phases and cover supply chain threats, legacy systems, cascading effects and single-supplier dependency; aim to be able to report within 12 months of notification. See the IEC 62443-3-2 OT Risk Assessment Guide.
5. Stand up or extend the CSMS. Map existing ISO/IEC 27001 or IEC 62443 processes to the 12 Article 32 elements and close gaps within the 24-month window.
6. Prepare the four-hour reporting path. Adopt the Article 37(8) classification scale in your incident process, designate the single point of contact, pre-agree CSIRT and authority channels, and align the report content with NIS2 Article 23 so one submission can serve both.
7. Close the SOC capability gap. Confirm logging, intrusion detection and vulnerability assessment cover every asset in the perimeter, including OT networks. If you use an MSSP, write supervision and data access terms into the contract. See the OT Network Security Monitoring Guide.
8. Update procurement. Add supply chain security requirements, supplier access rules and audit rights to OT and ICT contracts now, so the Article 33 controls apply smoothly six months after adoption.
9. Plan exercises. Critical-impact entities should schedule a cross-border attack scenario exercise for the year after notification, using the ENTSO for Electricity template scenario due by 31 December 2026.

Framework mapping

Measuring readiness

• Perimeter coverage: percentage of assets and machine identities in the provisional perimeter recorded in the inventory.
• Monitoring coverage: percentage of perimeter assets sending security logs to the SOC.
• Time to classify and report: measured in exercises, from detection to a classified report, against the four-hour limit.
• Supplier contract coverage: percentage of OT and ICT suppliers with security, access and audit clauses.
• CSMS gap closure: number of the 12 Article 32 elements implemented and evidenced.

Common failure patterns

• Waiting for notification: the CSMS and risk report windows (24 and 12 months) are short for organisations starting from zero; provisional lists exist precisely to start early.
• Perimeters drawn around devices only: leaving out the corporate identity systems, jump hosts and vendor access paths that reach the perimeter repeats the pattern seen in the Ukraine grid attacks, where valid accounts from the business network opened breakers.
• Two separate incident processes: running NIS2 and network code reporting in parallel teams risks missing the four-hour clock; Article 38(8) lets one NIS2 report carry the required information.
• Outsourcing responsibility with the SOC: buying monitoring from an MSSP without supervision terms leaves the entity liable for gaps it cannot see.
• Ignoring the supplier side: ICT providers and MSSPs that assume only operators are regulated may find themselves identified directly as critical ICT service providers.

Practitioner checklist

• Confirm your competent authority and whether you are on a provisional high or critical impact list.
• Map processes affecting cross-border flows and estimate your ECII tier.
• Build a perimeter inventory covering assets, suppliers, connections and machine identities.
• Complete a first four-phase entity risk assessment that covers supply chain, legacy and single-supplier risk.
• Map your ISMS or IEC 62443 programme to the 12 Article 32 CSMS elements.
• Adopt the Article 37(8) classification scale and test the four-hour report path in an exercise.
• Designate the single point of contact and agree CSIRT and authority channels.
• Verify SOC logging and intrusion detection reach every perimeter asset, including OT.
• Add security, access and audit clauses to OT, ICT and MSSP contracts.
• Track the event-driven deadlines and the corrigendum on the consolidated EUR-Lex text.

Standards and references

• EUR-Lex: Commission Delegated Regulation (EU) 2024/1366 network code on cybersecurity for cross-border electricity flows
• EUR-Lex: Consolidated text of Delegated Regulation (EU) 2024/1366
• EUR-Lex: Commission Delegated Regulation (EU) 2025/1759 correcting certain language versions
• ACER: Cybersecurity network code for electricity
• EUR-Lex: Directive (EU) 2022/2555 (NIS2)
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5

This guide summarises Commission Delegated Regulation (EU) 2024/1366 as of 8 November 2026 and is not legal advice. Related NHI Mgmt Group resources: Electric Utility Cybersecurity Programme Guide · Smart Grid Security Guide · Energy Sector Identity and OT Access Guide · EU Incident Reporting Clocks · IEC 62443 Guide