Cyber Resilience Act, forordning (EU) 2024/2847, certificerer ikke produkter mod en standard. Den kræver, at ethvert omfattet produkt med digitale elementer opfylder de væsentlige cybersikkerhedskrav i bilag I, og den kræver, at fabrikanten viser det i en teknisk dokumentation ad den overensstemmelsesvurderingsvej, som produktets trin tillader. Bilag I er derfor den liste, alle andre pligter hænger på: Risikovurderingen er en risikovurdering op imod den, den tekniske dokumentation dokumenterer den, det bemyndigede organ kontrollerer den.
Det er to sider i forordningen, og det er værd at have som én tabel. Her er den, med den læsning, der afgør, om et krav kan udelukkes.
Strukturen, og den ene skelnen, der betyder noget
Bilag I har to dele.
Del I, "Cybersikkerhedskrav vedrørende egenskaberne ved produkter med digitale elementer". Punkt 1 er det generelle krav: et cybersikkerhedsniveau, der svarer til risiciene. Punkt 2 opregner tretten konkrete egenskaber, litra a til m, og indledes med ordene "på grundlag af den cybersikkerhedsrisikovurdering, der er omhandlet i artikel 13, stk. 2, og hvor det er relevant". Den formulering gør arbejdet. Et krav i del I, punkt 2, kan udelades for et produkt, men kun på grundlag af risikovurderingen og med begrundelsen skrevet ind i den tekniske dokumentation. "Vi tænkte ikke på det" er ikke en udelukkelse.
Del II, "Krav til håndtering af sårbarheder". Otte krav til, hvad fabrikanten gør i produktets supportperiode, ikke til selve produktet. Ingen af dem er "hvor det er relevant". De gælder for ethvert omfattet produkt, også det mindste.
Den skelnen er det første, der skal være rigtigt i en teknisk dokumentation, og det er den, som den gratis fastlæggelse af anvendelsesområdet ikke dækker, fordi den hører til produktet og ikke til spørgsmålet om, hvorvidt forordningen gælder.
Del I: produktets egenskaber
| Henvisning | Krav | Hvad der skal gælde | Gælder |
|---|---|---|---|
| Del I, punkt 1 | Passende cybersikkerhedsniveau gennem design | Produktet designes, udvikles og fremstilles, så et cybersikkerhedsniveau, der svarer til risiciene, sikres på grundlag af cybersikkerhedsrisikovurderingen. | altid |
| Del I, punkt 2, litra a) | Ingen kendte udnyttelige sårbarheder ved tilgængeliggørelse | Produktet gøres tilgængeligt på markedet uden kendte udnyttelige sårbarheder. | hvor det er relevant |
| Del I, punkt 2, litra b) | Sikker standardkonfiguration | Produktet leveres med en sikker standardkonfiguration, herunder muligheden for at nulstille det til den oprindelige tilstand, medmindre andet er aftalt med en erhvervsbruger for et skræddersyet produkt. | hvor det er relevant |
| Del I, punkt 2, litra c) | Sikkerhedsopdateringer | Sårbarheder kan håndteres gennem sikkerhedsopdateringer, herunder automatiske opdateringer som standard med en klar fravalgsmulighed og underretning af brugerne, hvor det er relevant. | hvor det er relevant |
| Del I, punkt 2, litra d) | Beskyttelse mod uautoriseret adgang | Passende kontrolmekanismer, herunder autentificering, identitets- og adgangsstyring samt rapportering af mulig uautoriseret adgang. | hvor det er relevant |
| Del I, punkt 2, litra e) | Fortrolighed af data | Lagrede, overførte eller på anden måde behandlede data, personlige eller andre, beskyttes, for eksempel ved kryptering i hvile og under overførsel med mekanismer efter det aktuelle tekniske niveau. | hvor det er relevant |
| Del I, punkt 2, litra f) | Integritet af data, kommandoer og konfiguration | Lagrede, overførte eller behandlede data, kommandoer, programmer og konfiguration beskyttes mod manipulation eller ændring, som brugeren ikke har godkendt, og beskadigelser rapporteres. | hvor det er relevant |
| Del I, punkt 2, litra g) | Dataminimering | Kun data, der er tilstrækkelige, relevante og begrænset til det nødvendige for det tilsigtede formål, behandles. | hvor det er relevant |
| Del I, punkt 2, litra h) | Tilgængelighed af væsentlige og grundlæggende funktioner | Væsentlige og grundlæggende funktioner forbliver tilgængelige, også efter en hændelse, herunder modstandsdygtighed og afbødning over for denial-of-service-angreb. | hvor det er relevant |
| Del I, punkt 2, litra i) | Ingen negativ indvirkning på andre enheder og netværk | Produktet minimerer sin egen negative indvirkning på tilgængeligheden af tjenester, der leveres af andre enheder eller netværk. | hvor det er relevant |
| Del I, punkt 2, litra j) | Begrænset angrebsflade | Angrebsflader, herunder eksterne grænseflader, er begrænsede. | hvor det er relevant |
| Del I, punkt 2, litra k) | Reduceret virkning af hændelser | Virkningen af en hændelse reduceres ved hjælp af passende mekanismer og teknikker til afbødning af udnyttelse. | hvor det er relevant |
| Del I, punkt 2, litra l) | Sikkerhedslogning og -overvågning | Sikkerhedsrelateret information stilles til rådighed ved at registrere og overvåge relevant intern aktivitet, herunder adgang til eller ændring af data, tjenester eller funktioner, med en fravalgsmulighed for brugeren. | hvor det er relevant |
| Del I, punkt 2, litra m) | Sikker og nem sletning af data og indstillinger | Brugere kan sikkert og nemt fjerne alle data og indstillinger permanent, og hvor data kan overføres til et andet produkt, sker det sikkert. | hvor det er relevant |
Del II: håndtering af sårbarheder
| Henvisning | Krav | Hvad der skal gælde |
|---|---|---|
| Del II, punkt 1 | Identificere og dokumentere sårbarheder og komponenter, med en SBOM | Sårbarheder og komponenter i produktet identificeres og dokumenteres, herunder en softwarestykliste i et almindeligt anvendt maskinlæsbart format, der mindst dækker afhængighederne på øverste niveau. |
| Del II, punkt 2 | Afhjælpe sårbarheder uden unødigt ophold | Sårbarheder håndteres og afhjælpes uden unødigt ophold, herunder ved sikkerhedsopdateringer; hvor det er teknisk muligt, er sikkerhedsopdateringer adskilt fra funktionsopdateringer. |
| Del II, punkt 3 | Regelmæssige test og gennemgange | Effektive og regelmæssige test og gennemgange af produktets sikkerhed anvendes. |
| Del II, punkt 4 | Offentliggøre afhjulpne sårbarheder | Når en sikkerhedsopdatering er tilgængelig, deles og offentliggøres oplysninger om afhjulpne sårbarheder: beskrivelse, berørte produkter, virkninger, alvor og hvordan brugerne afhjælper; offentliggørelsen kan udskydes, hvor sikkerhedsrisikoen ved at offentliggøre opvejer fordelen. |
| Del II, punkt 5 | Politik for koordineret offentliggørelse af sårbarheder | En politik for koordineret offentliggørelse af sårbarheder indføres og håndhæves. |
| Del II, punkt 6 | En kontakt til indberetning af sårbarheder | Deling af oplysninger om potentielle sårbarheder lettes, herunder en kontaktadresse til indberetning af sårbarheder, der opdages i produktet. |
| Del II, punkt 7 | Sikker og rettidig distribution af opdateringer | Der findes mekanismer til sikker distribution af opdateringer, så sårbarheder afhjælpes eller afbødes rettidigt, og, hvor det gælder sikkerhedsopdateringer, automatisk. |
| Del II, punkt 8 | Gratis sikkerhedsrettelser med vejledninger | Sikkerhedsrettelser eller -opdateringer udsendes uden unødigt ophold og, medmindre andet er aftalt for et skræddersyet produkt, gratis, ledsaget af vejledende meddelelser, der giver brugerne de relevante oplysninger, herunder om mulige tiltag. |
Sådan læses listen
Ordene er omskrevet; henvisningerne er ikke. Kolonnen "Hvad der skal gælde" er vores korte læsning af hvert punkt i klart sprog. Klassificer op imod forordningens ordlyd, som henvisningerne lader jer finde på sekunder, og citer den i dokumentationen.
Del II forudsætter, at fire dokumenter findes. En politik for koordineret offentliggørelse af sårbarheder (punkt 5), en offentlig kontakt til indberetninger (punkt 6), en softwarestykliste (punkt 1) og en måde at distribuere opdateringer sikkert og gratis på (punkt 7 og 8). De fleste små fabrikanter har ingen af de fire på skrift. De er ikke svære at skrive; det er svært at huske at skrive dem, før nogen spørger.
"Uden kendte udnyttelige sårbarheder" er en tilstand ved tilgængeliggørelsen, ikke et løfte. Del I, punkt 2, litra a, handler om det øjeblik, produktet gøres tilgængeligt. Hvad der sker derefter, er del II, og anmeldelsespligten i artikel 14, i kraft siden den 11. september 2026, ligger oven på den for sårbarheder, der udnyttes aktivt.
Supportperioden er en del af svaret. Artikel 13, stk. 8, kræver, at fabrikanten fastlægger en supportperiode, hvori del II leveres, på mindst fem år, medmindre produktet forventes at være i brug i kortere tid, og angiver den. En dokumentation, der opregner kravene i del II uden at sige hvor længe, er ufuldstændig.
Udelukkelser er et argument, ikke et flueben. For hvert krav i del I, punkt 2, som I ikke implementerer, skal dokumentationen indeholde risikovurderingens begrundelse. Et bemyndiget organ, eller en markedsovervågningsmyndighed, når jeres medlemsstat har udpeget én, læser de begrundelser før alt andet.
Hvad I gør med det
For hvert omfattet produkt én række pr. krav: implementeret, hvordan, og hvor beviset ligger; eller udelukket, på grundlag af hvilken konklusion i risikovurderingen. Toogtyve rækker. Den tabel, med trinnet og fastlæggelsen af anvendelsesområdet foran sig, er det meste af rygraden i en teknisk dokumentation, og det er den tabel, fristen i december 2027 i virkeligheden handler om.
Kilder
- Forordning (EU) 2024/2847, bilag I, del I og II; artikel 13, stk. 2, for den risikovurdering, "hvor det er relevant" henviser til; artikel 13, stk. 8, for supportperioden; artikel 31 og bilag VII for den tekniske dokumentation; artikel 71, stk. 2, for datoerne.
- Kommissionens tekniske FAQ om CRA, version 1.3 af 1. juli 2026, om udelukkelser fra del I, punkt 2.
Dette er ikke juridisk rådgivning. Henvisningerne står der, så I kan læse hvert krav i forordningen og beslutte for jeres eget produkt.