NIS2 Implementing Regulation 2024/2690 Guide

If you run cloud, DNS, data centre, CDN, managed service, managed security or trust services in the EU, your NIS2 security measures are not left to national discretion: Commission Implementing Regulation (EU) 2024/2690 spells them out in a 13-section Annex and sets numeric thresholds for what counts as a significant incident. The NIS2 Directive itself only lists ten headline measures in Article 21(2). For the providers named in Article 21(5), the Implementing Regulation turns those headings into specific, auditable requirements, including identity lifecycle, privileged account and multi-factor authentication controls. This guide covers who is in scope, the Annex obligations, the incident thresholds, current status, enforcement, what the text means for service accounts, API keys and AI agents, and a compliance plan. It is for security, compliance and platform leads at digital infrastructure and ICT service providers. For the wider directive, see the NIS2 Directive Guide.

Status checked 27 October 2026: Implementing Regulation (EU) 2024/2690 was adopted on 17 October 2024, published in the Official Journal on 18 October 2024 and entered into force on 7 November 2024. A Commission proposal of 20 January 2026 to amend NIS2 is still in the legislative process and has not changed this Regulation.

Key takeaways

One rulebook, no national variation: as an implementing regulation it applies directly, so a cloud or MSP provider faces the same Annex requirements in every Member State, supervised where it has its main establishment.
Numeric incident triggers: Article 3 makes an incident significant at a direct financial loss above EUR 500,000 or 5% of annual turnover, whichever is lower, and Articles 5 to 14 add service triggers such as a cloud outage of more than 30 minutes.
Identity is written into the text: Annex section 11 requires unique identities for systems and users, separate credentials and strong authentication for privileged accounts, admin accounts used only for admin tasks, and multi-factor or continuous authentication.
Machine identities are not exempt: point 11.5 covers "systems" as well as users, shared identities need documented approval, and unneeded identities must be deactivated without delay, which reaches service accounts, API keys and agent credentials.
Documented exceptions are allowed, silent gaps are not: Article 2 lets an entity treat a requirement as not applicable or not feasible only if it documents the reasoning, so the evidence file is as important as the control.

Scope: who and what is covered

Article 1 lists the entity types. Whether an organisation is an essential or important entity, and whether NIS2 applies at all, is still decided by the directive and national transposition law. The Regulation only adds detail for entities already in scope.

Entity type (Art. 1)	Entity-specific incident article	Typical examples
DNS service providers	Art. 5	Recursive and authoritative DNS operators
TLD name registries	Art. 6	Country code and generic TLD registries
Cloud computing service providers	Art. 7	IaaS, PaaS and SaaS platforms
Data centre service providers	Art. 8	Colocation and hosting facilities
Content delivery network providers	Art. 9	CDN and edge delivery networks
Managed service and managed security service providers	Art. 10	MSPs running client infrastructure, MSSPs running SOC and detection services
Online marketplaces	Art. 11	Platforms where consumers contract with traders
Online search engines	Art. 12	General web search services
Social networking platforms	Art. 13	Platforms where users connect and share content
Trust service providers	Art. 14	Qualified and non-qualified eIDAS trust services

Jurisdiction: NIS2 recitals 113 and 114 explain that these providers fall under the Member State of their main establishment in the EU, generally where cybersecurity risk management decisions are predominantly taken. One national authority supervises the whole EU footprint.
Customers are counted: user counts in Articles 7 and 9 to 14 include contracted customers and the natural and legal persons linked to business customers, so a B2B provider's thresholds are reached faster than headline customer numbers suggest.

Key obligations

Article 2 states that the Annex sets the technical and methodological requirements for the measures in NIS2 Article 21(2)(a) to (j). The table lists the sections, the main requirements, and review cycles that the text states.

