Software skal beskytte data, kommandoer, programmer og konfigurationer mod ændringer, brugeren ikke har givet lov til, og give melding om korruption. Det er litra f i bilag I, del I, nr. 2. Fabrikanten skal leve op til det fra 11. december 2027.
Integritet i software bliver tit sat lig med signerede opdateringer. Litra f rækker videre. Den handler om alt det, produktet stoler på, mens det kører.
Ordlyden
Teksten kræver, at produktet beskytter integriteten af de data, produktet gemmer, sender eller på anden vis behandler, hvad enten det er personoplysninger eller andre data, og af kommandoer, programmer og konfigurationer mod enhver manipulation eller ændring, som brugeren ikke har givet tilladelse til. Produktet skal også give melding om korruption.
Fire genstande nævnes altså: data, kommandoer, programmer og konfigurationer. Og to handlinger: beskytte og melde. Hvor langt beskyttelsen skal gå, bestemmes af risikovurderingen.
Fire kontrolpunkter
De fire punkter nedenfor er vores måde at dele ordlyden op på, så den kan efterprøves. Opdelingen er praksis. Selve ordene kommer fra litra f.
1. Konfigurationsfiler. Hvor ligger produktets indstillinger, og hvem kan ændre dem? Kan en anden proces eller en bruger uden rettigheder skrive i filen? Opdager produktet det, hvis filen er ændret uden om produktets egne funktioner? Kommissionen nævner i sin vejledning kontrol af integriteten af konfigurationsændringer som eksempel på en foranstaltning i produktet. Det er et eksempel, ikke et krav.
2. Lokale data. Gemmer produktet data på disken, i en lokal database eller i en cache, som det senere stoler på? Hvad sker der, hvis data er ændret? Et tænkt eksempel: en klient gemmer en liste over tilladte servere lokalt. Kan listen ændres, kan klienten sendes et andet sted hen.
3. Kommandoer udefra. Tager produktet imod kommandoer fra en server, en administrationskonsol eller en anden enhed? Vejledningen nævner kryptografisk autentificering af fjernkommandoer som eksempel på en foranstaltning mod risici fra systemer uden for produktet. Spørgsmålet er, om produktet kan skelne en ægte kommando fra en forfalsket.
4. Meldingen. Litra f slutter med, at produktet skal give melding om korruption. Når produktet opdager, at noget er ændret uden lov, hvad gør det så? Stopper det, går det tilbage til en kendt tilstand, eller fortsætter det i stilhed? Og får nogen besked?
Programmer og opdateringer
Ordet “programmer” i litra f dækker også produktets egen kode. Integriteten af selve opdateringskanalen hører sammen med kravet om mekanismer til sikker distribution af opdateringer (bilag I, del II, nr. 7). Det emne har sin egen artikel om sikker distribution. Signering af opdateringer er ikke nævnt i lovteksten som krav. Det er en udbredt metode til at opfylde kravet, og den bør vurderes der.
Denne artikel holder sig til det, der sker, efter at produktet er installeret.
Hvordan en gennemgang prøver det
En almindelig fremgangsmåde er at ændre ting i en installeret kopi, som brugeren ikke ville have godkendt, og se, hvad der sker. Gennemgangen redigerer en konfigurationsfil uden om produktet, ændrer en post i den lokale database, sender en kommando uden gyldig autentificering og udskifter en fil i installationsmappen. For hvert forsøg noteres, om produktet opdager det, og om det melder det.
Resultaterne holdes op mod risikovurderingen. Har vurderingen besluttet, at lokale data ikke kræver beskyttelse, fordi de kun kan ændres af en administrator med fuld adgang til maskinen, kan det være en holdbar begrundelse. Står der ingenting, er det et fund.
Ingen standard foreskriver forsøgene. De er praksis, og indtil harmoniserede standarder ligger i EU-Tidende, hvilket ikke var tilfældet i november 2026, er det fabrikantens egen dokumentation, der skal bære begrundelsen.
Hvem har givet tilladelse?
Ordlyden taler om ændringer, brugeren ikke har givet tilladelse til. Det rejser et spørgsmål i produkter med flere roller. Er det administratoren eller den enkelte bruger, der giver lov? Forordningen svarer ikke. Vores tolkning er, at risikovurderingen bør beskrive, hvem der må ændre hvad, så det kan afgøres, hvornår en ændring er uautoriseret. Det kobler litra f tæt til adgangskontrollen i litra d.
Når produktet har mange installationer
Skala spiller også ind. Et produkt, der styres centralt fra en konsol hos fabrikanten eller hos kundens IT-afdeling, modtager kommandoer, der kan ramme hundredvis af installationer på én gang. En forfalsket kommando har derfor større virkning end en lokal ændring. Det er et argument for, at risikovurderingen giver kommandoer udefra særlig opmærksomhed. Synspunktet er vores, og det er tænkt som et eksempel på, hvordan litra f kan vægtes.
Hvad det kræver, og hvad det koster at lade være
Det kræver en oversigt over de data, filer og kommandoer, produktet stoler på, en beslutning om beskyttelse for hver, og en funktion, der melder, når noget er ændret uden lov.
Uden den oversigt beskytter produktet det, udviklerne tilfældigvis tænkte på. En konfigurationsfil, der kan ændres af alle på maskinen, eller en fjernkommando, der ikke kontrolleres, kan give en angriber kontrol uden at bryde nogen kryptering.
Det skal I lade være med
- At gøre integritet til et spørgsmål om signerede opdateringer alene · litra f nævner også data, kommandoer og konfiguration.
- At lade produktet tie, når det opdager en ændring · meldingen er en del af kravet.
- At regne lokale filer for sikre, fordi de ligger på kundens maskine · den antagelse skal stå i risikovurderingen.
Det skal auditten kunne vise
- ☐ En oversigt over konfiguration, lokale data, kommandoer og programfiler, produktet stoler på.
- ☐ Risikovurderingens stillingtagen til beskyttelse af hver.
- ☐ Resultater af forsøg med uautoriserede ændringer i en installeret kopi.
- ☐ En beskrevet og afprøvet melding om korruption.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, bilag I, del I, nr. 2, litra f, og del II, nr. 7, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 169, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find den konfigurationsfil, jeres produkt læser ved opstart, og prøv, hvad der sker, når den ændres uden om programmet.
Læs også: Fortrolighed · Adgangskontrol i softwaren
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
