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

If you build, buy or run software in Sweden, the Cybersecurity Act (cybersäkerhetslag, SFS 2025:1506) has applied since 15 January 2026, its security measures regulations took effect on 1 October 2026, and since 1 July 2026 the national CSIRT sits with the National Cyber Security Centre at FRA. DORA, the Protective Security Act, IMY's GDPR enforcement and the EU CRA and AI Act add further duties on software and suppliers.

This guide takes each regime from its primary source, names the supervisor, lists 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

• Sweden's NIS2 law is in force. The Cybersecurity Act (2025:1506) and Cybersecurity Ordinance (2025:1507) apply from 15 January 2026. Chapter 2, section 3 lists ten minimum measures, including supply chain security and secure acquisition, development and maintenance.
• Reporting clocks: a 24-hour notice, a 72-hour notification (24 hours for trust services) and a final report one month later.
• FRA holds the central roles. As amended by SFS 2026:623, the ordinance makes FRA the single point of contact, the CSIRT and the cyber crisis authority. CERT-SE moved from the Swedish Civil Defence Agency (MCF, formerly MSB) to FRA's NCSC on 1 July 2026.
• Sector authorities supervise, including Finansinspektionen, PTS and six county administrative boards.
• DORA applies now. Finansinspektionen's FFFS 2024:20 sets a 28 February deadline for the register of information.
• Protective security reaches suppliers. Outsourcing under the Protective Security Act needs a security protection agreement, a suitability test and sometimes consultation; a new notification duty starts on 1 January 2027.
• IMY fines weak software security: SEK 6 million against Sportadmin and SEK 1.8 million against Miljödata in 2026, both under GDPR Article 32.
• EU product rules are dated. CRA reporting from 11 September 2026, full CRA duties from 11 December 2027; AI Act high-risk rules from 2 December 2027 (Annex III) and 2 August 2028 (Annex I), per the Commission.
• Safeguard capabilities covered, all GA: SBOM generation and analysis, SCA and vulnerability management with EPSS and KEV, reachability analysis, policies and gates, license compliance, the Compliance and GRC suite (Sweden DPA, NIS2, DORA, EU CRA and EU AI Act pages), 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 Sweden

Swedish rules stack in three layers: EU regulations that apply directly (DORA, the CRA, the AI Act, the GDPR), an EU directive turned into Swedish law (NIS2, through the Cybersecurity Act), and national security law (the Protective Security Act). Most medium and large organisations sit in at least two.

Regulated finance. Banks, insurers, payment and e-money institutions, investment firms and fund managers are financial entities under DORA, Regulation (EU) 2022/2554, supervised by Finansinspektionen (FI). The Cybersecurity Ordinance also names FI as the NIS2 supervisor for banking and financial market infrastructure. ICT and software vendors are drawn in through contracts and the register of information.

Operators in NIS2 sectors. Section 7 of the ordinance lists the sectors, among them energy, transport, health care, water, food, digital infrastructure, digital providers, ICT service management, space, waste, research, public administration, chemicals and several kinds of manufacturing. Essential (väsentlig) and important (viktig) operators in these sectors are covered.

Public sector bodies. Government agencies listed in Annex 1 to the Preparedness Ordinance (2022:524) are covered unless exempted (ordinance section 4). Municipalities and regions are supervised by six county administrative boards.

Security-sensitive activities and their suppliers. Anyone running activity of importance to Sweden's security, or handling classified information, falls under the Protective Security Act. Their software, cloud and outsourcing suppliers are drawn in through security protection agreements.

Product makers. Any manufacturer placing a product with digital elements on the EU market falls under the EU Cyber Resilience Act.

Anyone processing personal data. The Swedish Authority for Privacy Protection (Integritetsskyddsmyndigheten, IMY) enforces the GDPR and the Swedish Data Protection Act (2018:218), including against SaaS processors.

Organisations building or deploying AI fall under the EU AI Act directly.

The rules, regulator by regulator

Each status below was checked on 25 October 2026 against the statute text published by the Riksdag, the regulator's own page or the European Commission's page. EUR-Lex did not load during research, so EU article numbers for NIS2, DORA, the CRA and the AI Act come from the published texts as we know them and from regulator pages that cite them; check them on EUR-Lex before relying on them.

