Norway software supply chain and AI security rules: a 90-day plan

If you build, buy or run software in Norway, three national laws already bite: the Digital Security Act (digitalsikkerhetsloven), in force since 1 October 2025 with a 24 hour first notice for serious incidents, the Security Act (sikkerhetsloven) for organisations that handle national security interests, and the Norwegian DORA Act, which has applied to supervised financial firms since 1 July 2025. Norway is in the EEA, not the EU, so the GDPR and DORA apply through the EEA Agreement, while NIS2, the Cyber Resilience Act and the AI Act are still under EEA scrutiny and are not yet Norwegian law, even though Norwegian makers selling into the EU must meet the last two anyway.

This guide takes each regime from its primary source, names the supervisor, sets out what each asks of software and open source, and ends with a 30/60/90-day plan that works with any tooling. It is a practical reading of public texts as of 25 October 2026, not legal advice.

Key takeaways

• The Digital Security Act is Norway's NIS law, and it implements NIS1, not NIS2. It has applied since 1 October 2025 to essential services in seven sectors and to some digital service providers.
• NSM sets hard clocks: a first notice within 24 hours, an update within 72 hours and a report within one month, to the sector supervisor with NSM in copy, even when the incident is at a supplier.
• DORA is Norwegian law through EEA Joint Committee Decision No. 040/2025, in force from 1 July 2025 and supervised by Finanstilsynet.
• NIS2, the CRA and the AI Act are still under EEA scrutiny, but Norwegian makers selling into the EU are caught by the EU text directly.
• NSM's Basic Principles for ICT Security 2.1 are advice, not law, yet they are the yardstick: 1.2 map devices and software, 2.1 security in procurement and development, 3.1 remove known vulnerabilities.
• Safeguard capabilities in this guide, all generally available (GA): the Compliance and GRC suite with a Norway NSM framework page, SBOM generation and analysis, SCA with deep transitive dependency scanning, vulnerability management with EPSS and KEV, reachability analysis, policies and gates, TPRM with SBOM requests, CSAF and VEX upload, license compliance, autonomous remediation (ships off), AI-BOM discovery, AI Gateway, MCP Guardrail, agent identity, Trust Center, the local runner, Zero AI mode, bring your own model, and on-prem and air-gapped deployment.

Who this applies to in Norway

Norwegian rules split along three lines: whether you deliver an essential service, whether you touch national security, and whether you are a supervised financial firm. Many organisations sit on more than one.

The Digital Security Act (section 2) covers providers of essential services (samfunnsviktige tjenester) in energy, transport, health, water supply, banking, financial market infrastructure and digital infrastructure, and providers of online marketplaces, search engines and cloud services. Its regulation lists the categories; Finanstilsynet says the finance categories in section 1, points 27 and 28, catch systemically important banks and significant market infrastructure. The Security Act applies to public bodies and classified suppliers (section 1-2) and to any organisation a ministry brings in under section 1-3. The DORA Act covers most firms Finanstilsynet supervises, and reaches their ICT providers through contracts and registers. The Personal Data Act (personopplysningsloven, LOV-2018-06-15-38) makes the GDPR Norwegian law under Datatilsynet. And any Norwegian maker selling products or AI systems in the EU meets the CRA and AI Act there.

Norway is in the EEA, not the EU: which EU acts apply

Norway takes EU single market law through the EEA Agreement. An EU act becomes binding in Norway only after the EEA Joint Committee adds it to an annex of the Agreement and Norway completes any constitutional steps, and then it is written into Norwegian law. Until then, it is not Norwegian law, even if the EU has marked it as EEA relevant. EFTA's EEA-Lex database is the primary record of where each act stands. As of 25 October 2026 it shows:

Two practical points follow. First, Norway's NIS law and its reporting clocks are national rules today. The Digital Security Act implements the first NIS Directive, yet NSM describes 24 hour, 72 hour and one month deadlines that look much like NIS2's, so operators already work to NIS2-style clocks. Second, the EEA gap does not shelter exporters. The CRA and AI Act regulate products and systems placed on the EU market, so a Norwegian software company selling to EU customers must plan for them on EU dates.

The rules, regulator by regulator

The Digital Security Act (digitalsikkerhetsloven, LOV-2023-12-20-108)

