Cybersecurity: The implementation of NIS2 in Luxembourg

Cybersicherheit: Die Umsetzung von NIS2 in Luxemburg Cybersecurity: The implementation of NIS2 in Luxembourg
Photo: Александр Бердюгин – AI/Adobestock

On 5 May 2026, Luxembourg adopted the law on measures to ensure a high level of cybersecurity, transposing Directive (EU) 2022/2555, commonly known as NIS2[1], into Luxembourg law.

The new law entered into force on 10 May 2026 and significantly expands Luxembourg’s cybersecurity framework. It replaces the narrower NIS1 regime with a broader framework imposing cybersecurity governance, risk management, incident reporting and supervisory obligations on a larger number of entities operating in Luxembourg.

Most importantly, potentially in-scope entities have only one month left, until 10 July 2026, to communicate the required information to their competent authority.

1. A broader cybersecurity regime

NIS2 applies to a much wider range of entities than the previous framework. According to the ILR, the Luxembourg NIS2 law applies to entities active in one or more sectors listed in Annexes I and II, including energy, transport, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, space, postal and courier services, waste management, chemicals, food, manufacturing, digital providers and research[2].

The Luxembourg law distinguishes between:

  • essential entities, generally covering larger entities active in highly critical sectors; and
  • important entities, covering other entities active in sectors listed by the law.

As a general rule, an entity active in a relevant sector will fall within scope if it meets the applicable size-cap criteria. The size assessment must be made by reference to the SME definition and may require a group-level analysis, taking into account linked and partner enterprises. Certain entities may, however, fall within scope irrespective of their size, including providers of public electronic communications networks or publicly available electronic communications services, trust service providers, top-level domain name registries and DNS service providers. An entity may also be identified as essential or important based on specific criteria, for example where it has already been identified as a critical entity or acts as a sole supplier in its field of activity.

The competent authority will generally be the Institut Luxembourgeois de Régulation (ILR), except for entities falling under the supervision of the Commission de Surveillance du Secteur Financier (CSSF). The Haut-Commissariat à la Protection nationale (HCPN) also plays a central role in cybersecurity policy coordination and cyber-crisis management.

2. Core obligations for in-scope entities

Entities falling within scope must implement appropriate and proportionate technical, operational and organisational measures to manage cybersecurity risks affecting their network and information systems.

These measures must cover, among other things:

  • risk analysis and information system security;
  • incident handling;
  • business continuity, backup management, disaster recovery and crisis management;
  • supply-chain security;
  • secure acquisition, development and maintenance of network and information systems;
  • vulnerability handling and disclosure;
  • cybersecurity training and cyber hygiene;
  • access controls, asset management and human resources security;
  • cryptography and encryption, where appropriate; and
  • multi-factor authentication or continuous authentication, where appropriate.

Cybersecurity also becomes a management responsibility. Management bodies must approve cybersecurity risk-management measures, oversee their implementation and receive appropriate cybersecurity training.

3. Incident reporting: 24 hours, 72 hours and one month

For significant incidents, the Luxembourg NIS2 law requires entities to move quickly from detection to regulatory communication. The reporting process is sequenced: an initial alert must generally be made within 24 hours, followed by a more detailed notification within 72 hours, and a final report within one month.

In-scope entities should therefore have a tested escalation procedure identifying who qualifies an event as reportable, who validates the notification, who contacts the competent authority, and how technical findings, legal assessment and management decisions are recorded. In practice, the effectiveness of the reporting framework will depend less on the existence of a policy than on the organisation’s ability to mobilise the right functions immediately after an incident.

4. Regulatory interplay

The Luxembourg NIS2 law forms part of a wider regulatory environment especially relevant n the context of heavy reliance on outsourced technology, cloud-based infrastructure and cross-border service providers  In practice, cybersecurity obligations will often need to be assessed alongside other frameworks, in particular the General Data Protection Regulation (GDPR), the Digital Operational Resilience Act (DORA) and the Luxembourg law of 17 December 2021 on electronic communications networks and services.