Annex section	Core requirements	Stated cadence
1. Security policy	Network and information security policy, roles, responsibilities and authorities	Policy reviewed at least annually (1.1.2)
2. Risk management	Risk framework, treatment plan, compliance monitoring, independent review	Risk assessment results and treatment plan reviewed at least annually (2.1.4)
3. Incident handling	Policy, monitoring and logging, event reporting, assessment and classification, response, post-incident review	Recurring incidents assessed quarterly (3.4.2)
4. Business continuity	Continuity and disaster recovery plan, backup and redundancy, crisis management	Regular backup integrity checks and recovery tests (4.2)
5. Supply chain	Supplier policy, selection criteria, contract clauses, directory of direct suppliers and service providers	Planned intervals and after significant change (5.1)
6. Acquisition, development, maintenance	Secure acquisition and SDLC, configuration and change management, testing, patching, network security, segmentation, malware protection, vulnerability handling and disclosure	Scans at planned intervals; critical vulnerabilities handled without undue delay (6.10)
7. Effectiveness assessment	What is measured, how, when and by whom	Planned intervals
8. Cyber hygiene and training	Awareness for staff, management and suppliers; role-based training	Repeated over time and on role change
9. Cryptography	Policy, approved algorithms with cryptographic agility, full key lifecycle	Not stated
10. Human resources	Responsibilities, background checks to the extent feasible, leaver duties, disciplinary process	Assignments reviewed at least annually (10.1)
11. Access control	Policy, access rights, privileged accounts, admin systems, identification, authentication, MFA	Privileged accounts reviewed at planned intervals (11.3)
12. Asset management	Classification, handling, removable media, inventory, return of assets	Classification reviewed periodically (12.1)
13. Environmental and physical	Supporting utilities, physical and environmental threats, perimeter and physical access	Regular testing of utilities (13.1)

Access control in detail (Annex section 11)

11.1 Access control policy: logical and physical access rules covering staff, visitors and suppliers, with access only for adequately authenticated users.
11.2 Management of access rights: rights granted and removed on need-to-know, least privilege and separation of duties; changed on role change or exit; third-party access limited in scope and duration; rights logged and reviewed.
11.3 Privileged and system administration accounts: strong authentication such as MFA, admin accounts used exclusively for admin tasks, privileges individualised and restricted as far as possible, and review at planned intervals.
11.4 Administration systems: used only for administration, separated from other applications, protected by authentication and encryption.
11.5 Identification: the full identity lifecycle, unique identities for systems and users, user identities linked to a single person, shared identities only where necessary for business or operational reasons with explicit approval and documentation, and deactivation of unneeded identities without delay.
11.6 Authentication: strength matched to asset classification, credentials changed initially, at intervals and on suspected compromise, lockout after failed attempts, session termination on inactivity, separate credentials for privileged accounts, and state-of-the-art methods to the extent feasible.
11.7 Multi-factor authentication: multiple factors or continuous authentication where appropriate, with strength matched to classification.

Other points auditors pick up

Remote access by providers (6.7): service provider connections are authorised for a set period only, and system-to-system communication goes through trusted, isolated channels.
Patching (6.6): patches applied within a reasonable time, tested, from trusted sources and integrity checked; a decision not to patch must be documented.
Cryptography (9): key generation, storage, rotation, compromise handling, revocation, backup and destruction are all in scope, which is the legal hook for secrets and certificate lifecycle management.

Significant incident thresholds

NIS2 Article 23 defines when an incident must be reported; the Regulation makes that test objective for these providers. An incident is significant if any Article 3 general criterion, the Article 4 recurring rule, or an Article 5 to 14 entity-specific criterion is met. Scheduled interruptions and planned maintenance are excluded.

Provider	Outage trigger	Degraded service trigger	Data trigger
All entities (Art. 3)	Direct financial loss above EUR 500,000 or 5% of prior-year turnover, whichever is lower; death or considerable damage to health; suspected malicious unauthorised access able to cause severe operational disruption		Exfiltration, or possible exfiltration, of trade secrets
DNS (Art. 5)	Complete outage of recursive or authoritative resolution for more than 30 minutes	Average response time above 10 seconds for more than one hour	Compromise of authoritative resolution data, except misconfiguration affecting fewer than 1,000 domain names and no more than 1% of those managed
Cloud, CDN, MSP and MSSP (Arts. 7, 9, 10)	Complete outage for more than 30 minutes	Limited availability for more than one hour for more than 5% of EU users or 1 million users, whichever is smaller	Suspected malicious compromise of data, or compromise affecting more than 5% of EU users or 1 million, whichever is smaller
Data centre (Art. 8)	Complete outage of a data centre service	Limited availability for more than one hour	Malicious compromise of data; compromised physical access to the data centre
Marketplaces, search, social (Arts. 11 to 13)	Outage affecting more than 5% of EU users or 1 million	Limited availability at the same threshold	Malicious compromise, or compromise at the same threshold
Trust services (Art. 14)	Complete outage for more than 20 minutes	Unavailable for more than one hour in a calendar week; limited availability for more than 1% of users or 200,000, whichever is smaller	Compromise affecting more than 0.1% of users or 100, whichever is smaller; compromised physical access to restricted areas

