De nya spelreglerna: NIS2 & CRA
Detta är inte IT-rekommendationer. NIS2 och Cyber Resilience Act (CRA) är lagkrav som ej går att välja bort. De förändrar fundamentalt hur mjukvara måste utvecklas, paketeras och förvaltas. Ledningen ansvarar personligen för en obruten beviskedja – från kodrad till produktionsmiljö.
Tidslinje: från lagtext till verklighet
Tre regelverk. Tre deadlines. Alla kräver att du kan bevisa säkerhet – inte bara påstå den.
Hur teknik mappar mot lagen
Varje krav har en teknisk konsekvens för hur ni utvecklar och levererar mjukvara.
NIS2: Systematiskt riskarbete
Kräver Systematiskt & Riskbaserat Arbete (SRBA). Ledningen måste besluta om riskacceptans. Säkerhetskonfigurering (3 kap. 34 §) innebär att aktivt ta bort onödiga funktioner, portar och beroenden ur era deployments.
Konsekvens för dev: Inga bloated base-images. Inga debug-verktyg i produktion. Ingen root. Varje Dockerfile måste motiveras.
CRA: Produktansvar genom livscykeln
Kräver Secure-by-Default, ansvar för sårbarheter i 5+ år, tvingande SBOM (Software Bill of Materials) och kryptografisk signering av varje release.
Konsekvens för dev: :latest är inte en releaseversion. Varje artefakt måste vara versionerad, signerad och ha en komplett beroendeförteckning.
Slutsats: docker compose up räcker inte
En "rörlig" VPS med manuell patchning, officiella :latest-images och avsaknad av SBOM får svårt att uppfylla NIS2/CRA:s krav på spårbarhet och bevisbörda.
Slutsats: En container-baserad, låst och signerad modell är konstruerad för regelefterlevnad. En manuellt hanterad VPS är det inte.
Vad förändras i praktiken för mjukvaruteam?
Fyra skiften som NIS2 och CRA tvingar fram – och vad det innebär för er utvecklingsprocess.
"Vi kör senaste versionen"
Officiella images från Docker Hub. Ingen kontroll över transitiva beroenden. :latest i docker-compose.yml. Exempelvis hade OpenWebUI:s officiella image 1 390 CVEs – Digitalists härdade version hade 118.
Pinnade, signerade artefakter med SBOM
Varje release är versionshanterad, signerad och har en komplett SBOM. Inga okända beroenden. Full spårbarhet vid revision – exakt vad som kördes, när, och vilka kända CVEs som fanns.
"Vi patchar vid nästa sprint"
Sårbarheter hanteras som backlog-items. Veckor eller månader till åtgärd. Inget sätt att bevisa för ledningen att ni uppfyller 24-timmars rapporteringskravet.
Automatiserad MTTD + garanterad MTTR
SBOM-driven detektion upptäcker nya CVEs i realtid. Ny artefakt byggs, signeras och rullas ut inom avtalad MTTR. Vi patchar inte – vi bygger om.
"Containern kör som root, men det funkar"
Debug-verktyg, compilers och öppna portar i produktion. Stor attackyta. Bryter mot NIS2 3 kap. 34 § (ta bort onödiga funktioner) redan från dag ett.
Minimal, härdad CRaaS-image
Non-root, inget skal, endast nödvändiga binärer. Nätverkssegmentering, kryptering, loggning. Uppfyller NIS2 3 kap. 34 § och CRA Secure-by-Default.
"En konsult vet hur det fungerar"
Kunskapen sitter i enskilda personers huvuden. Ingen dokumentation. Om konsulten slutar finns ingen bevisbörda och ingen kontinuitet.
Institutionaliserad kunskap i teamet
Dedikerat team som äger applikationen. Dokumenterad plattform. Compliance-dashboard som bevisunderlag. Personberoendet bryts systematiskt.
Två världar: gårdagens IT vs. dagens applikation
Gårdagens IT ("server"-eran)
- → VPS / Fysisk Server (Statisk, Manuell)
- → Monolitisk Applikation
- → Manuell patchning & "Config Drift"
- → Otydligt ansvar (Drift vs. Utveckling)
- → Säkerhet som ett "staket" (brandvägg)
- → Kompletterat av "frivilliga optioner" för säkerhet
Dagens applikation ("moln"-eran)
- → Versionshanterad Container (Dynamisk, Kod)
- → Microservices / 12-Factor applikationer
- → Automatiserad CI/CD-pipeline
- → Delat ansvar (DevOps + Styrning)
- → Säkerhet som process (Zero Trust)
- → Regelefterlevnad som krav
Fördjupning: Moderna molnapplikationer
Vår bloggserie i fyra delar som går på djupet – från teknisk arkitektur till juridisk bevisföring.
Moderna molnapplikationer för myndigheter
Skillnaden mellan traditionell och molnbaserad utveckling. Containerisering, automatisering, 12-faktor-principer och varför upphandlare måste ställa nya krav.
Läs artikeln →Från “docker compose up” till regelefterlevnad
Varför officiella images inte räcker. OpenWebUI-exemplet: 1 390 CVEs i original vs. 118 i härdad version. Vad CRA och NIS2 faktiskt kräver av din leveranskedja.
Läs artikeln →Innovation växer genom frihet – inte beroende
Teknisk och affärsmässig inlåsning hos hyperscalers. Varför öppna standarder, open source och modulär design är förutsättningen för verklig innovation och suveränitet.
Läs artikeln →Från antaganden till bevis i NIS2, CRA och Cybersäkerhetslagen
Config drift håller inte juridiskt. CRaaS som lösning. Kritiska tidslinjer och hur ni vänder regelverk till konkurrensfördel genom modernisering.
Läs artikeln →Detta är inte IT-rekommendationer. NIS2 och Cyber Resilience Act (CRA) är lagkrav som ej går att välja bort. De förändrar fundamentalt hur mjukvara måste utvecklas, paketeras och förvaltas. Ledningen ansvarar personligen för en obruten beviskedja – från kodrad till produktionsmiljö.
Tidslinje: från lagtext till verklighet
Tre regelverk. Tre deadlines. Alla kräver att du kan bevisa säkerhet – inte bara påstå den.
Hur teknik mappar mot lagen
Varje krav har en teknisk konsekvens för hur ni utvecklar och levererar mjukvara.
NIS2: Systematiskt riskarbete
Kräver Systematiskt & Riskbaserat Arbete (SRBA). Ledningen måste besluta om riskacceptans. Säkerhetskonfigurering (3 kap. 34 §) innebär att aktivt ta bort onödiga funktioner, portar och beroenden ur era deployments.
Konsekvens för dev: Inga bloated base-images. Inga debug-verktyg i produktion. Ingen root. Varje Dockerfile måste motiveras.
CRA: Produktansvar genom livscykeln
Kräver Secure-by-Default, ansvar för sårbarheter i 5+ år, tvingande SBOM (Software Bill of Materials) och kryptografisk signering av varje release.
Konsekvens för dev: :latest är inte en releaseversion. Varje artefakt måste vara versionerad, signerad och ha en komplett beroendeförteckning.
Slutsats: docker compose up räcker inte
En "rörlig" VPS med manuell patchning, officiella :latest-images och avsaknad av SBOM får svårt att uppfylla NIS2/CRA:s krav på spårbarhet och bevisbörda.
Slutsats: En container-baserad, låst och signerad modell är konstruerad för regelefterlevnad. En manuellt hanterad VPS är det inte.
Vad förändras i praktiken för mjukvaruteam?
Fyra skiften som NIS2 och CRA tvingar fram – och vad det innebär för er utvecklingsprocess.
"Vi kör senaste versionen"
Officiella images från Docker Hub. Ingen kontroll över transitiva beroenden. :latest i docker-compose.yml. Exempelvis hade OpenWebUI:s officiella image 1 390 CVEs – Digitalists härdade version hade 118.
Pinnade, signerade artefakter med SBOM
Varje release är versionshanterad, signerad och har en komplett SBOM. Inga okända beroenden. Full spårbarhet vid revision – exakt vad som kördes, när, och vilka kända CVEs som fanns.
"Vi patchar vid nästa sprint"
Sårbarheter hanteras som backlog-items. Veckor eller månader till åtgärd. Inget sätt att bevisa för ledningen att ni uppfyller 24-timmars rapporteringskravet.
Automatiserad MTTD + garanterad MTTR
SBOM-driven detektion upptäcker nya CVEs i realtid. Ny artefakt byggs, signeras och rullas ut inom avtalad MTTR. Vi patchar inte – vi bygger om.
"Containern kör som root, men det funkar"
Debug-verktyg, compilers och öppna portar i produktion. Stor attackyta. Bryter mot NIS2 3 kap. 34 § (ta bort onödiga funktioner) redan från dag ett.
Minimal, härdad CRaaS-image
Non-root, inget skal, endast nödvändiga binärer. Nätverkssegmentering, kryptering, loggning. Uppfyller NIS2 3 kap. 34 § och CRA Secure-by-Default.
"En konsult vet hur det fungerar"
Kunskapen sitter i enskilda personers huvuden. Ingen dokumentation. Om konsulten slutar finns ingen bevisbörda och ingen kontinuitet.
Institutionaliserad kunskap i teamet
Dedikerat team som äger applikationen. Dokumenterad plattform. Compliance-dashboard som bevisunderlag. Personberoendet bryts systematiskt.
Två världar: gårdagens IT vs. dagens applikation
Gårdagens IT ("server"-eran)
- → VPS / Fysisk Server (Statisk, Manuell)
- → Monolitisk Applikation
- → Manuell patchning & "Config Drift"
- → Otydligt ansvar (Drift vs. Utveckling)
- → Säkerhet som ett "staket" (brandvägg)
- → Kompletterat av "frivilliga optioner" för säkerhet
Dagens applikation ("moln"-eran)
- → Versionshanterad Container (Dynamisk, Kod)
- → Microservices / 12-Factor applikationer
- → Automatiserad CI/CD-pipeline
- → Delat ansvar (DevOps + Styrning)
- → Säkerhet som process (Zero Trust)
- → Regelefterlevnad som krav
Fördjupning: Moderna molnapplikationer
Vår bloggserie i fyra delar som går på djupet – från teknisk arkitektur till juridisk bevisföring.
Moderna molnapplikationer för myndigheter
Skillnaden mellan traditionell och molnbaserad utveckling. Containerisering, automatisering, 12-faktor-principer och varför upphandlare måste ställa nya krav.
Läs artikeln →Från “docker compose up” till regelefterlevnad
Varför officiella images inte räcker. OpenWebUI-exemplet: 1 390 CVEs i original vs. 118 i härdad version. Vad CRA och NIS2 faktiskt kräver av din leveranskedja.
Läs artikeln →Innovation växer genom frihet – inte beroende
Teknisk och affärsmässig inlåsning hos hyperscalers. Varför öppna standarder, open source och modulär design är förutsättningen för verklig innovation och suveränitet.
Läs artikeln →Från antaganden till bevis i NIS2, CRA och Cybersäkerhetslagen
Config drift håller inte juridiskt. CRaaS som lösning. Kritiska tidslinjer och hur ni vänder regelverk till konkurrensfördel genom modernisering.
Läs artikeln →Redo att gå från antaganden till bevis?
Boka en kostnadsfri genomgång. Vi kartlägger era nuvarande risker mot NIS2 och CRA och visar vad som krävs – tekniskt och organisatoriskt.