The Cybersecurity Act (cybersäkerhetslag, 2025:1506): Sweden's NIS2 law

Sweden transposed NIS2, Directive (EU) 2022/2555, with a new act and ordinance issued on 11 December 2025 and in force from 15 January 2026. The act repealed the 2018 NIS law (2018:1174). Chapter 2 holds the operator duties:

Two of the ten areas in section 3 are directly about software: point 4, security in the supply chain (säkerhet i leveranskedjan), and point 5, security in the acquisition, development and maintenance of network and information systems. The others cover risk analysis, incident handling, continuity, effectiveness testing, cyber hygiene and training, cryptography, personnel and access control with asset management, and authentication.

Chapter 3 gives supervisors information requests, site access, regular audits of essential operators, targeted audits and security scans (sections 3 to 7). For important operators these powers are reactive, used when there is reason to suspect non-compliance (section 2). Chapter 4, section 10 sets fines from SEK 5,000 up to the higher of 2 percent of global annual turnover or 10 million euros for essential operators, the higher of 1.4 percent or 7 million euros for important operators, and SEK 10 million for public sector operators.

Who supervises: sector authorities and FRA

Sweden spreads supervision across sector authorities. Section 7 of the ordinance names them:

Section 18 tells supervisors to work with IMY when an incident is also a personal data breach. Section 19 requires them to inform the DORA oversight forum if a supervised operator is a designated critical ICT third-party provider under DORA Article 31.

The central roles changed during 2026. The Swedish Civil Contingencies Agency (MSB) became the Swedish Civil Defence Agency (Myndigheten för civilt försvar, MCF) on 1 January 2026. Following a government decision of 20 November 2025, CERT-SE confirms that MCF's cyber work moved to the National Cyber Security Centre (Nationellt cybersäkerhetscenter, NCSC) at FRA on 1 July 2026, including CERT-SE, the cyber crisis role, the NIS2 single point of contact and the Cybersecurity Act tasks. As amended by SFS 2026:623, the ordinance names FRA as single point of contact (section 23, receiving registrations under section 5), CSIRT (section 31, receiving incident reports under section 6), coordinator for coordinated vulnerability disclosure (section 33, point 10) and cyber crisis management authority (section 35).

The security measures regulations from 1 October 2026

The act sets principles; regulations set detail. Section 39 of the ordinance lets FRA issue further rules on security measures and significant incidents for all supervisory areas except PTS's, and section 37 gives PTS the same power for its sectors. FRA says the regulations were drafted by MCF, published in June 2026 and took effect on 1 October 2026, and describes them as risk based: they set the areas to work on and the measures to consider given an organisation's risks, size and circumstances. For software teams, an auditor can now ask how you manage supply chain risk and secure development and expect records, not a policy statement.

DORA and Finansinspektionen

DORA has applied since 17 January 2025. FI's own regulations, FFFS 2024:20, cover incident reporting and the register of information. FI's pages say:

• Register of information. Under DORA Article 28(3) firms keep a register of all ICT third-party arrangements. Section 4 of FFFS 2024:20 requires reporting it to FI annually by 28 February, as at the previous year end, using the templates in Implementing Regulation (EU) 2024/2956, LEI codes and XBRL-CSV through Fidac. Groups may report at the highest consolidated level.
• Incident reporting. Major ICT-related incidents are reported under DORA Article 19 through Fidac, in JSON format since 31 March 2025.

The rest of DORA is where supply chain work lands: Article 8 on identifying ICT assets and dependencies, Articles 28 and 29 on third-party strategy and pre-contract assessment, and Article 30 on key contract provisions such as security requirements and audit rights. Because FI is also a Cybersecurity Act supervisor, have legal confirm how DORA's precedence as a sector-specific act under NIS2 Article 4 applies to your entity.

The Protective Security Act (säkerhetsskyddslag, 2018:585) and outsourcing

This national security law applies to anyone running security-sensitive activity (säkerhetskänslig verksamhet), and it is the regime that most often surprises foreign software suppliers. Chapter 2, section 1 requires a documented protective security analysis and the measures it calls for. Section 6 requires operators to notify their supervisor, and section 7 requires a head of protective security (säkerhetsskyddschef) unless clearly unnecessary.

