Vilka system ska skyddas med MFA?

NIS2 specificerar inte exakta system — det är designat som ett principbaserat direktiv. Men ENISAs vägledning är tydlig, och i vår SOC ser vi dagligen vilka system som attackeras först. Listan är inte överraskande:

Från Opsios NOC-perspektiv: vi ser regelbundet att organisationer skyddar sina molnkonsoler med MFA men glömmer service accounts och API-nycklar. En komprometterad service account i AWS med AdministratorAccess-policy är precis lika farlig som en komprometterad root-inloggning — och den har ingen MFA.

Är SMS-baserad MFA tillräcklig?

Kort svar: nej, inte för väsentliga entiteter.

NIST har sedan 2017 (SP 800-63B) avrått från SMS som autentiseringsfaktor. Anledningen är välkänd: SIM-kapning (SIM swapping) och SS7-avlyssning gör SMS-koder sårbara. Det har vi sett i praktiken — inte bara i NIST-rapporter.

Rekommenderade MFA-metoder för NIS2

Opsios rekommendation: FIDO2-nycklar för alla administratörer och privilegierade konton. TOTP-appar som standardmetod för övriga användare. Implementera number matching i push-notiser om ni använder Duo eller Okta för att motverka MFA fatigue-attacker.

Molnsäkerhet

Vilka krypteringsstandarder behövs för NIS2?

NIS2 namnger medvetet inga specifika algoritmer. Artikel 21(2)(e) kräver "kryptografi och, i lämpliga fall, kryptering". Det är ett principbaserat krav som ska vara teknikneutralt och hålla över tid. Men i praktiken behöver du konkreta val — och här pekar BSI (Bundesamt für Sicherheit in der Informationstechnik) och ENISAs tekniska rekommendationer åt samma håll.

Kryptering av lagrad data (at rest)

AES-256 är den rekommenderade standarden. AES med 256-bitars nycklar ger en säkerhetsmarginal som förväntas hålla mot kvantdatorattacker under överskådlig framtid. Alla stora molnleverantörer stödjer AES-256 som standard för disk- och objektlagringskryptering.

Praktiska implementeringspunkter:

• Databaser: Aktivera transparent datakryptering (TDE) med AES-256. I AWS RDS är detta standard. I Azure SQL Database likaså.
• Fillagring: Använd full-diskkryptering (exempelvis AWS EBS-kryptering eller Azure Disk Encryption). S3-buckets i eu-north-1 (Stockholm) ska ha SSE-S3 eller SSE-KMS aktiverat som standard.
• Backuper: Kryptera alla backuper med separata nycklar från produktionsdata. Det här missas regelbundet — och det är just backuperna som ransomware-aktörer är ute efter.

Kryptering av data i transit

TLS 1.3 är nuvarande rekommenderad standard. TLS 1.3 eliminerar äldre, svaga chiffersviter och minskar handskakningstiden. TLS 1.2 är fortfarande acceptabelt men bör fasas ut där det är möjligt.

Konkreta krav:

• Avaktivera TLS 1.0 och 1.1 helt. De är formellt avråds sedan RFC 8996 (2021).
• Intern trafik: Kryptera även öst-väst-trafik inom ert nätverk, inte bara nord-syd. Service mesh-lösningar som Istio med mutual TLS (mTLS) löser detta i Kubernetes-miljöer.
• Certifikathantering: Automatisera certifikatförnyelse med ACME/Let's Encrypt eller AWS Certificate Manager. Manuell certifikathantering är en av de vanligaste orsakerna till driftstörningar vi ser.

Nyckelhantering — det verkliga problemet

Här vill vi vara rakt på sak: algoritmen är sällan problemet — nyckelhanteringen är det. I Opsios SOC ser vi regelbundet att organisationer har AES-256 aktiverat överallt men lagrar krypteringsnycklar i samma konto som den krypterade datan, eller ännu värre, hårdkodat i applikationskod.

Rekommendationer för nyckelhantering:

• Använd dedikerade nyckelhanteringstjänster: AWS KMS, Azure Key Vault eller HashiCorp Vault.
• Implementera nyckelrotation minst var 90:e dag för datakrypteringsnycklar.
• Separera key encryption keys (KEK) från data encryption keys (DEK) — envelope encryption.
• Logga all nyckelanvändning och övervaka anomalier. En nyckel som plötsligt dekrypterar stora datamängder klockan 03:00 bör trigga en larm.

Managerade molntjänster

Zero trust och NIS2 — naturliga partners

Zero trust är inte ett NIS2-krav i sig — direktivet nämner inte termen. Men principerna bakom zero trust mappar direkt mot flera av Artikel 21:s punkter: åtkomstkontroll, nätverkssegmentering, kontinuerlig autentisering och övervakning.

I praktiken innebär en zero trust-approach:

• Ingen implicit tillit: Varje åtkomstbegäran verifieras, oavsett om den kommer inifrån eller utifrån nätverket.
• Minsta privilegium: Användare och system får bara den åtkomst de behöver, just-in-time.
• Mikrosegmentering: Nätverket delas upp i isolerade zoner. Ett intrång i en zon sprider sig inte automatiskt.
• Kontinuerlig verifiering: Sessioner omvalideras löpande baserat på kontext — enhetens säkerhetsstatus, plats, beteendemönster.