Recurring incidents (Art. 4): incidents that are not significant on their own count as one significant incident if they occur at least twice within six months, share the same apparent root cause and together meet the Article 3 financial threshold. Annex point 3.4.2 requires a quarterly assessment to catch this. Once an incident is significant, NIS2 reporting applies: an early warning within 24 hours of awareness, an incident notification within 72 hours and a final report within one month of the notification (NIS2 recital 102 and Article 23). The Cyber Incident Reporting Requirements Map compares these clocks with other regimes.

Timeline and current status

Date	Event
16 January 2023	NIS2 Directive (EU) 2022/2555 enters into force
17 October 2024	Transposition deadline for Member States; Implementing Regulation 2024/2690 adopted the same day
18 October 2024	NIS1 repealed; Regulation published in the Official Journal
7 November 2024	Regulation enters into force (twentieth day after publication, Art. 16)
7 May 2025	Commission sends reasoned opinions to 19 Member States for incomplete NIS2 transposition
26 June 2025	ENISA publishes NIS2 Technical Implementation Guidance (v1.0), with a mapping table later updated to v1.2 in September 2025
20 January 2026	Commission proposes targeted NIS2 amendments alongside a revised Cybersecurity Act

The Regulation applies regardless of national transposition, but enforcement powers, the competent authority and the fine process come from national law, so in a Member State that has transposed late the practical supervisory route may still be forming. The January 2026 proposal is not law. As reported, it would create a "small mid-cap" category treated as important entities, take DNS providers out of automatic scope so that size thresholds apply, require more facts on ransomware incidents, and link a proposed cyber posture certificate to the Article 21(5) implementing act.

Enforcement and penalties

Who enforces: the competent authority of the Member State of main establishment, using the supervisory powers in national law transposing NIS2 Articles 32 (essential entities, ex ante and ex post) and 33 (important entities, ex post).
Maximum fines: NIS2 sets maxima of at least EUR 10 million or 2% of worldwide annual turnover for essential entities and EUR 7 million or 1.4% for important entities, whichever is higher. National laws may go higher.
Management accountability: NIS2 Article 20 requires management bodies to approve and oversee the measures and to follow training.

What it means for AI agents and non-human identities

The Annex never uses the phrase "non-human identity", but its wording covers machine credentials directly. Point 11.5 asks for unique identities for "systems and users". Point 11.3 covers system administration accounts, which in most cloud and MSP estates are automation principals rather than people. Point 9 covers the key lifecycle. See the Compromised MSP Playbook.

Annex point	Machine identity reading	Practical control
11.5 unique identities; shared only with approval	No shared automation accounts across tenants or pipelines without a documented reason	One workload identity per service and per customer tenant; register any shared account as an exception
11.5 deactivate unneeded identities without delay	Orphaned service accounts, stale API keys and retired agent credentials must be removed	Owner field on every NHI, last-used telemetry, automatic disablement after an inactivity window
11.3 privileged and admin accounts	CI/CD deployers, backup operators and RMM agents with admin rights are privileged accounts	Vault-issued, short-lived credentials; scope per task; quarterly privileged review including NHIs
11.2 third-party access limited in scope and duration	Delegated admin relationships and partner API tokens need expiry	Time-boxed delegated admin roles; expiring tokens; see the GDAP and MSP Delegated Admin Access Guide
11.6 change credentials on suspected compromise	Rotation must be possible on demand, not only on a schedule	Tested rotation runbooks for every secret class
9 key lifecycle	Signing keys, TLS keys and token signing secrets	Inventory, HSM or KMS storage, revocation tested
3.2 monitoring and logging	Agent and automation actions must be attributable	Log the identity, the delegating human where there is one, and the tool or API called

AI agents: an agent that operates customer infrastructure is an identity under 11.5 and, if it holds admin rights, a privileged account under 11.3. Give each agent its own identity, scope its tools, and keep a human owner on record. See the Service Account Security Guide and the Secrets Management Guide.
MFA for machines: 11.7 allows "continuous authentication where appropriate". Machines cannot use a second factor, so the practical equivalent is workload identity federation, certificate-bound tokens and conditional access on workload principals. Record this reasoning under Article 2 rather than leaving MFA unanswered for automation.

