Cyber Resilience Act
Cyber Resilience Act
Oversigt
Cyber Resilience Act (CRA) indfører obligatoriske cybersikkerhedskrav for hardware- og softwareprodukter med digitale elementer. Den dækker hele produktets livscyklus fra design til slut på support og har til formål at tackle udbredelsen af usikre IoT- og softwareprodukter.[1]
CRA gælder for produkter, der bringes på EU-markedet, uanset hvor de er fremstillet.
Anvendelsestidslinje
| Dato | Milepæl |
|---|---|
| 10. december 2024 | CRA træder i kraft |
| 11. september 2026 | Rapporteringsforpligtelser begynder |
| 11. december 2027 | Fuld anvendelse af alle krav |
Produkter inden for anvendelsesområdet
Omfattede produkter
Produkter med digitale elementer, der:
- Har en direkte eller indirekte logisk eller fysisk datatilslutning til en enhed eller netværk
- Inkluderer hardware- og softwarekomponenter
Kategorier
| Kategori | Krav | Eksempler |
|---|---|---|
| Standard | Selvvurdering | De fleste software, grundlæggende IoT |
| Vigtig Klasse I | Standardbaseret vurdering | Browsere, adgangskodeadministratorer, VPN'er, netværksstyring |
| Vigtig Klasse II | Tredjepartsvurdering | Operativsystemer, firewalls, routere, hypervisorer |
| Kritisk | Tredjepartsvurdering + certificering | Hardware-sikkerhedsmoduler, smartmålere, smartkort |
Undtagelser
- Open source-software (ikke-kommerciel udvikling)
- SaaS (omfattet af andre regler)
- Produkter, der allerede er reguleret (medicinsk udstyr, køretøjer, luftfart)
- Forsvars- og nationale sikkerhedsprodukter
Væsentlige cybersikkerhedskrav[2]
Sikkerhed ved design
Produkter skal designes og udvikles for at sikre:
- Passende sikkerhedsniveau: Baseret på forudsigelige risici
- Ingen kendte udnyttelige sårbarheder: På tidspunktet for markedsføring
- Sikker standardkonfiguration: Inklusive fabriksnulstilling
- Fortrolighedsbeskyttelse: For lagrede, transmitterede og behandlede data
- Integritetsbeskyttelse: Mod uautoriseret ændring
- Tilgængelighed: Modstandsdygtig over for tjenestenægtelse
- Minimal angrebsflade: Reducer potentielle angrebsvektorer
- Begrænsning af hændelsespåvirkning: Minimer konsekvenser af brud
Autentificering og adgangskontrol
- Stærke, unikke standardlegitimationsoplysninger eller brugerindstillede ved første brug
- Beskyttelse mod brute force-angreb
- Sikre autentificeringsmekanismer
Databeskyttelse
- Krypteret lagring af følsomme data
- Sikker dataoverførsel
- Slet eller anonymiser data, når de ikke længere er nødvendige
Krav til håndtering af sårbarheder[3]
Producenter skal:
- Identificere sårbarheder: Gennem test og overvågning
- Dokumentere komponenter: Vedligeholde softwarematerialeliste (SBOM)
- Håndtere sårbarheder: Levere sikkerhedsopdateringer uden unødig forsinkelse
- Offentliggøre sårbarheder: Koordinere med berørte parter
- Sikkerhedsopdateringer: Gratis opdateringer i defineret supportperiode (minimum 5 år)
Rapportering af sårbarheder
Fra september 2026 skal producenter rapportere:
| Rapporttype | Tidslinje |
|---|---|
| Aktivt udnyttet sårbarhed | 24 timer til ENISA |
| Hændelse med sikkerhedspåvirkning | 24 timer til ENISA/CSIRT |
| Sårbarhedsmeddelelse | 72 timer til ENISA |
Overensstemmelsesvurdering
| Kategori | Procedure |
|---|---|
| Standard | Selvdeklaration eller EU-typeundersøgelse |
| Vigtig Klasse I | Harmoniserede standarder ELLER tredjepartsvurdering |
| Vigtig Klasse II | Tredjeparts overensstemmelsesvurdering |
| Kritisk | EU-typeundersøgelse + produktionskvalitetssikring |
Produkter skal bære CE-mærkning, der bekræfter overholdelse.
Straf
- Manglende overholdelse: Op til 15 millioner € eller 2,5 % af global omsætning
- Brud på væsentlige krav: Op til 10 millioner € eller 2 % af omsætning
- Andre overtrædelser: Op til 5 millioner € eller 1 % af omsætning[4]
Udviklerens handlingspunkter
For software- og hardwareproducenter:
- Inventar over produkter: Fastlæg hvilke der er omfattet og deres kategori
- Sikkerhed ved design: Integrer sikkerhed i udviklingsprocesser
- Håndtering af sårbarheder: Etabler procedurer for detektion og håndtering
- Oprettelse af SBOM: Dokumenter softwarekomponenter og afhængigheder
- Supportplanlægning: Definer og kommuniker supportperioder
- Opdateringsmekanismer: Byg sikre systemer til opdateringslevering
- Forberedelse til overensstemmelse: Forbered teknisk dokumentation