En kodebase, der er designet længe før december 2027, kan efter Kommissionens vejledning bringes i omsætning efter datoen på grundlag af en aktuel risikovurdering, der viser, at produktet har tilstrækkelige foranstaltninger. Fabrikanten skal ikke genskabe gammel design- og testdokumentation, men sårbarhedshåndteringen, overensstemmelsesvurderingen, erklæringen og brugeroplysningerne skal være på plads.
Det er den situation, de fleste softwarehuse står i. Vejledningens afsnit 2.7 er skrevet til den, men dens eksempel handler om hardware, og anvendelsen på software er derfor vores tolkning.
Udgangspunktet
Kravene i forordning (EU) 2024/2847 gælder fra 11. december 2027 for produkter, der bringes i omsætning fra den dato. For selvstændig software er det den enkelte version, der bringes i omsætning, og en ny version udbudt efter datoen er omfattet, selv om koden bag den er mange år gammel. Datoreglen for versioner er forklaret i artiklen om første udbud.
Kommissionens tjenestegrenes FAQ (6.4 og 7.2, vejledende) understreger, at forordningen gælder det enkelte produkt og ikke typen. Med routere som eksempel siger FAQ’en, at nye enheder af en type, der ikke overholder kravene, ikke må bringes i omsætning efter datoen.
Hvad Kommissionen ikke kræver
I Kommissionens vejledning, der ikke binder nogen, siger punkt 33 og 34, at fabrikanten skal lave en risikovurdering efter artikel 13, stk. 2, for at afgøre, hvilke krav i bilag I, del I, der gælder, og hvordan de er gennemført. Overholdelse kræver ikke nødvendigvis redesign. Viser vurderingen, at produktet allerede har passende og effektive foranstaltninger, kan fabrikanten bygge på dem.
Punkt 37 og 38 tilføjer, at beviskravet i overensstemmelsesvurderingen ikke skal forstås som et krav om testresultater fra den oprindelige design- og udviklingsfase. De nødvendige test kan grupperes på tværs af produktfamilier. Eksempel 12 med en mikrocontroller siger det ligeud. Fabrikanten skal ikke genskabe historisk design- eller testdokumentation.
Når risikovurderingen kommer bagefter
Artikel 13, stk. 2, forudsætter, at risikovurderingen bruges i planlægning, design og udvikling. For en kodebase, der blev designet, før forordningen fandtes, er det umuligt. Vejledningens punkt 35 og 36 løser det. Kan fabrikanten ikke vise, hvordan risikovurderingen blev brugt i design og udvikling, skal bestemmelsen forstås som en pligt til at lave en risikovurdering nu og på den baggrund vise, at produktet har tilstrækkelige foranstaltninger.
For et nyt produkt, der designes efter i dag, gælder den lempelse efter vores læsning ikke. Her er det et fund, hvis risikovurderingen først skrives, når koden er færdig.
Hvad der skal være på plads alligevel
Punkt 35, 36 og 39 nævner det, der ikke lempes.
- Overensstemmelsesvurdering, EU-overensstemmelseserklæring og CE-mærkning · Skal foreligge, før produktet bringes i omsætning
- Sårbarhedshåndtering efter bilag I, del II · Fabrikanten skal vise, hvordan den opfyldes
- Ajourføring af risikovurderingen · Vurderingen skal holdes ajour i supportperioden
- Brugeroplysninger efter artikel 13, stk. 18 · Brugeren skal have oplysningerne i bilag II
Sårbarhedshåndteringen er typisk den største opgave for en ældre kodebase. Beskrivelsen af processerne i den tekniske dokumentation skal efter bilag VII, nr. 2, bl.a. omfatte softwarekomponentlisten, og for kode med mange års afhængigheder kan det tage tid at få den på plads.
Forbeholdet for software
Vejledningens eksempel 12 handler om en mikrocontroller, altså hardware. Punkt 33 til 39 er formuleret generelt og nævner ikke hardware som en betingelse. Vi læser dem derfor som gældende for software på samme måde. Det er en tolkning, og en markedsovervågningsmyndighed kan se anderledes på det, indtil der er praksis.
Et tænkt forløb
Et softwarehus har en kodebase fra 2015, som skal udkomme i en ny version i 2028. Forløbet kunne se sådan ud. Først en risikovurdering af produktet, som det er i dag, med formål, brug og miljø. Dernæst en gennemgang af kravene i bilag I, del I, hvor hvert krav enten er dækket af eksisterende foranstaltninger, rettes eller begrundes som ikke relevant. Så en opbygning af sårbarhedshåndteringen og komponentlisten. Til sidst test af det nuværende produkt, dokumentation, erklæring og brugeroplysninger. Forløbet er tænkt og ikke en skabelon.
Hvad det kræver, og hvad det koster at lade være
Det kræver en ærlig risikovurdering af produktet, som det er, og tid til at bygge sårbarhedshåndteringen op. Begyndes arbejdet i 2027, er der kort tid til at rette det, vurderingen finder.
Lader I være, kan den første version efter december 2027 ikke bringes i omsætning med en erklæring, der holder.
Det skal I lade være med
- At begynde et redesign, før risikovurderingen har vist behovet · vejledningen kræver ikke redesign i sig selv.
- At lede efter gamle testrapporter · historisk testdokumentation skal ikke genskabes.
- At regne lempelsen for gældende for sårbarhedshåndteringen · bilag I, del II, skal opfyldes fuldt.
Det skal auditten kunne vise
- ☐ En aktuel risikovurdering af den ældre kodebase.
- ☐ For hvert krav i bilag I, del I, hvordan det er dækket, rettet eller begrundet.
- ☐ En fungerende sårbarhedshåndtering med komponentliste.
- ☐ Test af produktet, som det er nu, og den markerede tolkning for software.
Kilder
- Forordning (EU) 2024/2847, dansk tekst, artikel 13, stk. 2 og 18, og bilag I, læst 13. november 2026 i Publikationskontorets kopi.
- Kommissionens vejledning C(2026) 5252, punkt 33 til 39 og eksempel 12, ikke bindende, læst 13. november 2026.
- Kommissionens tjenestegrenes FAQ om CRA, version 1.4, FAQ 6.4 og 7.2, vejledende, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Lav en risikovurdering af jeres ældste aktive kodebase, som den er i dag, og se, hvor langt den er fra bilag I.
Læs også: Versioner fra før 11. december 2027 · Kravet kan ikke opfyldes fuldt
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