The Act on Digital Security was adopted on 20 December 2023 and entered into force on 1 October 2025, together with its regulation (digitalsikkerhetsforskriften). Lovdata lists it under the EEA Agreement as implementing Directive (EU) 2016/1148, the first NIS Directive. It is administered by the Ministry of Justice and Public Security.

What the Act requires:

• Section 7: risk assessment of network and information systems, and appropriate, proportionate technical and organisational measures to prevent, detect and limit incidents.
• Section 8: notice "without undue delay" (uten unødig opphold), despite confidentiality duties, of incidents that significantly affect delivery of the service. Sections 10 and 11 set the same duties for digital service providers.
• Section 5: sections 7, 8, 10 and 11 yield to other law with equal or stricter rules, which is why Finanstilsynet tells financial firms in scope to follow DORA.
• Sections 13 to 18: designated supervisors may demand information and access, order corrections, and impose coercive fines and administrative fines (overtredelsesgebyr) for intentional or negligent breaches, with a five year limitation period. Fine levels are set by regulation.

The reporting clocks. The regulation's section 5, as Finanstilsynet summarises it, requires essential service providers to report "as soon as possible" (snarest) to NSM and their supervisor. NSM's Risiko 2026 report (6 February 2026) spells out the deadlines: a first notice within 24 hours of discovery, an update within 72 hours, and an incident report within one month of the first notice. NSM says the deadlines are absolute and apply even if the incident happens at a partner or subcontractor, that each provider notifies its own sector supervisor with a copy to NSM, and that essential service providers must register with both. It also stresses that the Act covers operational technology.

Who supervises: sector authorities and NSM

Supervision is sectoral. Each ministry designates its sector's supervisor; for finance, Finanstilsynet under section 21 of the regulation, with Finanstilsynet and Nordic Financial CERT as sector response bodies under section 16. NSM (Nasjonal sikkerhetsmyndighet, the National Security Authority) is the national contact point that receives copies of every notice and publishes the reporting form. For a software supplier, that means your customer's supervisor can ask how your product is managed, and the clock runs even when the incident sits in your code.

NSM's Basic Principles for ICT Security (grunnprinsipper for IKT-sikkerhet) 2.1

NSM's Basic Principles for ICT Security are recommendations, not legal requirements. Version 2.1 was published on 4 June 2024 and updated on 28 October 2024. NSM says organisations should assess and adapt them, and that the Security Act sets stricter requirements for those it covers. They are still the benchmark most Norwegian auditors, supervisors and public buyers reach for, and they map neatly onto the Act's "appropriate and proportionate" measures.

There are 21 principles in four categories. The ones that touch software supply chain most directly:

Use NSM's own numbering in your control matrix; tools and consultancies sometimes renumber the principles.

The Security Act (sikkerhetsloven, LOV-2018-06-01-24)

The Act on National Security has applied since 1 January 2019. It protects national security interests and aims to prevent, detect and counter security threatening activity (sikkerhetstruende virksomhet). For organisations in scope:

• Chapter 4: the head of the organisation owns preventive security (4-1), with regular risk assessment including a map of dependencies (4-2), proportionate measures and exercises (4-3) and documentation (4-4). Section 4-5 requires immediate (straks) notice to the security authority of security threatening activity or serious breaches.
• Chapter 6: protection-worthy (skjermingsverdige) systems must be kept at an adequate level (6-2), approved before use where they handle classified information (6-3), and monitored continuously, with data kept up to five years (6-4).
• Chapter 9: a security agreement before a classified procurement starts (9-2), and an assessment of procurements touching protection-worthy systems, with significant risk notified to the ministry or the security authority (9-4).
• Chapter 11: coercive fines, administrative fines and criminal penalties.

For software, chapter 6 means showing what runs on a protected system before approval, and chapter 9 makes a cloud or software supplier a security decision. Risiko 2026 adds advice on supply chains: assess risk before procurement, write security into tender terms and contracts, keep redundancy, and limit the number of links in the chain.

DORA and Finanstilsynet

The Act on Digital Operational Resilience in the Financial Sector (lov om digital operasjonell motstandsdyktighet i finanssektoren, the DORA Act) was sanctioned on 27 May 2025 and entered into force on 1 July 2025, with the DORA Regulation (DORA-forskriften). It implements Regulation (EU) 2022/2554 and Directive (EU) 2022/2556. Finanstilsynet notes that DORA has applied in the EU since 17 January 2025, that the EU's level 2 rules are implemented through section 3 of the DORA Regulation, and that for many supervised firms the DORA Act replaced the ICT Regulation (IKT-forskriften) on 1 July 2025.

