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

If you build, buy or run software in Denmark, the rules that reach your code and your suppliers are already in force. The Danish NIS 2 Act (NIS 2-loven) has applied since 1 July 2025, DORA has applied to Danish banks, insurers and pension funds since 17 January 2025, the EU Cyber Resilience Act reporting duty started on 11 September 2026, GDPR is enforced through the Danish Data Protection Act, and Denmark's supplementary AI Act law has applied since 2 August 2025. On 24 September 2026 the Danish Resilience Agency raised the national threat level for destructive cyberattacks from MEDIUM to HIGH, so the question is no longer whether these rules apply but whether you can prove you meet them.

This guide takes each regime from its primary source, names the supervisor, sets out what it 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, not legal advice.

Key takeaways

• NIS 2 is Danish law today. Act No. 434 of 6 May 2025 entered into force on 1 July 2025. Entities already in scope had to register by 1 October 2025, and significant incidents follow a 24 hour, 72 hour and one month reporting sequence.
• Supervision is split by sector. Executive Order No. 620 of 2 June 2025 names the competent authority for each sector, from the Danish Resilience Agency (SAMSIK) for municipalities and central government to the Agency for Digital Government for cloud and managed service providers.
• The Danish Defence Intelligence Service (FE) is the national CSIRT for NIS 2 incident reports, which are filed through virk.dk. The old cfcs.dk address now forwards to SAMSIK.
• Finance runs on DORA. Finanstilsynet supervises it, collects the register of ICT third-party providers every year, and has designated shared banking IT and payment providers as operators of financial digital infrastructure.
• The CRA clock is running. Manufacturers have reported actively exploited vulnerabilities and severe incidents since 11 September 2026. The full product rules, including the SBOM duty, apply from 11 December 2027.
• Datatilsynet does not fine directly. It reports cases to the police with a recommended fine, and courts decide.
• AI rules are in place nationally. Act No. 467 of 14 May 2025 names three AI Act authorities. High-risk obligations start on 2 December 2027 (Annex III) and 2 August 2028 (Annex I).
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, SCA and vulnerability management with EPSS and KEV, reachability analysis, policies and gates, the Compliance and GRC suite with framework pages for NIS2, DORA, the EU CRA and the Denmark Data Protection Act 2018, TPRM SBOM requests, CSAF and VEX upload, Trust Center, AI-BOM discovery, AI Gateway, MCP Guardrail, agent identity, autonomous remediation (ships switched off), the local runner, Zero AI mode, and private VPC, on-prem and air-gapped deployment.

Who this applies to in Denmark

Denmark took a sector model for NIS 2. One cross-sector act sets the duties, and an executive order hands supervision to the authority that already knows each sector. Energy, telecoms and finance keep their own legal tracks.

Public administration. Central government bodies, the regions and the municipalities are inside the NIS 2 Act. SAMSIK supervises municipalities and central government; the Danish Health Data Authority (Sundhedsdatastyrelsen) supervises the regions. Suppliers feel these rules through tenders, data processing agreements and contract clauses.

Critical infrastructure operators and their suppliers. Health, water, wastewater, transport, maritime, space, research, food, chemicals, digital infrastructure and parts of manufacturing are in scope under Annexes 1 and 2 of the act. Cloud, data centre, managed service and managed security service providers are supervised by the Agency for Digital Government (Digitaliseringsstyrelsen). Energy has its own act on strengthened preparedness in the energy sector (Act No. 258 of 6 March 2025), and telecoms its own act on security and preparedness in the telecoms sector.

Regulated finance. Banks, insurers, pension funds, mortgage credit institutions and financial infrastructure companies fall under DORA, supervised by Finanstilsynet (the Danish Financial Supervisory Authority). Your software and SaaS vendors are drawn in through contracts and the register of information.

Software publishers and product makers. Any company placing a product with digital elements on the EU market, from a connected heat pump to installable software, is inside the EU Cyber Resilience Act. That includes many Danish industrial, medical device, energy technology and software firms.

Anyone processing personal data. Datatilsynet enforces the GDPR and the Danish Data Protection Act (Act No. 502 of 23 May 2018).