As a result, the same event may give rise to several notification and escalation processes. For example, a cyberattack affecting systems availability, client data or outsourced ICT services may have to be assessed under the Luxembourg NIS2 law, GDPR, DORA and the entity’s contractual notification obligations. The practical challenge is therefore not only to identify whether a report must be made, but also to determine to whom, by when, on what basis and with what level of detail.

For financial-sector entities, DORA will be the main reference point for ICT risk management, ICT third-party risk and major ICT-related incident reporting. Where a financial entity falls within DORA, its incident-reporting process should therefore be primarily structured around DORA’s harmonised framework. However, NIS2 may remain relevant where the issue falls outside DORA’s specific scope[3].

Financial entities should therefore not assume that DORA implementation automatically closes the NIS2 analysis. A mapping exercise remains advisable to identify any residual obligations and to ensure that governance, reporting and incident-response procedures are coherent across both frameworks.

5. Next steps

With the 10 July 2026 deadline approaching, potentially in-scope entities should:

  • confirm whether they fall within the scope of the Luxembourg NIS2 law;
  • determine whether they qualify as an essential or important entity;
  • identify whether their competent authority is the ILR or the CSSF;
  • prepare and submit the required information by 10 July 2026;
  • review their cybersecurity governance and management-body involvement;
  • update incident-response procedures to reflect the 24-hour, 72-hour and one-month reporting deadlines; and
  • align their NIS2, DORA, GDPR and contractual notification processes.

Conclusion

The Luxembourg NIS2 law marks a significant expansion of cybersecurity regulation. It introduces broader scope, stronger governance expectations, mandatory risk-management measures, incident-reporting obligations and enhanced supervisory powers.

The immediate priority is practical: entities potentially falling within scope should use the remaining month to complete their assessment and, where applicable, communicate the required information to the competent authority by 10 July 2026.

For more information about the transposition of NIS2 into German law, please click here.

[1] Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148.

[2] https://www.ilr.lu/en/sectors/niss/nis-2/scope-and-field-of-application/. The ILR guidance summarises the sectors falling within the scope of the Luxembourg NIS2 law, explains the size-cap rule and the relevance of group-level assessment under the SME definition, identifies certain entities that are in scope by default or regardless of size, and refers to the self-registration process.

[3] For example in relation to broader cyber-resilience coordination, certain supply-chain dependencies, cross-sector cooperation or risks affecting non-ICT infrastructure.



By continuing, you accept our privacy policy.
You May Also Like
Turbo-Zertifikate mit Beißkorb Turbo Certificates on a Leash
Read More

Turbo Certificates on a Leash

On 16 June 2026, BaFin’s general administrative order restricting the marketing, distribution and sale of turbo certificates enters into force. It establishes strict requirements for all distribution activities relating to turbo certificates directed at retail investors.
Read More
AMLA konsultiert Leitlinien zur laufenden Überwachung von Geschäftsbeziehungen – Was auf Verpflichtete zukommt AMLA Consults on Guidelines for the Ongoing Monitoring of Business Relationships – What You Should Expect
Read More

AMLA Consults on Guidelines for the Ongoing Monitoring of Business Relationships – What You Should Expect

Continuous monitoring is already one of the core obligations in anti-money laundering compliance today. However, the AMLR elevates this principle to a new level. Obliged entities must not only review individual transactions but continuously analyse and assess the entire business relationship throughout its lifecycle.
Read More
Datenschutz im Zahlungsverkehr – Rechtliche Grundlagen und Besonderheiten Data Protection in Payment Services – Legal Framework and Key Particularities
Read More

Data Protection in Payment Services – Legal Framework and Key Particularities

Data protection in payment services operates within the complex interplay of the GDPR, PSD2 and the German ZAG. A key challenge lies in the legal classification of payment data, as transaction data may reveal highly sensitive insights into individuals’ private lives. This article analyses the principal legal bases for data processing as well as the allocation of data protection responsibilities among payment service providers, PISPs and AISPs.
Read More