Chapter 4 governs outsourcing:

• Security protection agreement (4 kap. 1 §). Before a procurement, contract or cooperation that could give a supplier access to classified information at the "konfidentiell" level or higher, or equally important security-sensitive activity, the operator must sign a security protection agreement (säkerhetsskyddsavtal), including with subcontractors, before access starts.
• Control (4 kap. 3 to 5 §§). The agreement sets supplier requirements and the operator's right to check and revise; the operator must actually check.
• Suitability test (4 kap. 7 and 8 §§). Beforehand, the operator documents a special assessment of what the supplier could reach and whether the arrangement is suitable. If not, it must not go ahead.
• Consultation (4 kap. 9 to 11 §§). At the "hemlig" (secret) level or higher, the operator consults the supervisor first; the supervisor can order measures or prohibit the arrangement.

Amendments under SFS 2026:764 took effect on 1 July 2026, according to the county boards that act as supervisors. Supervisors can now intervene in ongoing arrangements judged unsuitable even without an agreement requirement (4 kap. 12 §) and make interim decisions. A new duty (4 kap. 1 a §) applies from 1 January 2027: notify arrangements begun before 1 December 2021, including those under older agreements, and those begun later but before the activity was classed as security-sensitive. Failing to notify can bring a sanction fee. Several authorities share supervision; the county boards of Norrbotten, Stockholm, Skåne and Västra Götaland are among them.

For a supplier, expect questions about where code runs and who in your company and subcontractors can reach the data.

IMY and the GDPR

IMY supervises the GDPR, with the Data Protection Act (2018:218) adding national rules. The articles that recur in its software decisions are Article 32 (security of processing), Article 28 (processor guarantees and contracts), Article 33 (breach notice within 72 hours where feasible) and Article 5(1)(f) and 5(2) (integrity and demonstrable compliance). Its recent decisions, below, look at real-time intrusion detection, checks on new software, known risks left open, and how controllers choose suppliers.

The EU Cyber Resilience Act for Swedish makers

The CRA, Regulation (EU) 2024/2847, entered into force on 10 December 2024. The Commission confirms that reporting obligations apply from 11 September 2026 and the main obligations from 11 December 2027.

For an actively exploited vulnerability, Article 14 requires an early warning within 24 hours, a notification within 72 hours and a final report within 14 days after a corrective measure is available, through ENISA's single reporting platform to the coordinator CSIRT. Sweden's ordinance makes FRA's CSIRT the coordinator for coordinated vulnerability disclosure. From December 2027, Annex I Part II requires vulnerability handling, including an SBOM covering at least top-level dependencies, and Article 13 requires due diligence on third-party components, including open source.

We could not confirm on a primary source which Swedish authority will be the CRA market surveillance authority.

The EU AI Act and Sweden's proposed supervisors

The AI Act, Regulation (EU) 2024/1689, entered into force on 1 August 2024. The Commission says it became applicable on 2 August 2026 with exceptions: after the political agreement on the simplification proposal, Annex III high-risk rules start on 2 December 2027 and Annex I product rules on 2 August 2028.

Sweden's AI inquiry (SOU 2025:101) proposed in October 2025 that PTS take the main market surveillance role, with IMY and Finansinspektionen sharing high-risk AI, and a PTS regulatory sandbox. We could not confirm that a bill has been enacted, so treat these roles as proposed. Supply chain articles to note are Article 11 and Annex IV (documentation, including software versions), Article 15 (accuracy and cybersecurity) and Article 25 (the AI value chain).

What the rules ask of software and open source

Stripped of legal form, the Swedish rules ask the same things of software in different words.

Three points are specific to Sweden. Both Cybersecurity Act incident reports and CRA vulnerability reports end at FRA's CSIRT, so one tested runbook can serve both, while GDPR notices still go to IMY. Protective security cuts across everything: a supplier that passes a NIS2 or DORA review can still be unsuitable because of who can reach the data. And public sector concentration matters, since many municipalities share the same systems and IMY has examined suppliers and customers after one breach.

Real public incidents in or affecting Sweden