Organisations building or deploying AI. The EU AI Act applies directly; Act No. 467 of 14 May 2025 sets up the national authorities and penalties.

Section 34 of the NIS 2 Act says it does not apply to the Faroe Islands and Greenland unless brought into force there by royal decree, and the AI law has the same carve out. Check the local position separately if you operate there.

The rules, regulator by regulator

The NIS 2 Act (NIS 2-loven), in force since 1 July 2025

Act No. 434 of 6 May 2025 on measures to ensure a high level of cybersecurity (lov om foranstaltninger til sikring af et højt cybersikkerhedsniveau) transposes Directive (EU) 2022/2555. Section 33 set entry into force at 1 July 2025 and repealed the 2018 sector acts for digital services, internet exchange points, health and transport. The duties that matter for software:

• Section 6, risk management measures. Essential and important entities must take appropriate and proportionate technical, operational and organisational measures. The minimum list mirrors Article 21(2) of the directive and includes supply chain security, covering the relationship with direct suppliers and service providers (item 4), and security in acquiring, developing and maintaining systems, including vulnerability handling and disclosure (item 5), alongside risk analysis, incident handling, continuity, effectiveness testing, cyber hygiene and training, cryptography, access control and asset management, and multi-factor authentication. Section 6(2) requires shortfalls to be corrected without undue delay.
• Section 7, management accountability. The management body approves the measures, oversees them, and takes part in relevant cybersecurity training.
• Sections 9 and 10, registration. Entities register with their competent authority. The transitional deadline in section 33(3) was 1 October 2025. New entities register within two weeks of coming into scope (three months for the digital provider types in section 9).
• Sections 12 and 13, incident reporting. A significant incident is one that has caused or can cause severe operational disruption or financial loss, or considerable damage to others. The entity sends an early warning within 24 hours of becoming aware, an incident notification with an initial assessment within 72 hours, interim reports on request, and a final report within one month of the notification. The CSIRT must reply to the early warning within 24 hours.
• Section 18, vulnerability reporting. The CSIRT must let anyone report vulnerabilities anonymously.
• Sections 21 to 25, supervision. Essential entities are supervised proactively, important entities reactively. After other measures fail, an authority can temporarily bar a chief executive level person from management functions (section 23).
• Section 32, penalties. Breaches of the measures, registration and reporting duties are punishable by fines, and companies can be held criminally liable.

Under section 14 of Executive Order No. 620, registration and reporting go through a self-service solution on virk.dk designated by SAMSIK, signed with MitID. SAMSIK's NIS 2 page says FE handles the reports as national CSIRT, and points companies to NIS2tjek.dk to check whether they are in scope.

Who supervises what under Executive Order No. 620

Executive Order No. 620 of 2 June 2025 on the designation of competent authorities is the map most Danish compliance teams need. In summary:

Energy and telecoms: separate acts

Section 1(2) of the NIS 2 Act steps aside for entities covered by the energy preparedness act and the telecoms security act. The energy act is supervised by the Danish Energy Agency. For telecoms, SAMSIK says it supervises providers' risk management and security measures, receives notifications about acquisitions of critical network components and security incidents, and decides security clearances for key staff. Software and network vendors to these operators should expect those rules in their contracts.

Finance: DORA and Finanstilsynet

Regulation (EU) 2022/2554, the Digital Operational Resilience Act, has applied since 17 January 2025. The NIS 2 Act does not apply to entities designated under section 333 of the Financial Business Act, and it steps aside wherever sector EU law has at least equivalent effect. Finanstilsynet supervises DORA through IT inspections, dialogue and follow up on IT incidents. On 10 October 2025 it opened its first DORA thematic review, covering 14 insurers and pension funds, with a focus on ICT risk management anchored in management.

The articles that land on software and open source:

• Article 8, identify and classify ICT assets and their dependencies.
• Article 9, protection and prevention, including patching and change management.
• Articles 17 to 19, ICT incident management, classification and reporting of major incidents to Finanstilsynet.
• Article 28, ICT third-party risk. Article 28(3) requires a register of information on every ICT services contract. Finanstilsynet collects the full register every year through e-Reg, using the templates in Implementing Regulation (EU) 2024/2956. For 2026 it opened submissions on 10 March with a 31 March deadline, at the highest consolidated level for groups.
• Article 30, the key contractual provisions, including security, audit and exit terms.

