Cyber Resilience Act: alle værktøjer og artikler
Forordning (EU) 2024/2847, bilag I · ISO/IEC 27001:2022, bilag A
CRA's væsentlige krav, kortlagt til ISO 27001
En fabrikant med et certificeret ISMS stiller først ét spørgsmål: Hvor meget af den tekniske dokumentation har jeg allerede? Svaret har tre dele. For de 14 krav i del I, produktets egenskaber, driver ISMS'et processen, og produktet leverer beviset. For 3 af de 8 krav til håndtering af sårbarheder i del II er ISMS-registreringen beviset. Og for 4 af de 22 leverer intet i bilag A det, forordningen beder om.
Et ledelsessystem er ikke et produkt
ISO 27001 certificerer, hvordan en organisation styrer informationssikkerhed. Cyber Resilience Act regulerer et produkt: hvad det gør, hvordan det bygges, og hvordan dets sårbarheder håndteres i supportperioden. De to mødes i udviklingsforanstaltningerne i bilag A, som styrer, hvordan produktet bygges, og i foranstaltningerne til håndtering af sårbarheder, som styrer, hvad der sker efter frigivelsen. De mødes ikke i produktets egne egenskaber: Ingen ISMS-registrering viser, at et produkt leveres med en sikker standardkonfiguration. Det viser produktets dokumentation og test.
Tre svar, ikke én score
- ISMS-registreringen er beviset
- 3
- Den registrering, foranstaltningen frembringer, er det, den tekniske dokumentation henviser til: sårbarhedsregistret, afhjælpningsloggen, testrapporterne.
- ISMS'et driver processen, produktet leverer beviset
- 15
- Foranstaltningen fastlægger kravet, princippet, kodningsreglen eller testen; beviset for, at produktet opfylder det, er produktets eget, pr. version.
- Leveres ikke af bilag A
- 4
- Intet i bilag A offentliggør noget, udarbejder en stykliste over et produkt eller forpligter sig til gratis opdateringer. Det skrives til forordningen.
Del I: produktets egenskaber
Punkt 1 er den generelle pligt, baseret på risikovurderingen. Punkt 2 opregner tretten egenskaber, hver gældende på grundlag af den vurdering, så en egenskab, der vurderes ikke at finde anvendelse, udelukkes med en begrundelse i dokumentationen. For dem alle leverer ISMS'et processen: de sikkerhedskrav, produktet skal opfylde, de principper, det er designet efter, kodningsreglerne, testene før frigivelsen. Beviset for hver egenskab er produktets.
I.1 Passende cybersikkerhedsniveau gennem design
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- Afsnit 6.1.2
- A.5.8
- A.8.25
Hvad dokumentationen stadig mangler: En cybersikkerhedsrisikovurdering af selve produktet (artikel 13, stk. 2 og 3), opbevaret i den tekniske dokumentation efter bilag VII, punkt 3. ISMS'et vurderer organisationens risici; produktets er en særskilt registrering.
I pakken med teknisk dokumentation: Cybersecurity risk assessment
I.2.a Ingen kendte udnyttelige sårbarheder ved frigivelsen
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.8
- A.8.29
Hvad dokumentationen stadig mangler: Kontrollen sker pr. frigivelse og pr. leveret komponent, og resultatet bliver hos den version. En scanning af organisationens egne systemer er en anden registrering.
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.b Sikker standardkonfiguration
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.9
- A.8.26
Hvad dokumentationen stadig mangler: Den sikre standardkonfiguration og nulstillingen til den er produktets egenskaber, vist ved dets dokumentation og test, ikke ved en konfigurationsbaseline for organisationens systemer.
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.c Sikkerhedsopdateringer
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.8
- A.8.32
Hvad dokumentationen stadig mangler: En opdateringsmekanisme i produktet, automatisk som standard med mulighed for, at brugeren fravælger den, og en meddelelse til brugerne, når en opdatering er tilgængelig: en funktion, ikke en proces.
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.d Beskyttelse mod uautoriseret adgang
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.26
- A.8.5
- A.5.15
- A.5.16
- A.5.17
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.e Fortrolighed af data
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.26
- A.8.24
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.f Integritet af data, kommandoer og konfiguration
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.26
- A.8.24
- A.8.9
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.g Dataminimering
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.26
- A.5.34
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.h Tilgængelighed af væsentlige og grundlæggende funktioner
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.26
- A.8.6
- A.8.14
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.i Ingen negativ indvirkning på andre enheder og netværk
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.27
- A.8.20
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.j Begrænset angrebsflade
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.27
- A.8.9
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.k Reduceret indvirkning af hændelser
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.27
- A.8.28
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.l Sikkerhedslogning og overvågning
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.26
- A.8.15
- A.8.16
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.m Sikker og enkel sletning af data og indstillinger
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.26
- A.8.10
I pakken med teknisk dokumentation: Standards applied and test evidence
Del II: håndtering af sårbarheder i supportperioden
Otte krav til fabrikanten, hvoraf ingen kan udelukkes. Det er her, et ISMS er tættest på forordningen, og her de konkrete huller ligger: styklisten, den offentlige oplysning, politikken, kontaktadressen og de gratis opdateringer.
II.1 Identificere og dokumentere sårbarheder og komponenter, med en SBOM
ISMS-registreringen er beviset
Processen, i bilag A
- A.8.8
- A.5.9
Hvad dokumentationen stadig mangler: En softwarestykliste i et almindeligt anvendt, maskinlæsbart format, der mindst dækker produktets afhængigheder på øverste niveau. Ingen foranstaltning i bilag A beder om en stykliste over et produkt.
I pakken med teknisk dokumentation: Software bill of materials procedure
II.2 Afhjælpe sårbarheder uden ophold
ISMS-registreringen er beviset
Processen, i bilag A
- A.8.8
- A.8.32
Hvad dokumentationen stadig mangler: Sikkerhedsopdateringer leveret adskilt fra funktionsopdateringer, hvor det er teknisk muligt: en frigivelsespraksis, som bilag A ikke nævner.
I pakken med teknisk dokumentation: Security updates and support statement
II.3 Regelmæssige test og gennemgange
ISMS-registreringen er beviset
Processen, i bilag A
- A.8.29
- A.8.8
- A.5.35
I pakken med teknisk dokumentation: Vulnerability handling process
II.4 Oplyse om afhjulpne sårbarheder
Leveres ikke af bilag A
Hvad dokumentationen stadig mangler: Offentlig oplysning om hver afhjulpet sårbarhed, når opdateringen er tilgængelig: beskrivelse, berørte produkter, indvirkning, alvorlighed og hvordan brugerne afhjælper. Bilag A har ingen foranstaltning, der offentliggør noget.
I pakken med teknisk dokumentation: Vulnerability handling process
II.5 Politik for koordineret oplysning om sårbarheder
Leveres ikke af bilag A
Hvad dokumentationen stadig mangler: En politik for koordineret oplysning om sårbarheder, indført og håndhævet. Bilag A kræver en hændelsesproces, ikke en offentliggjort politik for eksterne indberettere.
I pakken med teknisk dokumentation: Coordinated vulnerability disclosure policy
II.6 En kontakt til indberetning af sårbarheder
Leveres ikke af bilag A
Hvad dokumentationen stadig mangler: En offentliggjort kontaktadresse til indberetning af sårbarheder i produktet og i dets tredjepartskomponenter, og en måde at modtage dem på.
I pakken med teknisk dokumentation: Coordinated vulnerability disclosure policy
II.7 Sikker og rettidig distribution af opdateringer
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.24
- A.8.32
Hvad dokumentationen stadig mangler: Distributionsmekanismen er produktets: opdateringer signeret, leveret sikkert og rettidigt, automatisk hvor det er relevant.
I pakken med teknisk dokumentation: Security updates and support statement
II.8 Gratis sikkerhedsrettelser med meddelelser
Leveres ikke af bilag A
Hvad dokumentationen stadig mangler: Gratis sikkerhedsopdateringer i supportperioden, uden ophold, med en meddelelse til brugerne. En forretningsmæssig forpligtelse og en offentliggørelse, som bilag A ikke nævner nogen af.
I pakken med teknisk dokumentation: Security updates and support statement
4 ting, som bilag A ikke leverer
Skrevet ud, så en certificeret fabrikant ved, hvad der skal skrives, ikke kun hvad der kan henvises til. Hver af de 4 lander i et af 3 dokumenter i pakken med teknisk dokumentation, og de dokumenter udarbejdes ud fra produktregistreringen, ikke ud fra ISMS'et.
II.4 Oplyse om afhjulpne sårbarheder
Offentlig oplysning om hver afhjulpet sårbarhed, når opdateringen er tilgængelig: beskrivelse, berørte produkter, indvirkning, alvorlighed og hvordan brugerne afhjælper. Bilag A har ingen foranstaltning, der offentliggør noget.
II.5 Politik for koordineret oplysning om sårbarheder
En politik for koordineret oplysning om sårbarheder, indført og håndhævet. Bilag A kræver en hændelsesproces, ikke en offentliggjort politik for eksterne indberettere.
II.6 En kontakt til indberetning af sårbarheder
En offentliggjort kontaktadresse til indberetning af sårbarheder i produktet og i dets tredjepartskomponenter, og en måde at modtage dem på.
II.8 Gratis sikkerhedsrettelser med meddelelser
Gratis sikkerhedsopdateringer i supportperioden, uden ophold, med en meddelelse til brugerne. En forretningsmæssig forpligtelse og en offentliggørelse, som bilag A ikke nævner nogen af.
Hvad denne side ikke er
Ikke en dækningsscore. Her beregnes ingen procent, og det bør der heller ikke. Et krav, hvis proces ligger i ISMS'et, og hvis bevis endnu ikke ligger i dokumentationen, er ikke en delvist dækket brøk; det er et dokument, der skal skrives.
Ikke en overensstemmelsesformodning. Kun en harmoniseret standard, der er offentliggjort i EU-Tidende, giver en (artikel 27), og ISO 27001 er ikke, og bliver ikke, den standard. Hvor de harmoniserede standarder står, og hvad deres fravær betyder for hvert niveau
Ikke NIS2-kortlægningen. NIS2 regulerer organisationen, og dens foranstaltninger er skrevet ud fra ISO 27001, hvilket er grunden til, at den kortlægning ligger tættere på. NIS2-gennemførelsesforordningen kortlagt til ISO 27001
Læs derefter
CRA bilag I: de 22 væsentlige krav, som tjekliste
Bilag I til Cyber Resilience Act er det, jeres produkt skal opfylde fra den 11. december 2027, og det, den tekniske dokumentation skal vise. Del I er 14 produktkrav, 13 af dem \"hvor det er relevant\" på grundlag af jeres risikovurdering; del II er 8 krav til håndtering af sårbarheder, som altid gælder. Her er de som én tabel, med hvad hvert krav beder om, og om I må udelukke det.
Hvad der hører til i den tekniske dokumentation efter CRA: bilag VII, punkt for punkt
Fra den 11. december 2027 skal ethvert produkt med digitale elementer, der bringes i omsætning på EU-markedet, have teknisk dokumentation før omsætningen, opbevaret i ti år eller supportperioden, alt efter hvad der er længst. Bilag VII siger i otte punkter, hvad den indeholder. Her er de, hvad hvert punkt faktisk beder om, de fire dokumenter, som del II i bilag I forudsætter, og hvor længe I beholder den.
Harmoniserede standarder til CRA: hvad standardiseringsanmodning M/606 beder om, hvornår, og hvad en fabrikant har i dag
Artikel 27 giver en overensstemmelsesformodning til produkter, der følger harmoniserede standarder offentliggjort i Den Europæiske Unions Tidende. Den 3. februar 2025 bad Kommissionen CEN, CENELEC og ETSI om 41 af dem med frister fra den 30. august 2026 til den 30. oktober 2027; de tre accepterede den 3. april 2025. Den 12. september 2026 har Kommissionens indeks over harmoniserede standarder stadig ingen post for forordningen, hvilket for et klasse I-produkt betyder, at der ikke er nogen vej til egenvurdering efter artikel 32(2). Hvad der blev bedt om, datoerne, og hvad man bygger efter i mellemtiden.
Selvvurdering efter CRA: hvad modul A faktisk kræver, fra bilag VIII og Kommissionens FAQ
De fleste softwareprodukter vil aldrig se et bemyndiget organ. De bruger modul A, proceduren for intern kontrol i bilag VIII, og \"selvvurdering\" er det ord, alle bruger om den uden at sige, hvad den indeholder. Bilag VIII, del I, er fem punkter; Kommissionens FAQ tilføjer listen over aktiviteter, det faktum, at ingen testmetode er foreskrevet, hvor et softwareprodukt bærer sin CE-mærkning, de to former for overensstemmelseserklæringen og tidsplanen for de harmoniserede standarder, der afgør, hvornår selvvurdering holder op med at betyde \"direkte mod bilag I\".
CRA-cybersikkerhedsrisikovurderingen: hvad artikel 13 faktisk kræver, og det ene resultat, den skal levere
Artikel 13, stk. 2 til 4, i Cyber Resilience Act gør risikovurderingen til det dokument, alle andre CRA-pligter hænger på. Den skal analysere risici ud fra det tilsigtede formål, den forventelige brug og brugsbetingelserne over den forventede brugstid; angive om og hvordan hvert krav i del I, punkt 2, gælder; sige hvordan del I, punkt 1, og del II anvendes; være dokumenteret, holdt ajour over supportperioden og indgå i den tekniske dokumentation, med en klar begrundelse for hvert udeladt krav. De fire stykker, og en struktur på én side, der opfylder dem.
Kræver CRA en SBOM? Ja, og her står præcis, hvad den siger
Bilag I, del II, punkt 1 i Cyber Resilience Act kræver en softwarestykliste i et almindeligt anvendt, maskinlæsbart format, der mindst dækker afhængighederne på øverste niveau. Den hører til i den tekniske dokumentation, den offentliggøres ikke, og en markedsovervågningsmyndighed kan bede om den på begrundet anmodning. De tre sætninger, der afgør det, og hvad de lader stå åbent.
Den politik for koordineret offentliggørelse af sårbarheder, som CRA kræver: tre bestemmelser, og en politik på én side, der opfylder dem
Bilag I, del II, punkt 5, i Cyber Resilience Act kræver, at enhver omfattet fabrikant indfører og håndhæver en politik for koordineret offentliggørelse af sårbarheder. Artikel 13, stk. 17, kræver ét kontaktpunkt til indberetninger, som er let at finde og ikke begrænset til automatiserede værktøjer; bilag II, punkt 2, kræver kontaktpunktet og politikkens placering i brugeroplysningerne; bilag VII, punkt 2, litra b, sætter begge dele i den tekniske dokumentation. Hvad hver bestemmelse beder om, hvad en politik skal sige, og hvad den ikke må love.
Cyber Resilience Act for en lille softwarefabrikant, i tolv trin
Alt, hvad en virksomhed på ti personer, der leverer installeret software eller en enhed, skal gøre efter CRA, i den rækkefølge, det skal gøres: fastlæggelsen af anvendelsesområdet, trinnet, CSIRT'et og håndhæveren, den anmeldelsesprocedure, der har gjaldt siden den 11. september 2026, derefter den tekniske dokumentation, de 22 krav, SBOM'en, supportperioden, CE-mærkningen og erklæringen med frist den 11. december 2027. Hvert trin med sin artikel og den tekst, der forklarer det.
De 4 huller er 3 af dokumentationens 11 dokumenter
StandardOS fører de ISMS-registreringer, som de 23 kortlagte foranstaltninger frembringer, og pakken med teknisk dokumentation udarbejder de 11 dokumenter efter bilag VII ud fra produktregistreringen, blandt dem oplysningspolitikken, opdateringserklæringen og SBOM-proceduren. Kortlægningen på denne side er forbindelsen mellem de to.
Bilag I finder anvendelse fra den 11. december 2027. Foranstaltningerne er de 93 i bilag A til ISO/IEC 27001:2022, citeret ved reference; kortlægningen er vores og ikke ISO's eller Kommissionens. Dette er ikke juridisk rådgivning, og forordningen er den tekst, der skal læses: Forordning (EU) 2024/2847.