The Digital Security Act is in force — and it is not NIS2. What that means for energy and transport right now

The most common mistake in Norwegian boardrooms right now

A great many Norwegian undertakings believe they are regulated by NIS2. They are not.

The Act on Digital Security — the Digital Security Act (digitalsikkerhetsloven), LOV-2023-12-20-108 — entered into force on 1 October 2025, together with the Digital Security Regulations (FOR-2025-06-20-1131). Lovdata's own EEA reference for the Act is unambiguous: EEA Agreement Annex XI No. 5cpa, Directive (EU) 2016/1148. That is NIS1. Not NIS2.

The NIS2 Directive (EU) 2022/2555 was adopted by the EU on 14 December 2022, with a transposition deadline for member states of 17 October 2024. For Norway, as of August 2026 the directive has been neither formally incorporated into the EEA Agreement nor implemented in Norwegian law. Work to assess how NIS2 and the CER Directive can and should be implemented is under way, and a Norwegian implementation will require the consent of the Storting, since it presupposes changes to the law. No confirmed entry-into-force date exists.

This is not a legal technicality without practical significance. It has three concrete consequences for how an IT security leader should prioritise.

Consequence 1: The requirements you are actually subject to today are Norwegian — and they are less detailed

§ 2 of the Digital Security Act sets out its scope: the Act applies to providers of socially important services under § 6 in the sectors of energy, transport, health, water supply, banking, financial market infrastructure and digital infrastructure, as well as to providers of digital services under § 9. Chapter 2 (§§ 6–8) sets out security requirements and a duty to notify for socially important services. Chapter 4 (§§ 13–17) gives the supervisory authorities the legal basis to issue orders to rectify, coercive fines and administrative fines for infringement.

The Act is a framework law. It does not list ten concrete risk-management measures the way NIS2 Article 21 does. It states that the undertaking shall maintain a level of security appropriate to the risk. In practice, the content of "appropriate to the risk" is drawn from the Basic Principles for ICT Security published by the Norwegian National Security Authority (NSM), sector regulations such as the Power Supply Preparedness Regulations (kraftberedskapsforskriften, FOR-2012-12-07-1157), and the standards the undertaking has itself committed to.

On sector supervision: on 19 December 2025 the Norwegian Maritime Authority was designated the sector supervisory authority under the Digital Security Act for shipping companies. NSM is the national point of contact and the national response environment, and supervises sectors without their own designated supervisory authority.

Consequence 2: NIS2 is coming, and Article 21(i) and (j) are the two points that will require the most work

Once NIS2 is eventually implemented, a far more explicit set of requirements will follow. Article 21 lists minimum measures, and two of them bear directly on identity management:

• Point (i): personnel security, access control policies and asset management.
• Point (j): the use of multi-factor authentication or continuous authentication, secured voice, video and text communication, and secured emergency communication systems.

In addition, Article 20 requires the management body to approve the risk-management measures and to oversee their implementation, with personal liability for breaches of Article 21. Article 23 introduces a three-stage notification timeline: an early warning within 24 hours, an incident notification within 72 hours, and a final report no later than one month after the incident notification. Article 34 sets fine caps of EUR 10 million or 2% of global annual turnover for essential entities, and EUR 7 million or 1.4% for important entities — whichever amount is higher applies.

Note on sourcing: the article content above is reproduced from a secondary source that reproduces the directive text. For formal use, the wording should be checked against the EUR-Lex version of Directive (EU) 2022/2555.

The combination of Article 20 and Article 21(i) is what makes this something other than yet another compliance exercise. Management must approve the access control regime and can be held liable for it. Having a policy is then not enough. You must be able to demonstrate that the policy is actually enforced in the system.

Consequence 3: The 24-hour deadline is an identity challenge, not a communications challenge

Look at NIS2 Article 23 from an operational perspective. Within 24 hours, an early warning must be sent. Within 72 hours, an incident notification must be in place, with a preliminary assessment of severity and impact.

For an identity-related incident — a compromised administrator account, a guest user who has done something unexpected, a service account that suddenly starts performing bulk operations — the three questions that must be answered within 72 hours are:

1. What was actually changed in the directory during the period in question?

2. Who approved each of these changes, and on what grounds?

3. Which of the changes were legitimate, and which were not?

In an organisation where changes are carried out by people with standing administrator privileges, question 1 is answered by exporting audit logs from Entra, question 2 by searching the case-handling system and email, and question 3 by phoning people. Experience shows this takes days, not hours, and the result is incomplete.

In an organisation where every change is an order with the justification, the approver and the execution result in the same record, questions 1 to 3 are a single search. The difference is not marginal — it is the difference between the 72-hour deadline being realistic or not.