Denmark added a national layer. Finanstilsynet has designated a short list of shared banking IT and payment infrastructure providers as operators of financial digital infrastructure under a new chapter 19 c of the Financial Business Act, which it says implements NIS 2 for those providers and adds further requirements that follow from DORA.

SAMSIK, the threat level and the national CSIRT

The Danish Resilience Agency (Styrelsen for Samfundssikkerhed, SAMSIK) sits under the Ministry of Resilience and Preparedness. It coordinates NIS 2 across sectors, supervises its own sectors, issues national guidance on cybersecurity and the CRA, and publishes threat assessments. Teams used to the old Centre for Cyber Security (CFCS) website should note that cfcs.dk now forwards to samsik.dk. FE (Forsvarets Efterretningstjeneste) handles NIS 2 incident reports as the national CSIRT and, under section 17 of the act, can help entities on request with monitoring and proactive vulnerability scanning.

SAMSIK's 24 September 2026 assessment, prepared with input from FE and the Danish Security and Intelligence Service (PET), judges it likely that Russia will try to carry out destructive cyberattacks against Denmark. It says the threat mainly concerns wiper attacks and attacks that manipulate operational technology, comes from Russian state hackers and pro-Russian groups, is also influenced by groups linked to Iran, and applies especially to organisations responsible for vital functions in critical infrastructure.

Datatilsynet: the Data Protection Act and GDPR

The Danish Data Protection Agency (Datatilsynet) enforces the GDPR with the Danish Data Protection Act. The articles that most often touch software are Article 25 (data protection by design), Article 28 (processors, including choosing processors with sufficient guarantees and supervising them), Article 30 (records of processing), Article 32 (security of processing) and Article 33 (breach notification within 72 hours where feasible). Datatilsynet does not issue fines itself. It reports a case to the police with a recommended fine, and the case is settled or decided in court.

The EU AI Act and Denmark's supplementary act

Regulation (EU) 2024/1689 applies directly. Act No. 467 of 14 May 2025 on supplementary provisions to the AI Regulation (lov om supplerende bestemmelser til forordningen om kunstig intelligens) entered into force on 2 August 2025. Section 2 names three authorities: the Agency for Digital Government as notifying authority, central contact point and market surveillance authority for most prohibited practices in Article 5(1); Datatilsynet for the prohibited practices in Article 5(1)(d) and (g); and the Danish Court Administration (Domstolsstyrelsen) for the courts' use of AI outside their judicial capacity.

The European Commission says prohibitions and AI literacy duties have applied since 2 February 2025 and general purpose AI model rules since 2 August 2025. After the AI Omnibus, which entered into force on 27 July 2026, high-risk obligations start on 2 December 2027 for Annex III use cases and on 2 August 2028 for Annex I products. Article 15 (accuracy, robustness and cybersecurity for high-risk systems) is where model supply chain controls end up.

The EU Cyber Resilience Act for Danish makers

Regulation (EU) 2024/2847 entered into force on 10 December 2024. The Commission confirms reporting obligations from 11 September 2026 and the main obligations from 11 December 2027. SAMSIK's CRA page adds that manufacturers report actively exploited vulnerabilities and severe incidents to the national CSIRT and ENISA through the single reporting platform. In short:

• Article 14 reporting: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report (within 14 days of a corrective measure for a vulnerability, within one month for a severe incident).
• Article 13 manufacturer duties: due diligence on third-party components, open source included, and vulnerability handling for the support period.
• Annex I Part II: identify and document components and vulnerabilities, including a software bill of materials in a commonly used, machine-readable format covering at least top-level dependencies.

The pages checked for this guide did not name Denmark's CRA market surveillance authority, so confirm that with SAMSIK before planning around a specific regulator.

What the rules ask of software and open source

Strip away the legal wording and the Danish and EU texts ask for the same handful of capabilities. The table maps each to the evidence a supervisor, auditor or customer usually asks for.

