Softwaren skal beskytte sig selv mod uautoriseret adgang med passende kontrolmekanismer og give melding, når nogen muligvis har fået adgang uden lov. Reglen er litra d i bilag I, del I, nr. 2. Den skal følges fra 11. december 2027 og handler om de funktioner, kunden får med produktet.
Det er adgangskontrollen i selve softwaren, der er tale om. Hvordan en organisation styrer sine egne medarbejderes adgange, er et andet emne.
Ordlyden og det, den ikke siger
Litra d kræver beskyttelse mod uautoriseret adgang ved hjælp af passende kontrolmekanismer, herunder, men ikke begrænset til, systemer til autentificering, identitet eller adgangsstyring. Produktet skal også give melding om mulig ikkeautoriseret adgang.
Teksten nævner ingen bestemte teknikker. Der står intet om flerfaktorgodkendelse, adgangskodelængde eller bestemte protokoller. Kravene i del I er mål- og teknologineutrale, skriver Kommissionen i sin FAQ, og den konkrete løsning afhænger af risikovurderingen. Den, der påstår, at forordningen kræver en bestemt login-metode, læser mere ind i teksten, end der står.
Risikovurderingen afgør, hvor meget litra d fylder i et konkret produkt. Et kommandolinjeværktøj uden brugere eller netværksadgang kan have en kort begrundelse. En webapplikation med administratorer og eksterne integrationer har brug for en lang.
Hvor adgangen findes i et softwareprodukt
Når en gennemgang prøver litra d, ser den på alle de veje, der fører ind i produktet. Det følgende er vores tolkning af, hvad “passende kontrolmekanismer” dækker i software. Lovteksten og Kommissionens vejledning nævner ikke punkterne enkeltvis.
- Brugerlogin: hvordan brugeren beviser sin identitet, og hvordan sessioner udløber.
- Roller og rettigheder: om produktet skelner mellem almindelige brugere og administratorer, og om en bruger kan nå data eller funktioner, rollen ikke giver.
- Servicekonti: konti, der bruges af andre systemer, og om de har flere rettigheder end nødvendigt.
- API-nøgler og tokens: hvordan de udstedes, begrænses, gemmes og tilbagekaldes.
- Administrationsflader: om de kan nås udefra, og hvordan de er beskyttet.
For hvert punkt spørger gennemgangen, om risikovurderingen har taget stilling, og om den installerede kopi gør det, vurderingen siger. Et punkt, der ikke er nævnt i vurderingen, er i sig selv et fund, uanset hvor godt det er beskyttet i koden.
Melding om mulig uautoriseret adgang
Den anden halvdel af litra d overses ofte. Produktet skal give melding om mulig ikkeautoriseret adgang. Forordningen siger ikke, til hvem eller hvordan. Et naturligt bud er, at den, der har ansvaret for installationen, kan se mislykkede login-forsøg, nye enheder eller usædvanlige mønstre, men det er en tolkning.
Meldingen hænger tæt sammen med kravet om sikkerhedslogning i litra l. Logningen registrerer. Meldingen sørger for, at nogen opdager det.
Ændringer i adgangsfunktioner
Kommissionens vejledning bruger adgangsfunktioner som eksempel på en ændring, der kan være væsentlig. En “husk mig”-funktion, der gemmer autentificeringstokens lokalt, introducerer risiko for tyveri af tokens og kapring af sessioner, og Kommissionen regner den i sit eksempel som en væsentlig ændring. Pointen for en gennemgang er, at adgangskontrollen vurderes igen, hver gang den ændres.
Klassen er noget andet end kravet
Software til identitetsstyring og styring af privilegeret adgang står i bilag III, klasse I, som vigtige produkter. Det ændrer, hvilken procedure produktet skal igennem. Det ændrer ikke kravet i litra d, som gælder for alt software, hvor det er relevant. Har jeres app et login-modul, gør det ikke appen til et vigtigt produkt.
Hvad gennemgangen gør i praksis
En almindelig fremgangsmåde er at oprette brugere med forskellige roller i en installeret kopi og prøve, om de kan nå det, de ikke skal. Gennemgangen ser også på, hvordan API-nøgler opfører sig, når de tilbagekaldes, og om administrationsfladen svarer fra et netværk, hvor den ikke burde. Hvordan organisationen bag styrer sine egne adgange, hører under den almene sikkerhedsaudit af en organisation, og de tekniske kontrolpunkter i driften er beskrevet under teknisk kontrol af adgange i drift.
Når produktet lægger login over på en anden
Mange produkter lader en ekstern identitetsudbyder klare selve login. Det kan være et fornuftigt valg. Produktet har så stadig ansvar for det, der sker efter login: hvilke rettigheder brugeren får, hvordan sessionen holdes, og hvad der sker, når udbyderen ikke svarer. Risikovurderingen bør beskrive udbyderen som en ekstern afhængighed og forklare, hvad produktet selv gør for at beskytte sig. Den beskrivelse er vores tolkning af, hvordan litra d spiller sammen med afhængigheder uden for produktet, og den bør markeres som sådan i dokumentationen.
Hvad det kræver, og hvad det koster at lade være
Det kræver en oversigt over alle adgangsveje i produktet, en stillingtagen til hver i risikovurderingen og en funktion, der gør mulig uautoriseret adgang synlig.
Uden oversigten er det tilfældigt, hvilke veje der er beskyttet. En glemt servicekonto eller en API-nøgle, der aldrig udløber, er den slags fund, der ikke kræver avancerede værktøjer at gøre, og som er svære at forsvare.
Det skal I lade være med
- At love kunder en bestemt login-metode som lovkrav · litra d er teknologineutral.
- At glemme konti, der ikke tilhører mennesker · servicekonti og nøgler er også adgang.
- At logge uden at melde · teksten kræver, at mulig uautoriseret adgang meldes.
Det skal auditten kunne vise
- ☐ En liste over adgangsveje i produktet: login, roller, servicekonti, nøgler og administrationsflader.
- ☐ Risikovurderingens stillingtagen til litra d for hver adgangsvej.
- ☐ En beskrevet og afprøvet funktion, der melder mulig uautoriseret adgang.
- ☐ Vurdering af ændringer i adgangsfunktioner mellem versioner.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, bilag I, del I, nr. 2, litra d, og bilag III, klasse I, nr. 1, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, eksempel 44, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.2.1, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv alle veje ind i jeres produkt op på én side, også dem, der kun bruges af andre systemer.
- Bilag I, del I: softwarens egenskaber krav for krav
- Identitetsstyring, fælles login og flerfaktorsoftware: klasse I
Læs også: Sikkerhedslogning som produktkrav · Når noget går galt inde i softwaren
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