From the last three years, from the regulator's or company's own statements. We draw no conclusions beyond what the sources say.

Each involves software someone else wrote or hosted: a provider's data centre, a shared SaaS platform, a supplier serving most municipalities, and a third-party script on a website. For the Miljödata decision in depth, see our post on IMY's fine against Miljödata.

The personas who own the problem

The CISO owns the Cybersecurity Act programme, the management training under chapter 2, section 4 and the incident runbook. They need to know which systems and suppliers a supervisor would audit first, and a rehearsed 24-hour reporting path. Triggers: the 1 October 2026 regulations, a supervisor's information request, a significant incident.

The head of AppSec or product security owns secure development and vulnerability handling (point 5, and the CRA for makers). They need SBOMs on every release, triage that separates exploited and reachable issues from noise, and a disclosure contact. Trigger: any actively exploited vulnerability in a product since 11 September 2026.

VP or Director of Engineering owns the pipelines that produce evidence and wants one process for NIS2, DORA, the CRA and customer questionnaires, not four. Trigger: a large customer or supervisor asking for SBOMs on a deadline.

GRC and regulatory affairs owns the mapping from rule to control to evidence, the DORA register and the supervisor relationship. Triggers: the 28 February register deadline, an FI review, an audit under chapter 3 of the Cybersecurity Act.

The head of protective security (säkerhetsskyddschef) owns the protective security analysis, agreements and supervisor consultation, and needs an honest list of every supplier and subcontractor that can reach security-sensitive data. Trigger: the 1 January 2027 notification duty.

Procurement and vendor risk owns onboarding, clauses and reviews, and needs a repeatable way to request and chase SBOMs and attestations. Triggers: renewals, the DORA register cycle, a supplier breach.

The DPO owns Article 28 terms, Article 33 notices to IMY and the processing record. Trigger: a supplier breach, as Miljödata and Sportadmin showed.

A startup CTO selling to these organisations needs just enough: an SBOM per release, a disclosure contact, a vulnerability policy and a short answer on where data lives. Trigger: the first enterprise or public sector questionnaire.

A practical 30/60/90-day plan

This works with spreadsheets and open source tools, or with a platform, for a regulated operator or a supplier to one.

Days 1 to 30: scope, inventory and ownership

1. Confirm your position. One line per regime: Cybersecurity Act (essential, important or not covered, and which supervisor), DORA, Protective Security Act, GDPR role, CRA role, AI Act role. Have legal sign it off.
2. Check registration. If covered, confirm registration under chapter 2, section 2 with FRA as single point of contact, and that changes are reported within 14 days.
3. Name owners per regime and one for incident reporting across all of them. Book management training.
4. Build the software inventory. Generate an SBOM for each product you build, in SPDX or CycloneDX, as part of the build. List bought software and its vendors.
5. Build the supplier list, with what each supplier and subcontractor can reach. Mark any touching security-sensitive activity.
6. Write the incident matrix:

Days 31 to 60: vulnerability handling and suppliers

1. Set triage rules: known exploitation (CISA KEV), likelihood (EPSS), reachability in your code and asset criticality, with timelines per tier.
2. Add release gates. Fail builds on what must not ship, warn on the rest, and record exceptions with a reason, approver and expiry.
3. Publish a disclosure contact (security.txt and a policy page).
4. Request supplier evidence: an SBOM, vulnerability handling policy, breach notice commitments and where processing and support happen. Track answers.
5. Review contracts against DORA Article 30, GDPR Article 28 and, for security-sensitive suppliers, chapter 4 of the Protective Security Act, including a documented suitability test.
6. Start the 2027 list of arrangements the 1 January 2027 notification duty covers.

Days 61 to 90: evidence, AI and residency

1. Map controls to records for each of the ten areas in chapter 2, section 3: SBOMs, scan results, gate decisions, tickets, supplier responses.
2. Run a drill. Time how long it takes to name every affected product and version for an exploited library flaw. More than a few hours puts the 24-hour clock at risk.
3. Inventory AI: models, services, agents and MCP servers, owners, data touched and agent access. Map them to AI Act roles and dates.
4. Settle residency per sensitive workload: where code and data are processed, who can reach them, and whether supplier tools can run inside your environment.
5. Prepare the DORA register before 28 February.
6. Brief management with one page per regime and the top gaps.