Two observations. First, an SBOM is not named in the NIS 2 Act, DORA or the Data Protection Act, but it is the cheapest way to answer what all three ask: what is in this system, which version, from whom. Only the CRA requires one outright. Second, the 24 hour clock appears three times. If you cannot name the products that contain a vulnerable component within a few hours, every one of those clocks is at risk.

Real public incidents in or affecting Denmark

These come from official Danish sources and show the kind of event the rules are written for. They are not a judgement on the organisations involved.

A destructive attack on a water utility, attributed in December 2025. On 18 December 2025, FE assessed that Russia was behind a destructive cyberattack on a Danish water utility in 2024 and a series of DDoS attacks on Danish websites before the 2025 municipal and regional elections. FE assessed that Z-Pentest, which carried out the utility attack, and NoName057(16), which carried out the DDoS attacks, both have links to the Russian state.

The destructive attack threat level raised to HIGH, September 2026. SAMSIK's 24 September 2026 assessment followed a June 2026 sharpening of the threat within the previous MEDIUM level. It notes that attacks can range from simple attacks on weakly protected systems to coordinated attacks on well protected infrastructure.

Unauthorised access to the CPR register, October 2026. On 5 October 2026 SAMSIK relayed the ministry's announcement that unauthorised parties had obtained names, addresses and CPR numbers for a very large number of people through the Central Person Register, and urged vigilance against fraud. We cover the access path in our post on the CPR breach.

A critical open source update, 21 October 2026. SAMSIK advised organisations to install a critical PHP security update quickly, noting the developers' warning that the vulnerabilities could allow arbitrary code execution without special privileges. Its checklist starts by asking organisations to find out whether they use PHP in their own systems or in solutions from external suppliers. That first step is a software inventory question.

Public websites taken offline at a shared hosting supplier, 23 October 2026. SAMSIK reported that several authorities' websites on the same hosting platform were shut down as a precaution because of suspicious activity at the supplier. The sites were back the next morning. It is a small, clear example of concentration risk: one supplier, many public bodies.

Region Syddanmark fined under GDPR Article 32, March 2026. On 23 March 2026 Vestre Landsret fined Region Syddanmark 500,000 kroner on one of two Article 32 counts. Datatilsynet says a research and clinical database let logged-in users reach other people's PDF documents by changing the URL, exposing data on about 23,000 people. The court gave weight to a 2018 breach report involving the same type of vulnerability.

A private hospital reported for not supervising processors, February 2024. Datatilsynet reported Capio A/S to the police and recommended a fine of not less than 1.5 million kroner after finding it had not supervised three data processors for several years. Datatilsynet's page said the case was still before the courts when checked for this guide.

The personas who own the problem

The CISO or head of security. Owns the section 6 measures and the incident clocks, and briefs the management body under section 7. Triggers: a supervisor's request, a threat level change, or an incident that starts the 24 hour clock. Needs a one page risk view the board can approve, and confidence the team can name affected systems within hours.

The head of AppSec, product security or VP of Engineering. Owns vulnerability handling under section 6(1)(5), CRA Article 14 reporting and the release process. Triggers: a SAMSIK advisory, a customer questionnaire or a CRA report. Needs SBOMs on every release, ranking by exploitability and reachability, and fixes that do not stall delivery.

GRC, compliance and the NIS 2 contact. Owns registration, the evidence file and the relationship with the competent authority; in finance, DORA policy and the annual register. Triggers: an inspection, the register deadline or a thematic review letter. Needs evidence mapped to the clause, dated and current.

Procurement and vendor risk. Owns the DORA register, Article 30 contract terms, GDPR Article 28 processor supervision and the supplier tier list. Triggers: a new contract, a renewal or a supplier incident like the 23 October hosting outage. Needs a repeatable way to collect SBOMs and security evidence from suppliers.

The DPO. Owns Article 30 records, breach assessment under Article 33 and the line to Datatilsynet. Needs fast facts on which systems and which data were affected.

The startup or scale-up CTO. Often all of the above, usually triggered by a customer: a bank asking DORA questions, a municipality asking NIS 2 questions, or a European distributor asking about the CRA. Needs enough evidence for this stage, kept in one place.