The articles that matter most for software supply chain (references from our own reading of the Regulation; EUR-Lex did not load during our checks):

• Articles 8 and 9: identify and classify ICT assets and their dependencies, and protect their integrity.
• Articles 17 to 19: detect, classify and report major ICT related incidents. The EU incident reporting standards set an initial notification within 4 hours of classifying an incident as major and no later than 24 hours after awareness, an intermediate report within 72 hours, and a final report within one month.
• Article 26: Finanstilsynet confirms threat-led penetration testing at least every three years for most entities.
• Articles 28 to 30: a register of information on all ICT third-party arrangements (Article 28(3)), exit strategies, and mandatory contract terms.

Finanstilsynet's Risk and Vulnerability Analysis (ROS) 2026 shows how it reads these duties: firms use the register actively, supplier risk is rated high, oversight of subcontractors is weak, and supplier audit reports must not replace a firm's own checks.

GDPR and Datatilsynet

The Personal Data Act took effect on 20 July 2018, the day the GDPR entered into force in the EEA under Joint Committee Decision No. 154/2018. Datatilsynet supervises (section 20). The articles that come up in software audits are Article 25 (data protection by design), Article 28 (processors), Article 32 (security appropriate to the risk), Article 33 (breach notice within 72 hours where feasible) and Chapter V (transfers outside the EEA). Transfers to EU countries are not third country transfers for Norway.

NIS2: not yet in Norwegian law

EEA-Lex lists NIS2 (Directive (EU) 2022/2555) as under scrutiny by the EEA EFTA States, with no Joint Committee Decision. We could not confirm a current Norwegian bill or date on a primary source. Treat NIS2 as a guide to the next baseline: Article 21(2)(d) requires supply chain security and 21(2)(e) security in acquisition, development and maintenance, including vulnerability handling and disclosure. Norwegian groups with EU subsidiaries are under NIS2 there today.

The EU Cyber Resilience Act for Norwegian makers

The CRA (Regulation (EU) 2024/2847) is under EEA scrutiny, so it is not Norwegian law. In the EU, under Article 71, the notified body rules applied from 11 June 2026, Article 14 reporting from 11 September 2026, and everything else from 11 December 2027. For a Norwegian maker selling into the EU:

• Article 14 is live: report actively exploited vulnerabilities and severe incidents through the single reporting platform, with an early warning within 24 hours, a notification within 72 hours and a final report later.
• From 11 December 2027: the Annex I essential requirements, due diligence on third-party components including open source (Article 13), and an SBOM in a machine-readable format covering at least the top-level dependencies (Annex I Part II(1)).
• Updates: vulnerability handling for the support period, with security updates free of charge.

(CRA references also come from our own reading of the Regulation.)

The EU AI Act and Nkom

EEA-Lex lists the AI Act (Regulation (EU) 2024/1689) as under scrutiny, with an EU compliance date of 2 August 2026. Under Article 113 as adopted, prohibitions and AI literacy applied in the EU from 2 February 2025, general purpose AI model rules from 2 August 2025, most other rules from 2 August 2026, and Article 6(1) from 2 August 2027. The EU has proposed adjusting some high-risk dates, so check the current text.

The Government has named Nkom (Nasjonal kommunikasjonsmyndighet) as the coordinating market surveillance authority and single point of contact. Nkom's page of 24 March 2026 says sector authorities are expected to supervise AI in products they already oversee and that the national structure is not yet fully decided. The Norwegian AI law (KI-loven) went to consultation in 2025; we could not confirm its adoption, so treat it as pending. Finanstilsynet's ROS 2026 adds a warning about "shadow AI" (skygge-KI), generative tools used outside governance, and notes that the time from disclosure to exploitation of vulnerabilities is much shorter than before.

What the rules ask of software and open source

Strip away the legal form and the Norwegian rules ask for the same handful of capabilities. The table maps each to the evidence a supervisor, auditor or customer usually asks for.

Three points recur across Norwegian supervisors. Inventory comes first, because none of the clocks can be met without it. Suppliers are inside your perimeter for reporting purposes, so you need their component data, not only their certificates. And supervisors want evidence that is dated and repeatable, not a spreadsheet assembled for the audit.