Common mistakes

• Treating the Cybersecurity Act as paperwork. The October regulations and chapter 3 audit powers mean supervisors ask for records.
• Reporting to the old address. CERT-SE has been part of NCSC at FRA since 1 July 2026; update runbooks.
• Assuming DORA covers everything for a bank. IMY still handles personal data breaches, and protective security may apply.
• Bringing in protective security at contract signature. The suitability test and agreement come before access.
• Forgetting old arrangements that the 2027 notification duty covers.
• Asking suppliers for "an SBOM" with no format or deadline.
• Leaving third-party scripts out of scope, as the Apohem decision shows.

How Safeguard does this

Everything in the plan works without Safeguard. Here is how the same steps run in Safeguard, using only what its documentation and offering describe. Every capability named is generally available (GA).

1. Turn on the framework pages. In the Compliance and GRC suite (GA), the Sweden Data Protection Act (2018:218) framework is off until you switch it on under Compliance › Manage, while NIS2, DORA, the EU CRA and the EU AI Act are on unless switched off. Each page lists requirements a scan decides, plus catalogue controls you evidence with tests, uploads, policies or attestations.
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 inventory. Scans are checked against requirements such as SE-DPA-A32 (integrity hashes for Article 32), SE-DPA-A28 (identifiable suppliers), SE-DPA-A33 (components identifiable fast enough for a 72-hour notice), NIS2-21.2D (supply chain security), NIS2-23 (incident reporting readiness) and EU-CRA-II1 (an SBOM of top-level dependencies).
3. Scan without sending source code. The local runner (GA) is part of the Safeguard CLI. As the docs show, you install it with the one-line installer, run safeguard, type /login, and the machine polls for work. It scans locally and uploads only the SBOM and findings, never source code, over outbound HTTPS it opens itself. Headless, per the docs:

# 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.
5. Gate releases and record exceptions. Policies and gates (GA) live under Settings › Policies, with conditions such as severity, CVSS, EPSS, license, component age and maintenance. Each policy's action is Block, Warn or Notify. Exceptions are requested with a business justification and expiry, decided by approvers and recorded in the audit trail. In CI the docs show:

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

6. Collect supplier evidence. TPRM (GA) SBOM requests go out singly or in bulk from a template setting SPDX or CycloneDX and a deadline, with status tracking from Sent to Validated, automatic reminders, and format and completeness validation before scanning. That trail supports a DORA register entry, a supply chain control or a protective security supplier review.
7. State what is affected. CSAF and VEX upload (GA) holds exploitability statements for customers, FRA's CSIRT or a supervisor.
8. Keep licenses in check with license compliance (GA), relevant to CRA technical documentation.
9. Fix, with a human in charge. Autonomous remediation (GA) opens tested, policy gated fix pull requests, singly or in bulk. It ships switched off, every category set to Manual.
10. Govern AI. AI-BOM discovery (GA) inventories AI assets. AI Gateway (GA) guards model traffic against prompt injection, jailbreak and PII egress. MCP Guardrail (GA) issues guardrail proxy URLs for MCP servers, and agent identity (GA) tracks which agent holds what access.
11. Share posture. Trust Center (GA) publishes posture and documents such as SBOMs and VEX, and helps answer questionnaires.
12. Choose where it runs. SaaS is multi-region across US, EU and Gov; no Sweden-specific region is offered or implied. For residency and protective security questions, the GA options are private VPC or dedicated tenancy, full on-prem, and fully air-gapped with the AI models 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 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. It claims no Swedish or EU certification or approval.

What Safeguard does not do

• It does not make you compliant. It helps you produce and keep evidence. Whether you are essential or important, whether an incident is significant, and whether a supplier is suitable under the Protective Security Act stay your and your supervisors' decisions.
• It does not report to FRA, FI or IMY for you. It helps you name affected products and versions fast; filing is your team's job.
• It does not sign or assess security protection agreements. On-prem, air-gapped and local runner options can keep processing in an environment you control, but they do not replace the suitability assessment.
• It does not write contracts or legal analysis, such as DORA Article 30 clauses or GDPR Article 28 terms.
• It does not fix vendor appliances or hosted services. That fix comes from the vendor; Safeguard helps you track it.
• It does not replace incident response: containment, forensics, police reports and communication stay with you.