A practical 30/60/90-day plan

This plan works with whatever tools you already have. Each phase ends with something you can show a supervisor, auditor or customer.

Days 1 to 30: scope, inventory and ownership

1. Confirm scope and supervisor. Check whether you are an essential or important entity (NIS2tjek.dk is the official starting point), whether DORA or the energy or telecoms act applies instead, and whether you are a CRA manufacturer. Write down your competent authority from Executive Order No. 620.
2. Check your registration through virk.dk if you are in scope.
3. Name owners. One accountable person per regime, and a deputy for reporting outside office hours, because 24 hours includes weekends.
4. Build the software inventory. Generate an SBOM in SPDX or CycloneDX for every product and business-critical system, internet-facing systems first.
5. List your suppliers. Every ICT supplier and data processor, with the service, the data involved and a criticality tier. In finance, reconcile it with the DORA register.
6. Write the incident clocks on one page.

Days 31 to 60: vulnerability handling and suppliers

1. Connect the inventory to vulnerability data. Match every SBOM against advisories daily, with CISA KEV and EPSS context so the team works on what is exploited first.
2. Set release gates. Block known exploited critical vulnerabilities in reachable code, warn on the rest, and record every exception with a reason, an owner and an expiry date.
3. Publish a disclosure route with a security contact and a coordinated vulnerability disclosure policy.
4. Ask critical suppliers for evidence: an SBOM, their vulnerability handling policy and their incident notification commitment. Track who answered.
5. Fix contracts at renewal. Check financial contracts against DORA Article 30 and processor terms against GDPR Article 28, and actually supervise processors.
6. Test the clock. Run a tabletop where a SAMSIK advisory lands on a Friday afternoon, and time how long it takes to name every affected product.

Days 61 to 90: evidence, AI and management sign-off

1. Assemble the evidence file. For each requirement in the table above, store current evidence with a date and an owner.
2. Inventory AI. List every model, AI SDK, agent and AI SaaS tool, who owns it and what data it touches. Record AI literacy training under Article 4, and flag anything that may be high risk under Annex III.
3. Control agent access. Record which AI agent holds which access, at what level, and put guardrails between agents and sensitive tools.
4. CRA readiness for makers. Confirm you can file on the single reporting platform, that SBOMs ship with each release, and that your support period and vulnerability process are written down for 11 December 2027.
5. Decide residency. Map where each tool stores code, SBOMs and findings, and check it against contracts and GDPR transfer assessments.
6. Take it to the management body. Bring the evidence file, the open risks and a dated plan, and record approval and training under section 7.

Common mistakes

• Treating NIS 2 as next year's problem. It has applied in Denmark since 1 July 2025.
• Assuming CFCS is still the address. Guidance now comes from SAMSIK, and NIS 2 reports go through virk.dk to FE as CSIRT.
• Picking the wrong supervisor. A managed IT provider answers to the Agency for Digital Government, a municipality to SAMSIK, a region to the Danish Health Data Authority.
• Forgetting that finance is different. Danish financial entities follow DORA, not the NIS 2 Act.
• Producing SBOMs once. Last quarter's list cannot answer this week's PHP advisory.
• Supervising processors on paper only. A signed agreement is not supervision, as the Capio case shows.
• Leaving AI out of the inventory. The AI Act authorities exist and AI literacy duties already apply.

How Safeguard does this

Everything in the plan above works without Safeguard. This section shows the same steps in Safeguard, using only what Safeguard's offering and documentation describe. Every capability named here is generally available (GA). Commands are shown as the docs show them; they were not run for this guide.