Real public incidents in or affecting Norway

Only incidents from the last three years with official or primary reporting are listed here.

Cyber operation against a dam in Bremanger (2025). NSM's Risiko 2026 report says that one of the operational technology systems at a dam facility in Bremanger was hit by a cyber operation in 2025. According to PST, as NSM reports it, a pro-Russian hacktivist group gained remote access to a control panel and changed settings, leaving the dam's valves open for four hours and releasing about 500 litres of water per second. NSM describes the physical and economic consequences as apparently limited. In May 2025 NSM had publicly urged Norwegian organisations to strengthen their security after activity it observed against OT systems, and it shared the advice openly so that organisations outside the Security Act could act too. The lesson NSM draws is general: the Digital Security Act covers OT as well as IT, and OT security belongs in the same programme.

ICT incidents in the financial sector (2025). Finanstilsynet's ROS 2026 reports 313 ICT incidents reported by financial firms in 2025: 299 operational and 14 security incidents, slightly fewer than in 2024. Of these, 115 were reported after DORA took effect on 1 July 2025. None affected financial stability. Finanstilsynet notes that a network change at a global cloud provider reduced availability for some banks, links many incidents to weak change management, and singles out incidents that affect data integrity as especially serious.

The national risk picture (published February 2026). NSM's Risiko 2026 says cyber operations still hit broadly, that ransomware is among the most common attack methods against Norwegian organisations, that phishing increasingly defeats multi-factor authentication, and that threat actors who get into supply chains early could, for example, place hidden backdoors in digital components to use later. It recommends that organisations avoid depending on one supplier or one country for critical functions.

We have not drawn conclusions about what any affected organisation should have done beyond what these sources say.

The personas who own the problem

The CISO. Owns the Digital Security Act and Security Act duties and the board story. Needs one view of systems and suppliers, a tested 24 hour notice path that works when the incident is at a supplier, and a defensible answer when a supervisor asks why measures are proportionate. Triggers: registration as an essential service, an inspection letter, the annual Risiko briefing, or an incident.

The head of AppSec or VP of Engineering. Owns NSM principles 2.1, 2.10 and 3.1 in practice. Needs SBOMs on every build, a backlog ranked by real risk, and gates that do not stall releases. Triggers: a security questionnaire, a Security Act system approval, or an EU customer asking about CRA readiness.

GRC and regulatory affairs. Owns the control matrix across the Digital Security Act, NSM principles, DORA and the GDPR, and tracks NIS2, the CRA and the AI Act through EEA scrutiny. Needs dated evidence per requirement. Triggers: the DORA register cycle, a Finanstilsynet review, or a new EEA Joint Committee decision.

Procurement and vendor risk. Owns Security Act chapter 9 assessments and DORA Article 28 to 30 contracts. Needs vendor SBOMs and vulnerability statements, a record of follow-ups, and subcontractor visibility. Triggers: a new critical supplier, a renewal, or a supplier incident.

The DPO. Owns GDPR Articles 25, 28, 32 and 33 and transfers. Needs to know which components and processors sit behind each system holding personal data, so a breach can be scoped inside 72 hours.

The product security lead at a software maker. Owns CRA readiness for EU sales: Article 14 reporting now, SBOMs and vulnerability handling from 11 December 2027. Needs a disclosure process, exploitability statements and component data for every supported version.

A practical 30/60/90-day plan

The plan works with whatever tools you already use. Adjust the order if a supervisor's letter sets a different priority.

Days 1 to 30: scope, inventory and ownership

1. Decide which laws apply. Check the Digital Security Regulation's categories, any ministry decision under Security Act section 1-3, Finanstilsynet supervision, and EU market exposure. Record who signed it off.
2. Register and name owners. Essential service providers register with NSM and their sector supervisor. Name one owner per law and per critical system.
3. Build the software inventory. An SBOM in SPDX or CycloneDX for every production system and product, with versions, suppliers and integrity hashes, starting with essential services and protected systems.
4. List suppliers and subcontractors for each critical system, with hosting location and contract owner. Financial firms reconcile this with the DORA register.
5. Write the notice runbook, with supplier incidents included explicitly.

A simple decision table for the runbook:

Days 31 to 60: vulnerability handling and suppliers