FAQ

Is NIS2 in force in Sweden?

Yes. The Cybersecurity Act (2025:1506) and Cybersecurity Ordinance (2025:1507) have applied since 15 January 2026, replacing the 2018 NIS law. Security measures regulations took effect on 1 October 2026.

Who supervises cybersecurity under NIS2 in Sweden?

Sector authorities listed in section 7 of the ordinance, such as Finansinspektionen for banking, PTS for digital infrastructure and six county boards for public administration. FRA is the single point of contact, CSIRT and cyber crisis authority.

Did MSB's cyber role move to FRA?

Yes. MSB became MCF on 1 January 2026, and its cyber work, including CERT-SE, moved to NCSC at FRA on 1 July 2026.

How fast must a Swedish operator report a significant incident?

A notice within 24 hours, a notification within 72 hours (24 for trust services) and a final report one month later, under chapter 2, sections 5 to 8, to FRA's CSIRT.

Does DORA apply to Swedish banks and insurers now?

Yes, since 17 January 2025. Under FFFS 2024:20 the register of information is due to FI by 28 February each year, and major ICT incidents are reported through Fidac.

What does the Protective Security Act require when outsourcing IT?

If a supplier could reach information classified as confidential or higher, a documented suitability test and a security protection agreement before access, and consultation with the supervisor at the secret level. Older arrangements must be notified from 1 January 2027.

What fines has IMY imposed for weak software security?

SEK 6 million against Sportadmin in January 2026 and SEK 1.8 million against Miljödata in September 2026, both under Article 32.

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

Since 11 September 2026, for actively exploited vulnerabilities and severe incidents, with a 24-hour early warning through ENISA's platform. Full requirements apply from 11 December 2027.

Who will supervise the AI Act in Sweden?

Inquiry SOU 2025:101 proposed PTS as lead, with IMY and Finansinspektionen sharing high-risk AI. We could not confirm the proposal has been enacted.

The Swedish rules come down to knowing what is in your software, fixing what matters on a clock, and proving it with records. The block below covers the fixing part, including what to do 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. It then shows /permissions, /model and /scan. The same flow is how a Swedish product team closes a vulnerability it may have to report under the CRA, 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 operators under the Protective Security Act 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 AI inventories and agent access controls ahead of the AI Act dates, 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

• Riksdagen: Cybersecurity Act (cybersäkerhetslag, 2025:1506)
• Riksdagen: Cybersecurity Ordinance (cybersäkerhetsförordning, 2025:1507), as amended to SFS 2026:623
• FRA: New requirements to strengthen Sweden's cybersecurity (Swedish)
• CERT-SE: Cyber work gathered at the National Cyber Security Centre (Swedish)
• Finansinspektionen: Register of information under DORA (Swedish)
• Finansinspektionen: Information on incident reporting under DORA (Swedish)
• Riksdagen: Protective Security Act (säkerhetsskyddslag, 2018:585), as amended to SFS 2026:764
• County Administrative Board of Skåne: changes to the Protective Security Act from 1 July 2026 (Swedish)
• IMY: Sanction fee against Sportadmin (Swedish)
• IMY: Sanction fee against Miljödata (Swedish)
• IMY: Supervision of Apohem concerning the Meta pixel (Swedish)
• Tietoevry: clarification of the sequence of events in the ransomware attack (Swedish)
• Government Offices of Sweden: AI inquiry proposals (Swedish)
• European Commission: AI Act regulatory framework and timeline
• European Commission: Cyber Resilience Act
• Safeguard docs: Sweden Data Protection Act (2018:218) framework
• Safeguard docs: EU NIS2 framework
• Safeguard docs: EU DORA framework
• Safeguard docs: EU Cyber Resilience Act framework
• Safeguard docs: EU AI Act framework
• Safeguard docs: Local Runner
• Safeguard docs: Policies and Gates
• Safeguard docs: TPRM SBOM Requests

Related reading: IMY's fine against Miljödata and the supplier lessons, 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.