1. Switch on the Danish and EU framework pages. In the Compliance and GRC suite (GA), the EU NIS2 Directive, EU DORA and EU Cyber Resilience Act pages are on in a workspace unless you switch them off under Compliance › Manage. The Denmark Data Protection Act 2018 page is off until you switch it on there. Each page lists the requirements a scan decides and the policy templates. These are Safeguard's own mappings to the texts, not the regulator's numbering.
2. Generate SBOMs on every scan. SBOM generation and analysis (GA) produces SPDX and CycloneDX, and SCA with deep transitive dependency scanning (GA) builds the full component inventory. On the Denmark page, each scan is checked against GDPR Articles 32, 5(1)(f), 30, 28, 33 and 25 as given effect by the Data Protection Act, for example whether components have known versions, identifiable suppliers and integrity hashes, and whether versions are pinned. On the NIS2 page, scans are checked against Article 21(2)(a), (d) and (e), Article 23 and a coordinated disclosure contact, which line up with sections 6, 12 and 13 of the Danish act.
3. Scan without sending source code. The local runner (GA) is part of the Safeguard CLI. The runner docs show installing it with the one-line installer, running safeguard and typing /login; the machine then polls for work, scans locally and uploads only the SBOM and findings, never the source code, over 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

4. Prioritise what is exploited and reachable. Vulnerability management (GA) adds EPSS and CISA KEV context, and reachability analysis (GA) ranks the vulnerable code paths your application actually calls. When a SAMSIK advisory names a component, this takes you from "do we use it" to "which products, and which first".
5. Gate releases and record exceptions. Policies and gates (GA) are created under Settings › Policies with a visual builder or YAML, as the policies and gates docs describe. Each policy's action is Block (the gate fails), Warn (passes with a warning) or Notify (passes and sends a notification). For a legitimate exception, a developer requests one with a business justification and expiry date, and approvers decide. In CI, with policy outcomes on, the docs show a job failing when a gate fails:

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

6. Collect evidence from suppliers. TPRM (GA) SBOM requests send single or bulk requests from a template that sets SPDX or CycloneDX format and a deadline, track status from Sent to Validated or Rejected, and send automatic reminders before and at the deadline, with an escalation after it. That is the trail behind a section 6(1)(4) control, a DORA register entry or an Article 28 supervision record.
7. State what is and is not affected. CSAF and VEX upload (GA) lets you hold and share exploitability statements when a customer, supervisor or the CSIRT asks whether a vulnerability affects your product.
8. Fix, with a human in charge. Autonomous remediation (GA) can open tested, policy gated fix pull requests, singly or in bulk. It ships switched off, with every category set to Manual.
9. Inventory and govern AI. AI-BOM discovery (GA) inventories AI assets across code, cloud and connected SaaS, including models, AI SDK imports, prompts, agents and MCP servers. AI Gateway (GA) evaluates LLM traffic against guardrails 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.
10. Share posture with customers. Trust Center (GA) publishes your compliance status, controls, policies, subprocessors and documents on a public page managed under Compliance › Trust Center.
11. Choose where it runs. Safeguard's SaaS is multi-region across US, EU and Gov regions; no Denmark-specific region is offered or implied. For residency, 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. Zero AI mode (GA) runs the platform 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 its Trust Center: SOC 2 Type II audit in progress, and designed for FedRAMP High. Safeguard does not claim any Danish or EU certification, approval or designation.

What Safeguard does not do

• It does not make you compliant. It helps you produce and keep the evidence. Scope, whether an incident is significant and whether a vulnerability is reportable are decisions for you and your authorities.
• It does not file or register for you. Registration and early warnings on virk.dk, DORA reports to Finanstilsynet, breach notices to Datatilsynet and CRA notices on the single reporting platform stay with your team.
• It does not write your contracts or legal analysis. DORA Article 30 clauses, GDPR Article 28 terms and the NIS 2 scope decision need your legal team.
• It does not fix vendor appliances or hosted services. When the vulnerability is in a product you buy, the fix comes from that vendor; Safeguard helps you track the request and evidence.
• It does not replace incident response or OT security. Containment, forensics, communication and protection of operational technology against the wiper and OT threats SAMSIK describes remain your processes and tools.
• It does not offer in-country hosting in Denmark. If data must stay in Denmark, use the on-prem, air-gapped or local runner options inside your own environment.

FAQ

Is NIS 2 in force in Denmark?

Yes. Act No. 434 of 6 May 2025, the NIS 2 Act, entered into force on 1 July 2025. Entities already in scope had to register by 1 October 2025.

Who supervises NIS 2 in Denmark?

