Sweden's Cybersecurity Act: what it changes for security testing

Swedish organisations had an unusually long run-up to NIS2. The directive's transposition deadline was 17 October 2024; Sweden's Cybersecurity Act entered into force on 15 January 2026. That gap produced a familiar pattern — a lot of readiness assessments, comparatively little tested evidence. The Act removes the ambiguity that made deferral comfortable.

What actually changed on 15 January 2026

The substance of the obligations is inherited from NIS2: risk-management measures, incident reporting, management accountability, supply chain security, and supervision with the possibility of sanctions. What changed is that they became Swedish law with named supervisory authorities and a registration duty, rather than a directive to be planned for.

• In-scope entities must register with their supervisory authority. Registration is what makes you visible to supervision — it is not a formality you can defer indefinitely.
• Sector supervision is distributed across several authorities rather than concentrated in one, with MSB holding a coordinating role and the national CSIRT function at CERT-SE.
• Management bodies carry approval and oversight duties, mirroring NIS2 Article 20.
• Incident reporting follows the NIS2 staged model: early warning, notification, final report.
• Supervisory authorities can request evidence, and administrative sanction charges are available for non-compliance.

Why Swedish organisations are unusually exposed on identity

Sweden has one of the highest rates of enterprise cloud adoption in Europe, and Swedish B2B and public-sector environments lean heavily on federated identity, BankID-adjacent flows, and SaaS-first architectures. That is operationally excellent and it concentrates risk in a specific place: the identity provider and the trust relationships hanging off it.

In practice this means a perimeter-focused test tells you almost nothing useful. There is very little perimeter left. The questions that matter are whether a compromised user account can be escalated, whether conditional access can be bypassed through a legacy or recovery path, whether service principals and OAuth grants are over-privileged, and whether a supplier's delegated access is scoped to what they actually need.

A testing programme that maps to supervision

The evidence gap most readiness projects leave open

Readiness assessments produce gap analyses. Gap analyses describe intent. Supervision asks about outcome. The distance between the two is almost always in three places.

1. Detection. Policies claim monitoring coverage; nobody has verified what the SOC actually sees for the attack paths that matter. An objective-led exercise resolves this in days.
2. Recovery. Backup policies are documented; nobody has attempted to reach or damage backups from a compromised position. This is the control that decides whether an incident becomes significant.
3. Closure. Findings are recorded and assigned; nobody has verified the fix. A remediation ticket marked done is not evidence that the vulnerability is gone.

Sequencing for the first supervised year

If you are starting from a gap analysis and want defensible evidence within two quarters, the order that works is: confirm scope and register, test identity and the systems carrying your most sensitive processing, remediate on a stated window, retest anything high or critical, then run one timed incident exercise that produces an awareness-to-notification record. Board approval comes last, referencing all of it — not first, referencing a plan.

That order matters because management approval under Article 20 is only meaningful if there is something factual to approve. A board that signs off a policy set has approved a document. A board that signs off a tested risk position has discharged an obligation.