Cyber Resilience Act: 11. september 2026 er en reel frist

De fleste EU-forordninger giver dig en compliancedato og en overgangsperiode, hvor alle stille organiserer sig. Cyber Resilience Act gør noget andet. Dens første hårde pligt er et 24-timers indberetningsur, og det starter 11. september 2026.

Et 24-timers ur kan ikke indfases. Enten findes processen den dag, eller også rammer du ved siden af.

Hvad CRA er

Forordning (EU) 2024/2847 fastsætter cybersikkerhedskrav til produkter med digitale elementer, der gøres tilgængelige på EU-markedet. Udtrykket dækker langt mere, end folk først antager: ethvert software- eller hardwareprodukt, og dets løsninger til fjerndatabehandling, hvis tilsigtede eller rimeligt forudsigelige brug omfatter en direkte eller indirekte dataforbindelse.

Forbundne enheder er omfattet. Det samme er det meste kommercielle software, operativsystemer, browsere, mobilapps, firmware og komponenterne inde i andre produkter.

Forordningen blev offentliggjort i november 2024 og gælder trinvis:

11. juni 2026: pligter for overensstemmelsesvurderingsorganer.
11. september 2026: indberetningspligter for aktivt udnyttede sårbarheder og alvorlige hændelser.
11. december 2027: fuld anvendelse, inklusive væsentlige cybersikkerhedskrav, CE-mærkning, teknisk dokumentation og softwarekomponentlisten.

Den midterste dato er den, man skal planlægge efter, fordi den kommer først, og fordi den afhænger af kapacitet, du måske ikke har.

Hvad der sker 11. september 2026

Fra den dato skal producenter indberette:

Aktivt udnyttede sårbarheder i deres produkter med digitale elementer, og

alvorlige hændelser, der påvirker sikkerheden i disse produkter.

Indberetningen går via CRA's fælles indberetningsplatform, drevet af ENISA, til det CSIRT, der er udpeget i den medlemsstat, hvor producenten har sit hovedforretningssted, som derefter deler videre til andre berørte CSIRT'er og ENISA.

Tidslinjen:

Inden 24 timer efter kendskab: en tidlig varsling.
Inden 72 timer: en fuld underretning, inklusive afhjælpende eller begrænsende foranstaltninger, der er truffet.
Inden 14 dage efter at en afhjælpende foranstaltning er tilgængelig: en slutrapport for en aktivt udnyttet sårbarhed.
Inden en måned: en slutrapport for en alvorlig hændelse.

Fireogtyve timer fra kendskab, ikke fra bekræftelse, ikke fra afhjælpning. Udnyttes en sårbarhed i en komponent i dit produkt i naturen på en lørdag, kører uret om lørdagen.

Hvorfor dette er sværere, end det ser ud

Selve indberetningspligten er en formular. Vanskeligheden ligger i alt det, du skal have på plads, før du kan udfylde den.

Du skal vide, hvad der er i dit produkt

For at indberette, at en sårbarhed i dit produkt aktivt udnyttes, skal du vide, at den sårbare komponent er i dit produkt. For en moderne applikation med hundredvis af transitive afhængigheder er det ikke noget, et menneske svarer på fra hukommelsen.

Derfor bygger teams softwarekomponentlistepipelines nu, mere end et år før det formelle SBOM-krav i december 2027. SBOM er ikke målet. Målet er at kunne svare på «er vi berørt?» inden for timer, og SBOM'en er det, der gør spørgsmålet besvarligt.

Det ubehagelige er, at dette også gælder produkter, du sendte for år siden. Har du understøttede enheder i felten med firmware bygget i 2022 fra et afhængighedstræ, ingen har registreret, er det reelt arbejde at rekonstruere.

Du skal holde øje

Kendskab starter uret, og kendskabet forventes at være aktivt snarere end tilfældigt. Det betyder at overvåge sårbarhedskilder, abonnere på varsler for dine komponenter, følge kataloger over kendte udnyttede sårbarheder, og have en kanal hvor sikkerhedsforskere kan nå dig og få svar.

Du skal have en beslutningsvej

Nogen skal kunne afgøre, på ethvert tidspunkt af døgnet, om en hændelse når tærsklen, og om uret er startet. Uden en navngiven rolle og en eskaleringsvej går de første timer med at finde ud af, hvem der må træffe beslutningen.

Afhængigheder uden support bliver et ansvar

Får en komponent i dit produkt ikke længere sikkerhedsopdateringer, bærer du stadig indberetningspligten, når den udnyttes, og du har ingen opstrøms rettelse at pege på. At gennemgå afhængigheder uden support er noget af det mest nyttige i optakten, fordi svaret indimellem tvinger en migrering frem med sin egen leveringstid.

Hvad fuld anvendelse i december 2027 bringer

Pligterne fra december 2027 er det større program, og de skal påbegyndes længe før.

Sikkerhed gennem design og som standard. Produkter skal udformes, udvikles og fremstilles, så de sikrer et passende cybersikkerhedsniveau baseret på risiko. Ingen standardadgangskoder. Sikker konfiguration lige ud af boksen. Minimering af angrebsfladen. Beskyttelse af data under overførsel og i hvile.

