Software skal være bygget, så virkningen af en hændelse bliver mindst mulig, når noget først er gået galt. Forordningen placerer kravet som bilag I, del I, nr. 2, litra k, og det handler om, hvad der sker efter et brud.
Fra 11. december 2027 skal fabrikanten kunne vise, hvilke mekanismer der begrænser skaden, og hvorfor netop de er valgt.
Ordlyden
Litra k kræver, at design, udvikling og produktion sigter mod at mindske virkningen af en hændelse ved hjælp af passende mekanismer og teknikker til begrænsning af udnyttelsen.
Teksten forudsætter, at noget kan gå galt. En sårbarhed bliver fundet og udnyttet, et modul opfører sig forkert, eller en komponent bliver kompromitteret. Spørgsmålet er, hvor langt skaden kan brede sig derfra.
Forordningen nævner ingen bestemte teknikker. Hvilke mekanismer der er passende, afgøres i risikovurderingen, sådan som det gælder for alle punkterne i nr. 2.
Afgrænsningen til nabokravene
Det er let at blande litra k sammen med andre krav. Adgangskontrol i litra d handler om, hvem der må komme ind. Begrænsning af angrebsflader i litra j handler om, hvad der står åbent. Litra k handler om det, der sker bagefter, når nogen eller noget alligevel er kommet ind et sted.
Den skelnen er nyttig i en gennemgang, fordi den giver hvert krav sine egne kontrolpunkter. Et produkt kan have stærk adgangskontrol og en lille angrebsflade og alligevel lade én fejl brede sig til hele systemet.
Litra h er et selvstændigt krav ved siden af litra k. Det handler om tilgængelighed: at væsentlige og grundlæggende funktioner bevares, også efter en hændelse, blandt andet med værn mod denial of service-angreb. Adskillelsen i litra k kan støtte det krav, men den opfylder det ikke af sig selv.
Hvor skillelinjerne går i software
Kilderne nævner ikke moduler, plugins eller lejere ved navn. De tre er vores tolkning af, hvor litra k typisk bliver relevant i et softwareprodukt. Kommissionens FAQ nævner sandboxing eller isolering af meget kritiske komponenter som en mulig handling, når komponenter integreres. Det er en mulighed, ikke et krav.
Moduler. Kører alle dele af produktet med de samme rettigheder i den samme proces? Kan en fejl i et modul, der læser filer fra brugeren, give adgang til modulet, der holder nøglerne? Adskillelse i processer med hver sine rettigheder er et kendt greb.
Plugins og udvidelser. Tillader produktet kode fra andre? Hvad kan den kode nå? Kører den med produktets fulde rettigheder, eller er den afgrænset til det, den skal bruge?
Lejere. Har produktet flere kunder eller organisationer i samme installation? Hvad forhindrer, at en kompromitteret lejer når en andens data? Bemærk, at ren SaaS kan ligge uden for forordningen. Litra k bliver relevant for de dele, der er en del af produktet, for eksempel en installeret server eller fjerndatabehandling, der hører til produktet.
Komponenter fra tredjepart. Et bibliotek, der fortolker komplekse filformater, er et klassisk sted for sårbarheder. At køre det i en afgrænset proces kan begrænse virkningen af en fejl i det. FAQ’en peger netop på isolering af meget kritiske komponenter.
Rettigheder
Mindst mulige rettigheder er en anden mekanisme, der ofte nævnes i den sammenhæng. Kører produktet som administrator, fordi det var lettest under udviklingen? Har en servicekonto adgang til hele databasen, når den kun skal læse én tabel? Hver for meget givet rettighed gør virkningen af en hændelse større. Kravet nævner ikke rettigheder direkte. Det er vores tolkning, at de hører under “mekanismer og teknikker til begrænsning af udnyttelsen”.
Begrundelsen i risikovurderingen
Gennemgangen leder efter sammenhængen mellem risikovurderingen og arkitekturen. For hver skillelinje, vurderingen nævner, bør der være en mekanisme, og for hver mekanisme en begrundelse. Hvor der ikke er en skillelinje, bør vurderingen forklare, hvorfor det er forsvarligt.
Et lille kommandolinjeværktøj uden netværk og uden plugins kan have en kort begrundelse. En platform med udvidelser fra tredjepart og mange lejere har brug for en udførlig.
Hvordan en gennemgang prøver det
En almindelig fremgangsmåde er at lade, som om én del er kompromitteret, og følge, hvad den del kan nå. Gennemgangen ser i arkitekturbeskrivelsen og i den installerede kopi på, hvilke processer der kører med hvilke rettigheder, hvad et plugin har adgang til, og hvordan data for forskellige lejere er adskilt. Det er en øvelse på papir og i en installeret kopi, ikke et angreb. Metoden er praksis. Pr. november 2026 var der ingen harmoniseret standard til forordningen med reference i EU-Tidende, som beskriver, hvordan litra k skal prøves.
Hvad det kræver, og hvad det koster at lade være
Det kræver en arkitektur, hvor skillelinjerne er tegnet med vilje, en begrundelse for dem i risikovurderingen og en beskrivelse, der kan sammenholdes med det, produktet faktisk gør.
Uden skillelinjer bliver hver sårbarhed en sårbarhed i hele produktet. Det gør også sårbarhedshåndteringen tungere, fordi alvoren af hvert fund bliver større, end den behøvede at være.
Det skal I lade være med
- At lade alle dele køre med samme rettigheder af bekvemmelighed · det giver en fejl adgang til alt.
- At give plugins produktets fulde rettigheder uden vurdering · kode fra andre er en risiko, I bærer.
- At blande litra k sammen med adgangskontrol · det ene handler om at holde ude, det andet om at begrænse.
Det skal auditten kunne vise
- ☐ En arkitekturbeskrivelse med skillelinjer mellem moduler, plugins, lejere og kritiske komponenter.
- ☐ Risikovurderingens begrundelse for de valgte mekanismer.
- ☐ En oversigt over rettigheder for processer og servicekonti.
- ☐ Resultat af en gennemgang af, hvad en kompromitteret del kan nå.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, bilag I, del I, nr. 2, litra d, h, j og k, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.4.2, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Vælg det modul i jeres produkt, der oftest behandler data udefra, og skriv op, hvad det kan nå, hvis det bliver kompromitteret.
Læs også: Adgangskontrol i softwaren · Begrænsning af angrebsflader
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
