NIS2-direktivet trådte i kraft i Danmark den 18. november 2024 — og for første gang er kommuner eksplicit med: de klassificeres som offentlige forvaltningsenheder og betragtes som "vigtige enheder" under direktivet. Det stiller nye krav til IT-afdelinger der hidtil har opereret uden formel cybersikkerhedsforpligtelse.
Det betyder at kommunens IT-afdeling nu er underlagt de samme risikostyringskrav som private virksomheder i kritisk infrastruktur — herunder krav om systematisk certifikatstyring og dokumenteret tilsynsberedskab. Og et af de mest konkrete tekniske krav handler om TLS-certifikater.
Er jeres kommune omfattet?
Ja. Alle danske kommuner er som udgangspunkt klassificeret som vigtige enheder under NIS2, med mindre de falder under en specifik undtagelse. Vigtige enheder er underlagt kravene i Artikel 21 om risikostyring og Artikel 23 om hændelsesrapportering.
I praksis vil Digitaliseringsstyrelsen og Center for Cybersikkerhed (CFCS) fungere som tilsynsmyndigheder for den offentlige sektor. Tilsyn kan ske via selvvurdering, stikprøver og egentlige inspektioner.
Hvad Artikel 21 kræver — på certifikatniveau
Artikel 21 opstiller otte kategorier af sikkerhedsforanstaltninger. For certifikater og TLS er tre af dem direkte relevante:
Artikel 21(2)(a) — Risikoanalyse og informationssystemsikkerhed. Kommunen skal have et overblik over sine informationssystemer og de risici de er udsat for. Et certifikat der udløber uden at nogen opdager det udgør en konkret, dokumenterbar risiko. Uden et register over certifikaternes status er denne risikoanalyse ikke mulig at gennemføre troværdigt.
Artikel 21(2)(e) — Sikring af anskaffelse, udvikling og vedligeholdelse af systemer. Systemer skal konfigureres og vedligeholdes sikkert. For TLS betyder det i praksis: aktuelle certifikater, stærke protokolversioner (TLS 1.2 minimum, TLS 1.3 foretrukket), korrekte certifikatkæder og rettidigt fornyelse. Tilsynsmyndigheder vil forvente at dette er dokumenteret og systematisk styret — ikke ad hoc.
Artikel 21(2)(d) og Artikel 22 — Forsyningskædesikkerhed. Kommunens leverandørers systemer er en del af kommunens sikkerhedspostur. Mange kommunale systemer hostes af leverandører som KMD, Systematic, ESDH-udbydere og KOMBIT-tilknyttede systemer. Disse bruger certifikater på kommunens domæner. Under NIS2 er kommunen ansvarlig for at have overblik over denne forsyningskæde.
Hvilke systemer er i scope?
En typisk kommune har TLS-certifikater på et bredt antal systemer. Her er de kategorier der oftest er i scope for NIS2:
- Borgervendte selvbetjeningsløsninger — Digital Post, ansøgningsskemaer, booking-systemer, borger.dk-integrationer
- Intranet og medarbejderportaler — systemer der kræver TLS internt i kommunens netværk
- Fagsystemer — ESDH, EOJ, KSD, hjemmeplejesystemer og andre fagsystemer med webadgang
- KOMBIT-integrationer med TLS-afhængigheder — FK-adgangsstyring, NemLog-in, serviceplatform-services
- Leverandørhosted infrastruktur — systemer hostet eksternt men tilgængelige under kommunens domæne
- Administrative systemer — HR, økonomi, budgetsystemer med webadgang
Certifikatudløb som hændelse: rapporteringspligten under Artikel 23
Artikel 23 kræver at kommunen rapporterer væsentlige hændelser til tilsynsmyndigheder inden for stramme tidsfrister: 24 timer for tidlig varsel og 72 timer for en egentlig hændelsesnotifikation.
Et certifikatudløb der forårsager at borgere ikke kan tilgå selvbetjeningsløsninger, at medarbejdere ikke kan tilgå fagsystemer, eller at kommunikation afbrydes, kan kvalificere som en væsentlig hændelse. Definitionen er bred og inkluderer "forstyrrelser af tjenester" der påvirker "væsentligt antal brugere".
Uden et certifikatregister kan det alene tage 2-4 timer at identificere at et certifikatudløb er rodårsagen til en nedetid og forstå omfanget — tid kommunen ikke har i en hændelsessituation, og tid der tæller med i de 24 timer I har til at rapportere.
Hvad tilsynet vil spørge om
Baseret på NIS2-implementeringen i andre EU-lande og CFCS's hidtidige vejledninger er det sandsynligt at tilsynet ved en inspektion vil efterspørge:
- Et aktivregister over kommunens informationssystemer og de certifikater de bruger
- Dokumentation for at certifikater overvåges og fornys rettidigt
- En proces for hvad der sker når et certifikat er ved at udløbe
- Dokumentation for leverandørers certifikatstyring (forsyningskæde)
- Historik over eventuelt udløbne certifikater og hvad der skete
Tre prioriterede tiltag til at komme i gang
For kommuner der ikke allerede har systematisk certifikatstyring er der tre prioriterede tiltag:
1. Opbyg et komplet certifikatregister. Kortlæg alle kommunens domæner og underdomæner — inkl. leverandørers systemer der kører på kommunens domæner. Et automatiseret scanningsværktøj er den eneste praktiske måde at sikre at registret er komplet og opdateret.
2. Implementér tidlig alarmering. Advarsler 30 dage frem er ikke nok i en kommunal kontekst. Leverandørdialoger, udbudsregler og ændringsprocesser kræver at I ser problemerne komme 60-90 dage i forvejen.
3. Generér revisionsdokumentation løbende. Dokumentation skabt reaktivt til et tilsyn er sværere at bruge og leder til spørgsmål om om det er repræsentativt. Automatisk genererede rapporter over certifikatstatus og hændelseslog er mere troværdige.
Hvad CertControl leverer til kommunens NIS2-compliance
De tre prioriterede tiltag ovenfor — komplet certifikatregister, tidlig alarmering og løbende revisionsdokumentation — er præcis hvad CertControl er bygget til at levere for kommuner:
- Komplet register inkl. leverandørers systemer under kommunens domæner. CertControl forespørger Certificate Transparency-logs og finder automatisk alle certifikater nogensinde udstedt til kommunens domæner — inklusiv systemer hostet af KMD, Systematic, KOMBIT-tilknyttede løsninger og andre leverandører. Registret opdateres løbende uden manuel vedligeholdelse.
- On-premise agent til interne fagsystemer. ESDH, EOJ, hjemmeplejesystemer og andre interne systemer er ikke synlige fra internettet. CertControls on-premise agent installeres bag firewall og scanner disse systemer uden at åbne indgående forbindelser — designet til at overholde kommunale IT-sikkerhedspolitikker. Interne certifikater indgår i det samme register og alarmsystem som de eksternt tilgængelige.
- Advarsler 60-90 dage frem til de rette modtagere. Tærskler konfigureres per certifikat. For leverandørhostede systemer kan du sætte advarsler til at udløse 90 dage i forvejen — tid nok til leverandørdialog, eventuelle udbudsprocesser og ændringsanmodninger. Advarsler routes til navngivne ejere, ikke en fælles postkasse.
- Revisionsdokumentation der bygges løbende, ikke reaktivt. CertControl genererer automatisk executive-rapporter, driftsrisikorapporter og udløbsprognoser. Audit-loggen viser hvornår hvert certifikat sidst blev scannet, hvilke advarsler der udløste og hvad der skete — den dokumentation Digitaliseringsstyrelsen og CFCS forventer at se, og som ikke kan rekonstrueres baglæns.
- Forsyningskæde-dokumentation til Artikel 21(2)(f). Listen over overvågede leverandørcertifikater og alarmhistorikken udgør konkret bevis for at forsyningskædesikkerhed ikke blot er beskrevet i en politik, men aktivt spores i drift.