1. Scan continuously. Match SBOMs against vulnerability data, add EPSS and the CISA KEV catalogue, and rank by reachability.
2. Set written fix targets by risk, for example known exploited and reachable within days, critical within weeks.
3. Gate the pipeline. Block known exploited or critical vulnerabilities and banned licenses, warn on lower risk, and record exceptions with an approver, a reason and an expiry date (NSM principle 2.10).
4. Ask suppliers for SBOMs with a format, required fields and a deadline, starting with suppliers to protected systems.
5. Check contracts against DORA Article 30, Security Act section 9-2 and GDPR Article 28.
6. Run a tabletop in which the incident starts at a supplier, and time how long it takes to name affected systems.

Days 61 to 90: evidence, AI and residency

1. Collect evidence on a schedule: dated SBOMs, scans, gate outcomes, exceptions and supplier responses, mapped to NSM principles, the Act and DORA articles.
2. Publish exploitability statements (VEX or CSAF) for widely reported vulnerabilities in your products.
3. Inventory AI: models, AI services, agents and what they can reach, with an approved model list and logged agent access.
4. Settle residency: document where code, SBOMs and findings are processed, and decide what must stay on premises.
5. Track EEA milestones for NIS2, the CRA and the AI Act on EEA-Lex, and brief the board on one page.

Common mistakes

• Treating Norway as an EU member state. NIS2, the CRA and the AI Act are not Norwegian law yet; their EU dates still bind EU sales.
• Assuming the Digital Security Act is NIS2. It implements NIS1.
• Leaving suppliers out of the notice runbook. NSM says the clocks apply when the incident is at a subcontractor.
• Relying on supplier reports alone, which Finanstilsynet warns against.
• Building the inventory once. Last quarter's SBOM cannot answer a 24 hour question about this week's release.
• Ignoring OT and AI. The Act covers operational technology, and shadow AI is a gap now.

How Safeguard does this

Everything in the plan above works without Safeguard. This section shows how the same steps run in Safeguard, using only what Safeguard's documentation and offering describe. Every capability named here is generally available (GA).

1. Switch on the Norway and EU framework pages. In the Compliance and GRC suite (GA), the Norway NSM Basic Principles framework is on unless you switch it off under Compliance › Manage, as are EU DORA, EU NIS2, the EU Cyber Resilience Act, the EU AI Act and the GDPR. The NSM page lists the checks a scan decides: mapping devices and software, a versioned software overview, knowing the suppliers behind components for procurement and development, keeping software updated without floating versions, integrity hashes over deployed components, and identifying affected components quickly for incident response. The page ties these to NSM principles 1.2 and 2.1 and to the Protect, Detect and Respond categories. Safeguard's own catalogue control IDs on that page are Safeguard's labels, not NSM's numbering, so map them to NSM's 2.1 principle numbers in your own matrix. The NSM page also offers policy templates, including an incident response and breach notification procedure.
2. Generate SBOMs on every scan. SBOM generation and analysis (GA) produces SPDX and CycloneDX. SCA with deep transitive dependency scanning (GA) builds the full component inventory with versions and suppliers, which is the evidence for NSM principle 1.2 and DORA Article 8.
3. Scan where your code lives. The local runner (GA) is part of the Safeguard CLI (GA). As the docs show, you install it with the one-line installer, run safeguard, type /login, approve the session in your browser, and the machine starts polling for work. It runs each scan locally and uploads only the SBOM and findings, never the source code, and all traffic is outbound HTTPS that the runner opens. For headless use the docs show:

# Start without the terminal UI and serve assistant turns for this workspace
safeguard runner start --workspace ./path/to/repo
# Is it running, and what is it doing
safeguard runner status
# Drain in-flight work and stop
safeguard runner stop

On networks that forbid held connections, the docs show --poll-wait 0 to poll at a fixed interval instead. These commands are quoted from the docs and were not run for this article. 4. Prioritise what is exploited and reachable. Vulnerability management (GA) matches components against advisories with EPSS and CISA KEV context. Reachability analysis (GA) ranks the vulnerable code paths your application actually calls first, which is how a small team meets NSM principle 3.1 without drowning in findings. 5. Gate releases and keep exceptions on record. Policies and gates (GA) are set under Settings › Policies with a visual builder or YAML, on conditions such as severity, CVSS, EPSS, license, component age and maintenance status. Each policy's action is Block (the gate fails), Warn (the gate passes with a warning) or Notify (the gate passes and a notification is sent). Exceptions are requested with a business justification and an expiry date, approvers decide, and the audit trail is recorded. With policy outcomes switched on for your workspace, the docs show a CI job failing when a gate fails:

safeguard ci scan --wait --fail-on-gate <gate>

6. Collect SBOMs from suppliers. TPRM (GA) keeps the vendor directory. SBOM requests go out singly or in bulk from a template that sets SPDX or CycloneDX format, required fields and a deadline. Status runs from Sent to Validated, reminders go out 7 days before the deadline, at the deadline, and as an escalation 7 days after, and each submission is checked for format and completeness and then scanned. That is the evidence behind a DORA register entry, a Security Act chapter 9 assessment or NSM principle 2.1.
7. State what is and is not affected. CSAF and VEX upload (GA) holds exploitability statements you can share when a customer, a supervisor or NSM asks whether a vulnerability affects you.
8. Keep licenses in check. License compliance (GA) applies SPDX license policy and attribution across the inventory, which matters for CRA technical documentation and customer contracts.
9. Fix with a human in charge. Autonomous remediation (GA) can open tested, policy gated fix pull requests, one at a time or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own.
10. Inventory and govern AI. AI-BOM discovery (GA) inventories AI assets. AI Gateway (GA) places a guardrail proxy in front of model traffic for prompt injection, jailbreak and PII egress. MCP Guardrail (GA) generates guardrail proxy URLs for MCP servers, and agent identity (GA) tracks which agent holds what access, at what level. These cover the AI inventory step in the plan and the shadow AI risk.
11. Share posture with customers. Trust Center (GA), managed under Compliance › Trust Center, publishes your frameworks, live control status, policies, sub-processors and shared documents such as SBOMs and VEX, and nothing goes live until you publish it.
12. Choose where it runs. Safeguard's SaaS is multi-region across US, EU and Gov regions; there is no Norway-specific region. For residency and Security Act questions, the GA options are private VPC or dedicated tenancy, full on-prem, and fully air-gapped with the AI models running inside your environment and signed offline snapshot delivery, where no component inside the perimeter calls outbound. Zero AI mode (GA) runs the whole platform deterministically with no LLM in the loop, and bring your own model (GA) suits teams with an approved model list. Safeguard states that customer code, SBOMs and telemetry are not used to train shared models.

Safeguard's posture wording is limited to what its Trust Center says: SOC 2 Type II audit in progress, and designed for FedRAMP High. Safeguard does not claim any Norwegian or EU certification, approval or listing.

What Safeguard does not do

• It does not make you compliant. It helps you produce and keep evidence. Whether you provide an essential service, whether an incident is significant, and whether a supplier is acceptable under the Security Act remain decisions for you and your supervisors.
• It does not notify NSM, Finanstilsynet, Datatilsynet or the security authority for you. It helps you name affected systems and versions quickly; filing the notice is your team's job.
• It does not approve protected systems or sign security agreements. On-prem, air-gapped and local runner options keep processing in an environment you control, but the Security Act approval and chapter 9 decisions stay with you and the authorities.
• It does not write contracts or legal analysis, such as DORA Article 30 clauses, GDPR Article 28 terms or a transfer assessment.
• It does not fix vendor appliances, OT controllers or hosted services. Those fixes come from the vendor; Safeguard helps you track which ones you depend on.
• It does not replace incident response. Containment, forensics, police reports and communication stay with you.
• It does not track EEA incorporation. Watch EEA-Lex and the ministries for NIS2, CRA and AI Act milestones.

FAQ

Is NIS2 in force in Norway?

No. As of 25 October 2026, EFTA's EEA-Lex lists NIS2 as under scrutiny by the EEA EFTA States, with no Joint Committee Decision. Norway's Digital Security Act, in force since 1 October 2025, implements the first NIS Directive. Norwegian groups with EU subsidiaries are under NIS2 in those member states.

What is the Digital Security Act (digitalsikkerhetsloven)?

Norway's NIS law, LOV-2023-12-20-108, in force since 1 October 2025. It requires risk assessment and proportionate measures (section 7) and incident notice (section 8), with corrective orders and fines (sections 15 to 17).

How fast must a Norwegian essential service report an incident?

NSM's Risiko 2026 report says a first notice within 24 hours of discovery, an update within 72 hours and an incident report within one month of the first notice. Notices go to the sector supervisor with a copy to NSM, and the deadlines apply even when the incident happens at a supplier or subcontractor.

