--- title: "Cyber Resilience Act's indberetningspligt er trådt i kraft. Hos de fleste producenter er processerne stadig teater. | Guardian360" description: "Cyber Resilience Act's indberetningspligt trådte i kraft den 11. september 2026: producenter skal anmelde aktivt udnyttede sårbarheder og alvorlige hændelser inden for 24 timer. Undersøgelser viser høj bevidsthed, men svag beredskab. Hvad du skal indberette, hvem det gælder for, og hvordan det faktisk ser ud at være forberedt." url: https://guardian360.net/da/blog/cra-reporting-duty-is-live/ locale: en source: guardian360.net --- [← Alle indlæg](https://guardian360.net/da/blog/) Holdning # Cyber Resilience Act's indberetningspligt er trådt i kraft. Hos de fleste producenter er processerne stadig teater. Af Jan Martijn Broekhof · 11. september 2026 I dag, den 11. september 2026, træder Cyber Resilience Act’s indberetningspligt i kraft i hele Den Europæiske Union. Ikke i december 2027, hvor de væsentlige produktkrav lander, og alle har fået at vide, at det er dér, det virkelige opgør kommer. I dag. Hvis du fremstiller et produkt med digitale elementer og sælger det ind på EU-markedet, begynder uret på din første anmeldelse at løbe fra dette øjeblik, uanset om din organisation har noteret datoen eller ej. Jeg skrev i juli, at Cyber Resilience Act var den regulering, ingen fulgte tæt nok med i, den, der kan trække et produkt af markedet i stedet for blot at give virksomheden bag en bøde. Det stykke handlede om det store complianceoverblik: anvendelsesområde, kategorisering, forholdet til NIS2. Dette handler om den langt snævrere og langt skarpere forpligtelse, der netop er trådt i kraft, og om det ubehagelige gab mellem hvor mange producenter, der siger, de kender til den, og hvor mange, der faktisk kan handle på den inden for de timer, loven giver dem. ## Datoen ingen holdt øje med Størstedelen af dækningen af CRA kredser stadig om december 2027, og forståeligt nok, for det er dér, de væsentlige cybersikkerhedskrav og forpligtelserne omkring overensstemmelsesvurdering finder fuld anvendelse. Men artikel 14 i forordningen udskilte en separat og tidligere dato specifikt til indberetning: fra den 11. september 2026 skal producenter anmelde aktivt udnyttede sårbarheder og alvorlige hændelser, der påvirker deres produkter, og den pligt gælder for produkter, der allerede er på markedet, ikke kun nye lanceringer. Europa-Kommissionen offentliggjorde sin praktiske vejledning om dette den 27. juli 2026, blot uger før datoen trådte i kraft. Det er et smalt vindue for en forpligtelse med en frist på 24 timer knyttet til den første anmeldelse. De væsentlige krav i december 2027 giver producenterne cirka femten måneders tilløb fra nu. Indberetningspligten gav langt mindre. ## Hvad skal du egentlig indberette? Det er dette spørgsmål, folk snubler over, og det er værd at besvare præcist frem for i generelle vendinger. Du indberetter en aktivt udnyttet sårbarhed, altså at der er troværdige beviser for, at nogen bruger den mod dit produkt lige nu. Du indberetter en alvorlig hændelse, altså noget, der faktisk kompromitterer dit produkts sikkerhed, ikke blot en teoretisk svaghed. Det, du ikke indberetter, er hver eneste CVE, der bliver tildelt din kodebase, hvert fund fra din egen penetrationstest eller hver indsendelse gennem dit responsible disclosure-program eller din bug bounty, medmindre der er beviser for, at den faktisk er blevet udnyttet. Det webinar, som det hollandske Ministerie van Economische Zaken en Klimaat og National Cyber Security Centre (NCSC) afholdt den 27. august, var kontant om denne skelnen, og med god grund: uden den ville producenter enten drukne deres nationale CSIRT i støj eller, endnu værre, antage, at enhver sårbarhedsanmeldelse kræver den samme hastværk på 24 timer og udmatte det team, der skal håndtere dem, der faktisk betyder noget. Du kan stadig indberette de mindre alvorlige tilfælde frivilligt, og der er gode grunde til at opbygge den vane. Men den juridiske pligt hviler specifikt på aktiv udnyttelse og alvorlige hændelser, og at vide, hvor den grænse går, er det første, din incident response-proces skal have styr på. ## Uret holder ikke pause til dit incident response-møde Så snart du ved det, er tidslinjen faseinddelt og ubarmhjertig. En tidlig advarsel skal ud inden for 24 timer efter, du bliver bekendt med forholdet. En fyldigere anmeldelse følger inden for 72 timer og dækker det, du ved på det tidspunkt om karakteren, konsekvenserne og de afbødende foranstaltninger. En endelig rapport lukker sagen: fjorten dage efter, at en korrigerende foranstaltning bliver tilgængelig for en sårbarhed, eller en måned for en alvorlig hændelse, ifølge Europa-Kommissionens vejledning. Freshfields’ analyse af den nye forpligtelse fremhæver en pointe, der er værd at dvæle ved: indberetningsperioderne begynder i det øjeblik, du bliver bekendt med forholdet, og uret standser ikke i weekender eller på helligdage. Der er ingen frist for det forhold, at din sikkerhedsansvarlige var til konference, eller at hændelsen skete en fredag aften. Hvis din organisation ikke allerede har en defineret proces for, hvem der vurderer en anmeldelse, hvem der afgør, om den overskrider tærsklen, og hvem der indsender den, så bygger du den proces for første gang under en løbende frist på 24 timer, hvilket er præcis det forkerte tidspunkt at bygge noget som helst. Selve indberetningen går gennem din nationale CSIRT, NCSC i Holland, og den EU-dækkende Single Reporting Platform, der drives af ENISA, så en producent i Belgien, Tyskland eller andre steder i EU følger den samme faseinddelte tidslinje gennem sit eget nationale kontaktpunkt. Mekanikken varierer en smule fra medlemsstat til medlemsstat; forpligtelsen og fristerne gør ikke. ## Hvorfor er beredskabstallene så dårlige? Her skal påstanden om, at “hos de fleste producenter er processerne teater”, vise sit værd, og undersøgelsesdataene bakker den mere skarpt op, end jeg havde forventet. ENISA’s SME Cyber Resilience Maturity Assessment Model, offentliggjort den 13. juli 2026 og baseret på feltarbejde med 194 organisationer på tværs af 31 lande, fandt høj bevidsthed om CRA, men konsekvent svag praktisk beredskab, hvor incident response og produktlivscyklusstyring scorede som de to svageste områder overordnet. Bevidsthed om, at en lov findes, er ikke det samme som at have en proces, der kan handle inden for et vindue på 24 timer. Linux Foundation og OpenSSF’s 2026-undersøgelse af CRA-beredskab, baseret på 843 respondenter, fortæller en lignende historie fra en anden vinkel. Seksogtres procent vidste stadig ikke, hvad de faktisk skulle gøre for at overholde reglerne, et tal, der næsten ikke havde flyttet sig fra 62 procent året før. Kun 41 procent af producenterne forventede at nå fuld compliance inden fristen i december 2027, og kun 34 procent identificerede overhovedet den dato korrekt. Blandt de respondenter, der overhovedet var bekendt med CRA, kunne 54 procent stadig ikke tydeligt skelne mellem en producents forpligtelser og en stewards. Intet af det er en kritik af noget enkelt complianceteam. Det afspejler en regulering, der bevægede sig fra abstrakt til operationel hurtigere, end de fleste organisatoriske processer kunne følge med. Men det betyder, at en betydelig andel af de producenter, der læser dette, krydsede grænsen den 11. september uden nogen afprøvet proces bag sig, hvilket er præcis det scenarie, indberetningspligten var udformet til at afsløre. ## Hvem skal egentlig indberette? Under CRA hviler indberetningsforpligtelsen på producenten, den enhed, der bringer et produkt med digitale elementer på EU-markedet under sit eget navn eller mærke, og organisationens størrelse fritager dig ikke. En importør eller distributør bærer generelt ikke en selvstændig indberetningspligt, medmindre den sælger under sit eget mærke eller ændrer produktet væsentligt, i hvilket tilfælde den reelt bliver producenten for det pågældende produkt. Stewards af open source-software står over for en lettere version af den samme pligt, hvilket afspejler det anderledes forhold, de har til de produkter, de vedligeholder. Små virksomheder og mikrovirksomheder er også fuldt omfattet; den eneste indrømmelse, den hollandske NCSC har bekræftet, er, at der ikke er nogen sanktion for at overskride det strikse vindue på 24 timer i den kategori, hvilket er en afbødning, ikke en fritagelse. En detalje er værd at fremhæve, fordi den skaber reel forvirring: CRA kræver ikke i sig selv nogen forudgående registrering, før du kan indberette. Du behøver ikke en konto eller et login for at indsende en anmeldelse. Det er et bevidst designvalg, adskilt fra den registreringspligt, der findes under Cyberbeveiligingswet (den hollandske gennemførelse af NIS2) for organisationer, der også er omfattet af den lov. De to forpligtelser løber parallelt, ikke som én samlet proces, og at blande dem sammen er en let fejl at begå. ## Hvordan ser “forberedt” egentlig ud? At forberede sig på CRA’s indberetningspligt er i princippet ikke kompliceret. Det er krævende i praksis, hvilket er et andet problem. Begynd med en ærlig opgørelse over, hvad der faktisk er i dine produkter, ideelt set gennem en Software Bill of Materials (SBOM), for du kan ikke vurdere, om en anmeldt sårbarhed rammer dig, hvis du ikke ved, hvilke komponenter du leverer. Fastsæt på forhånd dine egne interne tærskler for, hvad der tæller som aktiv udnyttelse eller en alvorlig hændelse, så den vurdering ikke bliver truffet for første gang under pres. Byg en eskaleringsvej med navngivne roller: hvem der slår alarm, hvem der beslutter, hvem der indsender. Udarbejd skabeloner til den tidlige advarsel, 72-timers anmeldelsen og den endelige rapport nu, mens ingen er under en frist. Og afstem dette med det, du i forvejen indberetter under, for en pæn andel af de producenter, der læser dette, er også omfattet af Cyberbeveiligingswet eller AVG, og at køre tre ukoordinerede indberetningsprocesser er en risiko i sig selv. Det er, ikke tilfældigt, den samme disciplin, jeg argumenterede for i juli, da jeg skrev om CRA’s bredere compliancekrav: vid, hvad du har, kategorisér det ærligt, og byg papirarbejdet, før tilsynsmyndigheden beder om det. Indberetningspligten har blot flyttet det argument fra “på et tidspunkt” til “nu”. Hvis en kunde i morges fortalte dig, at nogen aktivt udnyttede en sårbarhed i dit produkt, ville din organisation så vide, inden for 24 timer, præcis hvem der tager imod den anmeldelse? Hvis det ærlige svar er “det finder vi ud af”, så trådte indberetningspligten ikke i kraft i dag for ingenting. ## Kilder - European Commission, Cyber Resilience Act, Reporting obligations, Shaping Europe’s Digital Future: [digital-strategy.ec.europa.eu/en/policies/cra-reporting](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) - ENISA, SME Cyber Resilience Maturity Assessment Model, published 13 July 2026. - Linux Foundation Research, Linux Foundation Europe, and OpenSSF, “The CRA Readiness Reality: What Changed (and What Didn’t) Between 2025 and 2026?”, June 2026: [linuxfoundation.org](https://www.linuxfoundation.org/blog/the-cra-readiness-reality-what-changed-and-what-didnt-between-2025-and-2026) - Freshfields, “Cyber Resilience Act reporting obligations take effect on 11 September 2026”: [freshfields.com](https://www.freshfields.com/en/our-thinking/blogs/technology-quotient/cyber-resilience-act-reporting-obligations-take-effect-on-11-september-2026-102nzmk) - Ministry of Economic Affairs and Climate Policy and National Cyber Security Centre (NCSC), Cyber Resilience Act, Themasessie Meldplicht (webinar), 27 August 2026.