Software skal leveres sikker som standard, så en ny installation er beskyttet, før brugeren har rørt en eneste indstilling. Det er litra b under nr. 2 i bilag I, del I, som tager virkning den 11. december 2027 og omfatter muligheden for at nulstille produktet til den oprindelige tilstand.
Kravet handler om de valg, I træffer, før softwaren forlader huset. Hvad kunden siden gør med indstillingerne, er en anden sag. På engelsk kaldes princippet ofte secure by default, og det er det udtryk, mange kunder bruger i deres spørgsmål.
Ordlyden
Litra b kræver, at produkter gøres tilgængelige med en sikker konfiguration som standard. Der er én undtagelse i selve teksten. Fabrikanten og en erhvervsbruger kan aftale noget andet for et skræddersyet produkt. Og kravet rummer udtrykkeligt muligheden for at nulstille til den oprindelige tilstand.
Som alle punkter i del I, nr. 2, bygger kravet på cybersikkerhedsrisikovurderingen og gælder, hvor det er relevant. Kommissionens FAQ siger, at standardkonfigurationen vurderes i lyset af det tilsigtede formål, den rimeligt forudsigelige anvendelse og risikovurderingen. Hvad der er sikkert, afhænger altså af, hvad produktet bruges til.
Skræddersyet eller standardprodukt
Undtagelsen bliver ofte strakt for langt. Ifølge FAQ’en kan kun to krav fraviges ved udtrykkelig aftale med en bestemt erhvervsbruger om et skræddersyet produkt: den sikre standardkonfiguration og kravet i del II, nr. 8, om sikkerhedsopdateringer uden betaling.
Små tilpasninger gør ikke et standardprodukt skræddersyet. Kommissionen bruger to eksempler: et kundestyringssystem, der sælges bredt, og en platform, som kunden former med udvidelser og programmeringsgrænseflader. Den tekniske dokumentation skal rumme bevis for, at produktet faktisk er skræddersyet, hvis I bruger undtagelsen.
Komponenter leveret til integration
Sælger I et bibliotek eller en anden komponent, gælder kravet kun den konfiguration, komponenten leveres med. Hvordan integratoren siden indstiller den, er integratorens ansvar. Kommissionens eksempel er et kryptografisk bibliotek, der leveres med usikre eller forældede algoritmer slået fra og validering af certifikater slået til.
Brugeroplysningerne
Bilag II, nr. 8, litra a, kræver, at oplysningerne til brugeren indeholder de nødvendige foranstaltninger ved første ibrugtagning og i hele levetiden. Hvis brugeren skal gøre noget ved første opstart for at holde produktet sikkert, skal det altså stå der. Det er en del af kravet at få det skrevet ned, og det hænger sammen med den standard, I har valgt.
Hvad en gennemgang ser efter
Forordningen nævner ikke standardkonti eller forudindstillede adgangskoder. De er eksempler på det, en gennemgang typisk kigger efter, fordi de er klassiske svagheder i en ny installation.
En almindelig fremgangsmåde er at installere en frisk kopi af den version, der frigives, på en ren maskine og se, hvad den gør uden indgreb. Spørgsmålene lyder omtrent sådan:
- Hvilke porte og tjenester er åbne efter installationen, og hvorfor?
- Findes der konti med kendte eller fælles adgangskoder, eller tvinges brugeren til at vælge sin egen ved første opstart?
- Hvilke funktioner er slået til, som ikke alle brugere har brug for, for eksempel fjernadministration, fejlsøgning eller eksempeldata?
- Er krypteret forbindelse standard, eller skal den vælges til?
- Virker nulstillingen, og bringer den produktet tilbage til den samme sikre tilstand?
Svarene holdes op mod risikovurderingen. Står en funktion åben som standard, skal vurderingen forklare, hvorfor det er forsvarligt for den tilsigtede brug. Mangler forklaringen, er det et fund, også når funktionen i sig selv er harmløs.
Kontrollen af en installeret kopi er praksis og ikke et lovkrav. Hvordan prøven skal udføres, er heller ikke fastlagt i en harmoniseret standard. Vi har ikke set en offentliggjort i EU-Tidende pr. november 2026.
Standardindstillinger over tid
Kravet gælder hver version, I bringer i omsætning. Får en ny version en ny funktion, der er slået til som standard, hører den med i vurderingen. Hvordan standardindstillinger holdes i drift hos den, der bruger softwaren, behandles under standardindstillinger i den daglige drift. Her er synsvinklen fabrikantens.
Når kunden vil have det anderledes
Mange erhvervskunder beder om at få en funktion slået til fra start, fordi det sparer dem tid. Det kan I godt imødekomme. Spørgsmålet er, hvem der træffer valget. Slår kunden selv funktionen til efter installationen, er standarden stadig jeres sikre udgangspunkt. Leverer I en særlig pakke, hvor funktionen er slået til, og produktet ikke er skræddersyet, bør den pakke vurderes, som om den var en standard. Det er vores tolkning af, hvordan undtagelsen for skræddersyede produkter afgrænser kravet.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at nogen ejer standardkonfigurationen som en beslutning, og at den beslutning er skrevet ind i risikovurderingen for hver funktion, der er slået til. Det kræver en nulstilling, der er testet.
Uden det bliver standarden et biprodukt af udviklernes bekvemmelighed. En åben fejlsøgningsfunktion eller en fælles adgangskode i en ny installation er let at finde for en myndighed, en kunde eller en angriber, og den er svær at forklare bagefter.
Det skal I lade være med
- At kalde et standardprodukt skræddersyet · undtagelsen gælder kun et produkt lavet til én erhvervsbruger.
- At lægge sikkerheden over i en installationsvejledning, ingen læser · standarden skal være sikker i sig selv.
- At glemme nulstillingen · den er en del af kravets ordlyd.
Det skal auditten kunne vise
- ☐ En beskrivelse af standardkonfigurationen for den frigivne version.
- ☐ En begrundelse i risikovurderingen for hver funktion, port eller konto, der er aktiv som standard.
- ☐ Brugeroplysninger om foranstaltninger ved første ibrugtagning efter bilag II, nr. 8, litra a.
- ☐ Bevis for, at nulstillingen er afprøvet.
- ☐ Ved skræddersyet produkt: aftalen og beviset for, at produktet er skræddersyet.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, bilag I, del I, nr. 2, litra b, og bilag II, nr. 8, litra a, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.2.4 og 4.2.5, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Installér den seneste version på en ren maskine, og skriv op, hvad der er åbent og slået til, før nogen har ændret noget.
Læs også: Begrænsning af angrebsflader · Adgangskontrol i softwaren
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
