Cyber Resilience

Styresystemer, hypervisorer, containerafviklere, firewalls og indtrængningsdetektion: platforms- og sikkerhedssoftware i klasse I og II

Styresystemer, hypervisorer, containerafviklere, firewalls og indtrængningsdetektion: platforms- og sikkerhedssoftware i klasse I og II

Styresystemer står i klasse I. Hypervisorer, containerafviklere, firewalls og systemer til opdagelse og forebyggelse af indtrængen står i klasse II, hvor en vurdering med tredjepart altid er nødvendig, med en enkelt undtagelse for open source. Et produkt med et indbygget styresystem eller en indbygget firewall bliver ikke selv et styresystem eller en firewall.

Kategorierne rammer dem, der udgiver tilpassede distributioner, platforme til virtualisering og containere og sikkerhedsprodukter. Kravene gælder fra 11. december 2027.

Klasse I, punkt 11: operativsystemer

Gennemførelsesforordning (EU) 2025/2392 beskriver operativsystemer som software, der udgør en abstrakt grænseflade til hardwaren og styrer kørslen af anden software. Det omfatter forvaltning af ressourcer, planlægning, input og output, dataforvaltning og en grænseflade for applikationer. Kategorien omfatter realtidsoperativsystemer, generelle operativsystemer og operativsystemer til særlige formål.

Kommissionens vejledning bruger i eksempel 57 et produkt, hvis væsentligste funktionalitet er netop den. Betragtning 4 i gennemførelsesforordningen siger, at et styresystem med en lommeregner, en simpel grafikeditor eller browserfunktioner stadig er et styresystem. Ekstra funktioner flytter det ikke ud af kategorien.

For et softwarehus, der udgiver en tilpasset distribution, er spørgsmålet, om distributionen selv er et operativsystem, eller om den er en samling programmer oven på et andet. Udgiver I et færdigt system, som kunderne installerer og kører software på, peger det mod kategorien. Det er vores læsning af beskrivelsen og ikke en afgørelse fra Kommissionen.

Klasse II, punkt 1: hypervisorer og container runtime-systemer

Gennemførelsesforordningen beskriver hypervisorer af type 1, type 2 og hybride hypervisorer, også indlejret virtualisering. Den nævner container runtime-systemer, der styrer udførelse og livscyklus for containere på ét værtsoperativsystem.

Det er altså selve afviklingen, der er kategorien. Et værktøj, der bygger containerbilleder, eller en tjeneste, der orkestrerer containere på tværs af mange værter, er ikke nævnt i beskrivelsen. Om et sådant værktøj alligevel hører til, afhænger af dets væsentligste funktionalitet. Den vurdering bør skrives ned, fordi grænsen er snæver. Notatet bør også sige, hvilken version af værktøjet det gælder, så det kan tages op igen, hvis værktøjet senere får sin egen afviklingsdel.

Klasse II, punkt 2: firewalls og systemer til opdagelse og forebyggelse af indtrængen

Beskrivelsen omfatter netværksfirewalls og applikationsfirewalls, fx firewalls til webapplikationer, filtre og anti-spam-gateways. Den omfatter også netværksbaserede og værtsbaserede systemer til opdagelse og forebyggelse af indtrængen.

Kategorien er bredere, end navnet antyder. En anti-spam-gateway eller en firewall til webapplikationer kan være et klasse II-produkt, selv om den ikke ligner en klassisk netværksfirewall. Kommissionens eksempel 61 med en sikkerhedssuite placerer modulet til indtrængningsdetektion i klasse II, når det sælges for sig.

Det indbyggede bliver ikke hovedsagen

Gennemførelsesforordningens betragtning 4 og vejledningens eksempel 63 bruger en router med indbygget firewall. Routeren har stadig routerens væsentligste funktionalitet og klassificeres som router. Eksempel 58 bruger samme tankegang på en telefon, hvor både styresystem og adgangskodeadministrator er bygget ind. Telefonen anses generelt ikke for at være nogen af delene.

Vejledningen (punkt 152) tilføjer, at når et produkt integrerer en funktion, der selv er et vigtigt eller kritisk produkt, er det helhedens væsentligste funktionalitet, der tæller. For et softwarehus betyder det, at en forretningsapplikation med en indbygget applikationsfirewall klassificeres efter forretningsfunktionen. Firewallen skal stadig med i risikovurderingen. Se mere i artiklen om indlejrede komponenter i en app.

Hvad klasse II betyder

Klasse II kræver altid en vurdering med tredjepart: modul B og C, modul H eller en europæisk cybersikkerhedscertificeringsordning på mindst niveauet “betydeligt” (artikel 32, stk. 3). Kommissionens vejledning (punkt 148) bekræfter, at egenkontrol efter modul A ikke er en mulighed, uanset om der findes harmoniserede standarder.

Den eneste undtagelse er open source-software, der stilles til rådighed uden betaling. Den kan efter artikel 32, stk. 5, følge samme vej som standardkategorien, forudsat at den tekniske dokumentation offentliggøres.

For et softwarehus med en kommerciel hypervisor eller firewall er et bemyndiget organ derfor en del af planen. Hvordan forberedelsen ser ud, står i klar til det bemyndigede organ.

Klasse I-styresystemer og standarderne

For et styresystem i klasse I er modul A kun en mulighed, hvis harmoniserede standarder, fælles specifikationer eller en certificeringsordning er anvendt fuldt. Vi har ikke set en reference til en harmoniseret standard efter CRA i EU-Tidende, da vi kiggede i november 2026. Planlægningen gennemgås i klasse I uden harmoniseret standard.

Hvad det kræver, og hvad det koster at lade være

Det kræver en skrevet klassificering af hver platform og hvert sikkerhedsprodukt med henvisning til beskrivelsen i gennemførelsesforordningen, og for klasse II en plan med et bemyndiget organ.

Opdager et softwarehus sent, at dets produkt er klasse II, kan det ikke nå at gennemføre en vurdering med tredjepart, før kravene gælder. Egenkontrol alene er ingen lovlig vej til markedet for et klasse II-produkt efter 11. december 2027.

Det skal I lade være med

  • At regne med modul A for et klasse II-produkt · artikel 32, stk. 3, kræver tredjepart.
  • At klassificere en forretningsapp efter dens indbyggede firewall · helhedens væsentligste funktionalitet afgør.
  • At overse anti-spam-gateways og webapplikationsfirewalls · de står i beskrivelsen af punkt 2.

Det skal auditten kunne vise

  • ☐ En skrevet klassificering med henvisning til klasse I, punkt 11, eller klasse II, punkt 1 eller 2.
  • ☐ For klasse II en valgt procedure med tredjepart og en tidsplan.
  • ☐ En vurdering af indbyggede sikkerhedsfunktioner i risikovurderingen.
  • ☐ Begrundede afgrænsninger for værktøjer tæt på kategorierne.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Find ud af, om nogen af jeres produkter afvikler andre programmer, containere eller virtuelle maskiner, eller filtrerer trafik som hovedopgave.

Læs også: Vigtigt produkt eller ej? · Efter attesten

→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal jeres software gennemgås?

Skriv kort, hvilket produkt det drejer sig om, og hvad der sætter det i gang. Så vender jeg tilbage. Gennemgangen er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.