It depends on the sector. Executive Order No. 620 of 2 June 2025 names the authority for each: SAMSIK for central government, municipalities, chemicals and parts of manufacturing; the Danish Health Data Authority for health and the regions; the Agency for Digital Government for cloud, data centres and managed service providers; and other agencies for transport, maritime, water, research, space and food.

How do I report a significant incident in Denmark?

Through the self-service solution on virk.dk designated by SAMSIK, signed with MitID; FE handles the report as national CSIRT. Send an early warning within 24 hours, a notification within 72 hours and a final report within one month of the notification. The old CFCS website now forwards to SAMSIK.

Does the NIS 2 Act apply to Danish banks?

Generally no. Financial entities follow DORA, supervised by Finanstilsynet. Some shared banking IT providers are designated separately as operators of financial digital infrastructure under chapter 19 c of the Financial Business Act.

When is the DORA register of information due in Denmark?

Every year. For 2026, Finanstilsynet opened e-Reg submissions on 10 March and set a 31 March deadline. Check its page for the next cycle.

Can Datatilsynet fine a company directly?

No. It reports the case to the police with a recommended fine, and the courts decide. Vestre Landsret fined Region Syddanmark 500,000 kroner in March 2026 for an Article 32 breach.

When do Danish manufacturers have to report under the EU CRA?

Since 11 September 2026, for actively exploited vulnerabilities and severe incidents, through the single reporting platform. The full product requirements, including the SBOM, apply from 11 December 2027.

Who enforces the AI Act in Denmark?

Act No. 467 of 14 May 2025 names the Agency for Digital Government as notifying authority and central contact point, with market surveillance of prohibited practices split between it, Datatilsynet and the Danish Court Administration. The act has applied since 2 August 2025.

What is the current Danish cyber threat level?

On 24 September 2026 SAMSIK raised the threat level for destructive cyberattacks from MEDIUM to HIGH, judging it likely that Russia will try such attacks, mainly wipers and OT manipulation.

Every Danish regime above comes back to the same question: when a vulnerable component is named in an advisory, how fast can you find it and fix it. The block below sets out how Safeguard closes the gap between a disclosure and a fixed build, including when upstream has not shipped a fix yet.

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 the lodash CVE in this repo". It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow is how a Danish product team closes a vulnerability named in a SAMSIK advisory, with a person 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 municipalities, regions and banks 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 preparing for 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

• Act No. 434 of 6 May 2025, the NIS 2 Act (Retsinformation, PDF)
• Executive Order No. 620 of 2 June 2025 (Retsinformation, PDF)
• Act No. 467 of 14 May 2025 on the AI Regulation (Retsinformation, PDF)
• SAMSIK: NIS 2
• SAMSIK: Cyber Resilience Act
• SAMSIK: telecoms
• SAMSIK: Danish Resilience Agency in English
• SAMSIK: HIGH threat from destructive cyberattacks
• SAMSIK: threat assessment, September 2026 (PDF)
• SAMSIK: unauthorised access to CPR data
• SAMSIK: critical PHP security update
• SAMSIK: authorities' websites temporarily unavailable
• FE: Russia responsible for cyberattacks against Denmark (PDF)
• Finanstilsynet: DORA
• Finanstilsynet: DORA register submission
• Finanstilsynet: operators of financial digital infrastructure
• Finanstilsynet: DORA thematic review of insurers and pension funds
• Datatilsynet: judgment against Region Syddanmark
• Datatilsynet: Capio A/S recommended for a fine
• European Commission: Cyber Resilience Act
• European Commission: AI Act timeline
• Safeguard docs: Denmark Data Protection Act 2018
• Safeguard docs: EU NIS2
• Safeguard docs: EU DORA
• Safeguard docs: EU Cyber Resilience Act
• Safeguard docs: Local Runner
• Safeguard docs: Policies and Gates
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: AI-BOM Discovery
• Safeguard docs: Trust Center
• Safeguard docs: Air-Gapped Deployment

Related reading: Denmark's CPR breach and partner access, CRA Article 14 vulnerability reporting, the ENISA single reporting platform, NIS2 supply chain evidence and DORA third-party ICT risk.

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.