Does DORA apply in Norway?

Yes. DORA was incorporated into the EEA Agreement by Decision No. 040/2025 and applies in Norway through the DORA Act and DORA Regulation from 1 July 2025. Finanstilsynet supervises, and for many firms DORA replaced the ICT Regulation.

Are NSM's Basic Principles for ICT Security mandatory?

No. NSM presents them as recommendations to assess and adapt, though they are the usual benchmark for appropriate measures. The Security Act sets stricter requirements for organisations it covers.

Does the EU Cyber Resilience Act apply to Norwegian software companies?

Not as Norwegian law yet; EEA-Lex lists it as under scrutiny. But it applies to products placed on the EU market, so a Norwegian maker selling into the EU has had to meet Article 14 reporting since 11 September 2026 and must meet the remaining obligations from 11 December 2027.

Who will supervise AI in Norway?

The Government has named Nkom as the coordinating market surveillance authority and single point of contact for the AI Act, with sector authorities expected to supervise AI in products they already oversee. The Norwegian AI law that would give this legal effect was still pending when we checked.

Does the Security Act affect cloud and software procurement?

Yes, for organisations in scope: a security agreement before a classified procurement (section 9-2), an assessment of procurements touching protection-worthy systems (9-4), and approval of protected systems before use (6-3).

Can a Norwegian organisation use Safeguard without sending source code abroad?

Yes. The local runner scans on your own machine and uploads only the SBOM and findings, never source code. Safeguard can also run in a private VPC, fully on-prem or fully air-gapped with the AI models inside your environment, and Zero AI mode runs with no LLM in the loop. There is no Norway-specific SaaS region.

The Norwegian rules above all come down to one question asked under time pressure: which of your systems and suppliers carry the vulnerable component, and how soon will it be fixed. The section below describes how Safeguard closes that gap when a fix exists and when it does not.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix a vulnerable dependency in a repository. It reads the finding and the advisory, asks before any command that changes something, edits the manifest, runs the install and the tests with your approval, prints a summary and pushes nothing. For a Norwegian team working to NSM principle 3.1, or a maker with a CRA report due, it shows a fix moving with a human approving each change.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. This is the option for organisations under the Security Act and financial firms that will not let source code leave their network.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. For teams building an AI inventory and controlling agent access ahead of the AI Act, it shows what scoped agent access looks like in practice.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Lovdata: Digital Security Act (digitalsikkerhetsloven), LOV-2023-12-20-108 (Norwegian)
• Lovdata: Security Act (sikkerhetsloven), LOV-2018-06-01-24 (Norwegian)
• Lovdata: Personal Data Act (personopplysningsloven), LOV-2018-06-15-38 (Norwegian)
• NSM: Basic Principles for ICT Security 2.1 (Norwegian)
• NSM: Risiko 2026 (Norwegian)
• NSM: Risiko 2026 report, PDF (Norwegian)
• Finanstilsynet: The DORA Act enters into force on 1 July (Norwegian)
• Finanstilsynet: DORA in Norway (Norwegian)
• Finanstilsynet: The Digital Security Act in the financial sector (Norwegian)
• Finanstilsynet: Risk and Vulnerability Analysis 2026 (Norwegian)
• Nkom: Who enforces the AI Act in Norway (Norwegian)
• EFTA EEA-Lex: GDPR, Regulation (EU) 2016/679
• EFTA EEA-Lex: DORA, Regulation (EU) 2022/2554
• EFTA EEA-Lex: NIS2, Directive (EU) 2022/2555
• EFTA EEA-Lex: Cyber Resilience Act, Regulation (EU) 2024/2847
• EFTA EEA-Lex: AI Act, Regulation (EU) 2024/1689
• Safeguard docs: Norway NSM Basic Principles framework
• Safeguard docs: EU DORA framework
• Safeguard docs: EU NIS2 framework
• Safeguard docs: EU Cyber Resilience Act framework
• Safeguard docs: EU AI Act framework
• Safeguard docs: GDPR framework
• Safeguard docs: Local Runner
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: Trust Center setup
• Safeguard docs: Air-Gapped Deployment

Related reading: NIS2 supply chain evidence for EU operators, SBOM requirements for financial services under DORA, and EU Cyber Resilience Act SBOM obligations.

To try the flows above, download Safeguard and read the Safeguard documentation.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.