Från vår erfarenhet med NIS2-implementeringar: organisationer som redan har en zero trust-strategi behöver göra betydligt mindre arbete för att uppfylla Artikel 21. De som fortfarande bygger på perimeterbaserad säkerhet — brandvägg utanpå, platt nätverk inuti — har ett stort efterlevnadsgap att täppa till.

Managerad DevOps

Implementeringsordning: var börjar ni?

Vi ser ofta att organisationer paralyseras av NIS2:s bredd. Vår rekommendation baserad på hundratals implementeringar:

Månad 1–2: MFA för privilegierade konton

Aktivera FIDO2 eller TOTP-baserad MFA för alla administratörskonton, molnkonsoler och VPN-gateways. Det här ger störst riskminskande effekt per investerad krona.

Månad 2–3: Kryptering-audit

Inventera var data lagras och hur den krypteras. Identifiera luckor: okrypterade backuper, TLS 1.0/1.1 som fortfarande är aktivt, nycklar som inte roteras.

Månad 3–4: MFA för alla användare

Rulla ut MFA till samtliga användare. Kommunicera tidigt, utbilda och erbjud support — MFA-utrullningar som misslyckas gör det nästan alltid på grund av bristfällig förändringsledning, inte teknik.

Månad 4–6: Zero trust-foundation

Implementera villkorlig åtkomst (Conditional Access i Entra ID, eller AWS IAM Identity Center), påbörja nätverkssegmentering och etablera löpande övervakning.

Sanktioner och ansvar

NIS2:s sanktionsram är avsevärd:

• Väsentliga entiteter: Böter upp till 10 miljoner EUR eller 2 % av global årsomsättning (det högre beloppet gäller)
• Viktiga entiteter: Böter upp till 7 miljoner EUR eller 1,4 % av global årsomsättning

Vad som gör NIS2 annorlunda är att ledningen kan hållas personligt ansvarig. Det innebär att styrelse och ledningsgrupp inte kan delegera bort ansvaret — de måste förstå och godkänna de cybersäkerhetsåtgärder som implementeras.

I Sverige är det Integritetsskyddsmyndigheten (IMY) och sektorsspecifika tillsynsmyndigheter som ansvarar för tillsyn. Vi förväntar oss att tillsynen inledningsvis fokuserar på just MFA och kryptering som grundläggande hygienåtgärder — de är konkreta, mätbara och svåra att argumentera emot.

Cloud FinOps

Opsios perspektiv

MFA och kryptering är inte komplicerade tekniskt — de är välkända, mogna teknologier. Det som gör dem svåra är konsekvent implementation och löpande förvaltning. Nycklar som inte roteras, undantag som blir permanenta, service accounts utan MFA — det är de saker som skapar verkliga sårbarheter. Vår SOC i Karlstad och Bangalore övervakar dessa kontroller dygnet runt, och det är i den löpande driften som skillnaden mellan efterlevnad på papper och verklig säkerhet uppstår.

Vanliga frågor

Räcker SMS-baserad MFA för att uppfylla NIS2?

Tekniskt sett är SMS bättre än ingen MFA alls, men NIST har sedan 2017 avrått från SMS som autentiseringsfaktor på grund av SIM-kapning och avlyssning. För väsentliga entiteter under NIS2 rekommenderas FIDO2/WebAuthn-nycklar eller TOTP-baserade appar. SMS uppfyller sannolikt inte kravet på "lämpliga och proportionella" åtgärder.

Vilka krypteringsalgoritmer kräver NIS2 specifikt?

NIS2 namnger inga specifika algoritmer. Artikel 21(2)(e) kräver "kryptografi och, i lämpliga fall, kryptering". BSI och ENISA pekar mot AES-256 för lagrad data och TLS 1.3 för data i transit som minimistandard. Valet ska vara proportionellt mot risken.

Gäller MFA-kravet alla användare eller bara administratörer?

ENISAs vägledning är tydlig: MFA ska tillämpas på alla system som hanterar känslig information eller ger administrativ åtkomst. I praktiken innebär det att alla användare med åtkomst till driftskritiska system — inte bara administratörer — behöver MFA.

Hur hänger zero trust ihop med NIS2:s krav?

Zero trust bygger på principen att ingen åtkomst beviljas implicit — varje begäran verifieras. Det matchar NIS2:s krav på åtkomstkontroll, nätverkssegmentering och kontinuerlig autentisering. Det är inte ett krav i sig, men det är det mest effektiva sättet att uppfylla flera av Artikel 21:s punkter samtidigt.

Vad händer om vi inte uppfyller NIS2:s MFA-krav?

Väsentliga entiteter kan få böter upp till 10 miljoner EUR eller 2 % av global årsomsättning. Viktiga entiteter riskerar upp till 7 miljoner EUR eller 1,4 %. Dessutom kan ledningen hållas personligt ansvarig, vilket är nytt jämfört med tidigare regelverk.