Note that the 24- and 72-hour deadlines in this form do not apply in Norway today. The Digital Security Act operates with notification "without undue delay" (author's translation from the Norwegian). The exact deadlines in the Digital Security Regulations should be checked against the regulatory text. But the operational capability the deadlines presuppose cannot be built at the moment the deadline arrives.

What to build now, that holds up regardless of how the implementation turns out

It is tempting to wait for the Norwegian NIS2 law before investing. That is wrong, for three reasons.

First, the requirements overlap with regulations that already apply. An entity in the Norwegian power supply contingency organisation (KBO) is already bound by Chapters 6 and 7 of the Preparedness Regulations. A petroleum undertaking is already bound by the Management Regulations' requirements for barriers and nonconformity handling. An undertaking subject to the National Security Act (sikkerhetsloven) already has requirements for authorisation and an overview of authorised personnel under Chapter 12 of the Undertakings Security Regulations (virksomhetsikkerhetsforskriften). Access management that meets these standards also meets the standard of NIS2 Article 21(i).

Second, the technical prerequisites are independent of the exact wording of the regulations:

• A single authoritative, searchable overview of identities, groups, devices, licences and access across tenants.
• A documented process for the entire lifecycle — creation, change, deactivation — that is actually the process being used, not the one that is written down.
• A coherent audit trail where decision and execution are the same record.
• The absence of standing privileges held by people.

All four are explicitly called for in NSM's Basic Principles 2.6.1 to 2.6.3, which apply now.

Third, the management liability in Article 20 is a documentation challenge, not a technology challenge. A board cannot approve something it cannot see. Being able to produce a report showing how many privileged accounts exist, how many changes have been made in the last quarter, who approved them, and how many requests were rejected — that is what "approve and oversee" actually requires in practice.

Where Entra Logic fits in

Entra Logic does not solve compliance. No product does. What Entra Logic does is change where the documentation comes from: from being something produced after the fact for an audit, to being a by-product of how the work is actually done.

Concretely: every change in Entra ID goes through a request–approve–execute flow. The business justification, the approval decision and the technical execution are a single record. No human needs standing administrator privileges. The synchronisation service maintains a continuously updated, searchable copy of the estate, so that the question "what did it look like on 3 March at 14:00" can be answered.

What Entra Logic does not do, and does not claim to do: recertification campaigns, access attestation, and segregation-of-duties analysis. If the undertaking needs that, it is a different category of product — or Microsoft Entra ID Governance, which has access reviews and entitlement management built in, for a separate licence add-on.

Checklist before the next management review

• Do you know which law the undertaking is actually subject to today, and who the sector supervisory authority is?
• Can you produce a complete list of privileged accounts in the tenant in under an hour?
• Can you document the justification and approver for an arbitrary directory change from last quarter?
• Has management actually approved the access control regime, with it minuted, or has it merely been briefed on it?

Sources

• Act on Digital Security (LOV-2023-12-20-108), in force from 01.10.2025 — https://lovdata.no/dokument/NL/lov/2023-12-20-108
• NSM on the new Digital Security Act — https://nsm.no/aktuelt/ny-digitalsikkerhetslov-i-norge
• NSM, incident notification under the Digital Security Act — https://nsm.no/regelverk-og-hjelp/digitalsikkerhetsloven-og-forskriften/varsle-om-hendelser-etter-digitalsikkerhetsloven
• Norwegian Maritime Authority designated as sector supervisory authority (19.12.2025) — https://www.sdir.no/nyheter/sjofartsdirektoratet-er-utpekt-myndighet-for-sektortilsyn-med-digitalsikkerhetsloven-for-rederier/
• Storting/EU-EEA news on the cybersecurity package (28.01.2026) — https://www.stortinget.no/no/Hva-skjer-pa-Stortinget/EU-EOS-informasjon/EU-EOS-nytt/2026/eueos-nytt—28.-januar-2026/cybersikkerhetspakke-lagt-frem/
• Europalov, status of NIS2 in the EEA — https://europalov.no/rettsakt/felles-sikkerhetsniva-for-digital-sikkerhet-nis-2/id-28655
• NIS2 Articles 21, 23 and 34 (secondary reproduction, should be checked against EUR-Lex) — https://www.nis-2-directive.com/NIS_2_Directive_Article_21.html
• NSM, Basic Principles for ICT Security v2.1 — https://nsm.no/getfile.php/1313975-1717589722/NSM/Filer/Dokumenter/Veiledere/NSMs%20Grunnprinsipper%20for%20IKT-sikkerhet%20v2.1.pdf