Sårbarhedshåndtering. En dokumenteret proces, der dækker identifikation, afhjælpning, test, distribution og offentliggørelse. Sikkerhedsopdateringer skal leveres uden ophold og gratis, i en supportperiode der afspejler produktets forventede levetid, med fem år som almindelig reference.

Softwarekomponentliste. I maskinlæsbart format, der som minimum dækker afhængighederne på øverste niveau, og holdes opdateret.

Teknisk dokumentation og overensstemmelsesvurdering. De fleste produkter egenvurderer. Vigtige og kritiske kategorier, som blandt andet omfatter adgangskodeadministratorer, VPN'er, operativsystemer og industrielle styresystemer, kræver tredjepartsinddragelse.

CE-mærkning. Den digitale ækvivalent til det fysiske mærke, der erklærer overensstemmelse.

Politik for koordineret sårbarhedsoffentliggørelse. Offentliggjort, med et kontaktpunkt der virker.

Hvem der faktisk er omfattet

Nogle få grænsetilfælde går igen.

Fri og open source-software udviklet uden for kommerciel aktivitet falder stort set udenfor. Forordningen indfører begrebet forvalter af open source-software med lettere pligter. Men kommercialiserer du open source, eller leverer det inde i et produkt, du sælger, er produktpligterne dine.

Software som tjeneste falder generelt uden for CRA og ligger snarere under NIS2, selvom løsninger til fjerndatabehandling, der er integrerede i et produkt med digitale elementer, trækkes ind. Afhænger din enhed af din cloudbackend for at fungere, følger den backend med produktet.

Importører og distributører bærer også pligter. Bringer du et tredjepartsprodukt på EU-markedet under eget navn eller varemærke, behandles du som producent.

Produkter, der allerede er reguleret andetsteds, som medicinsk udstyr, køretøjer og luftfartsudstyr, håndteres i deres egne rammer.

Anvendelsesområdespørgsmålene er reelt ikke trivielle, og dette er et sted, hvor en time med jeres jurister sparer måneder med fejlrettet udvikling.

Hvad vi ville gøre i den resterende tid

Er du omfattet og starter nu, er dette den rækkefølge, der fungerer:

Først, etablér produktoversigten. Hvad har du faktisk på EU-markedet? Inklusive gamle versioner stadig i felten, white label-varianter og produkter, du distribuerer for andre. Denne liste er som regel længere, end nogen forventer.

Dernæst, byg SBOM-generering ind i CI. Generér en SBOM ved hver build, i CycloneDX eller SPDX, gem den sammen med udgivelsesartefaktet og hold den søgbar. Pointen er at kunne spørge «hvilke af vores leverede udgivelser indeholder dette bibliotek?» og få svar på minutter.

Dernæst, tilslut sårbarhedsovervågning. Fød SBOM-data ind i en scanner, der følger varsler og kataloger over kendte udnyttede sårbarheder, og send advarsler til en kanal, nogen læser.

Dernæst, skriv hændelsesdrejebogen. Hvem erklærer, hvem vurderer, hvem indberetter, hvem kommunikerer. Navngivne personer, stedfortrædere og kontakter uden for arbejdstid. Øv den så én gang med et fiktivt varsel. Det er i øvelsen, du opdager, at personen med adgangen til indberetningsplatformen holder ferie.

Dernæst, offentliggør en politik for sårbarhedsoffentliggørelse. En security.txt-fil, en overvåget adresse og en oplyst svartid. Det er en eftermiddags arbejde og forskellen mellem at høre om et problem fra en forsker eller fra en journalist.

Til sidst, start arbejdet mod december 2027. Sikre standardindstillinger, opdateringsmekanismer, beslutninger om supportperiode og dokumentation er arkitekturspørgsmål, ikke papirarbejde. Produkter, du designer i 2026, vil stadig være på markedet i 2028.

Overlappet ingen bruger

Der findes betydeligt dobbeltarbejde mellem CRA og andre regimer, og de fleste virksomheder håndterer hvert for sig, hvilket er spild.

En SBOM bygget til CRA besvarer de fleste leverandørkædespørgsmål i NIS2. Hændelsesdrejebogen overlapper med NIS2's 24-timers tidlige varsling og med GDPR's 72-timers bruddunderretning. Processerne for sårbarhedshåndtering fører direkte ind i kunders sikkerhedsspørgeskemaer og indkøb i store virksomheder.

Byg dette én gang som platformkapacitet. Alternativet er tre teams, der bygger tre versioner af den samme aktivoversigt.

Hvor du får hjælp

Vi bygger og vedligeholder software for virksomheder, der sælger ind i EU, hvilket i stigende grad betyder at bygge den leverandørkædeoverblik og opdateringsinfrastruktur, CRA forudsætter. Prøver du at finde ud af, om du er omfattet, eller har du septemberdatoen i kalenderen uden overvågning på plads, så skriv til office@c9group.dev.

Vores service til vedligeholdelse af ældre systemer er ofte, hvor dette starter, fordi produkterne med dårligst afhængighedsoverblik gerne er de ældste. Det bredere regulatoriske billede findes i vores guide til EU digital compliance 2026.

Vi er ingeniører snarere end jurister. Beslutninger om anvendelsesområde og klassificering hører til jeres jurister, og vi bygger efter det svar, de giver.