Framework mapping

Annex area	NIST CSF 2.0	NIST SP 800-53 Rev 5	ISO/IEC 27001:2022 Annex A
11.2 access rights	PR.AA-05	AC-2, AC-6	A.5.15, A.5.18
11.5 to 11.7 identification and authentication	PR.AA-01	IA-2, IA-5	A.5.16, A.5.17, A.8.5
11.3 privileged accounts	PR.AA-05	AC-6	A.8.2
3 incident handling and reporting	RS.CO-02, DE.CM-01	IR-6	A.5.24 to A.5.26
4.2 backup	PR.DS-11	CP-9	A.8.13
5 supply chain	GV.SC-05	SR-3	A.5.19 to A.5.21
6.6 and 6.10 patching and vulnerabilities	ID.AM-01 (inventory as prerequisite)	SI-2, RA-5	A.8.8
9 cryptography	PR.DS-01	SC-13	A.8.24

The mapping is indicative; an ISO/IEC 27001 certificate does not by itself prove conformity with the Annex.

Compliance steps

Confirm status and jurisdiction (weeks 1 to 2): record which Article 1 category each service falls in, whether you are essential or important, and the Member State of main establishment.
Build the incident classifier (weeks 2 to 6): encode Articles 3 to 14 as a decision table in the incident tool: outage minutes, latency, user percentages and the financial threshold.
Run a gap assessment against the Annex (weeks 4 to 10): score every numbered point, using ENISA's evidence examples. For each point record met, partly met, or not applicable with the Article 2 justification.
Fix identity first (months 3 to 6): inventory human and non-human identities, remove shared and orphaned accounts, separate admin credentials, enforce MFA for privileged humans and federated, short-lived credentials for workloads.
Close supplier and network gaps (months 4 to 9): create the supplier directory, add incident notification and audit clauses, time-box provider remote access and separate admin networks.
Test and prove (ongoing): keep prior configurations so a control that breaks a service can be rolled back, and run restore tests, privileged account reviews and annual policy and risk reviews on a calendar, with outputs filed as evidence.

Detection and measurement

Log: privileged and administrative sessions, creation and use of service accounts and API keys, and service availability metrics that feed the Article 5 to 14 thresholds.
Classification latency: median time from detection to a significant or not significant decision, against the 24 hour early warning clock.
Identity hygiene: percentage of identities, human and machine, with a named owner and unique credentials; target 100% for privileged.
Stale credentials: count of NHIs unused for 90 days still enabled.
Privileged review completion: share of privileged accounts reviewed in the last cycle.
Critical vulnerability age: days from disclosure to remediation for critical findings under point 6.10.

Common failure patterns

Counting only direct customers: Article 3 counts linked natural and legal persons of business customers, so a B2B MSP can pass the 1 million threshold earlier than expected.
MFA for people, nothing for machines: privileged automation with static keys and no documented Article 2 reasoning is the most common identity gap. The CISA Private-CISA GitHub leak shows how long a static admin key can stay exposed.
Permanent supplier access: provider connections without an expiry breach point 6.7 and point 11.2.
Missing the recurring rule: without a quarterly review, repeated small incidents with one root cause go unreported.
Undocumented exceptions: a control dropped as not feasible with no written reasoning is a finding in itself.

Practitioner checklist

Record the Article 1 category, entity class and main establishment for each service.
Encode Articles 3 to 14 thresholds in the incident classification workflow and test them.
Run the quarterly recurring incident assessment and keep minutes.
Score every Annex point with evidence, and document Article 2 exceptions.
Inventory all identities, including service accounts, API keys and AI agents, with owners.
Separate privileged credentials, enforce MFA for admins and short-lived credentials for workloads.
Time-box all third-party and delegated admin access.
Maintain the supplier directory and contractual incident clauses.
Test restores and rotation runbooks, and file the results.

Standards and references

This guide summarises Commission Implementing Regulation (EU) 2024/2690 and related NIS2 provisions as of 27 October 2026 and is not legal advice. Related NHI Mgmt Group resources: NIS2 Directive Guide · NIS2 Readiness Checklist · DORA and NIS2 Overlap Mapping Guide · Cybersecurity for MSPs and MSSPs Guide

NIS2 Implementing Regulation 2024/2690 Guide: Technical Measures for Digital Infrastructure Providers