Der er sket noget. Hvornår blev I opmærksomme på det?

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.

Hvilket CSIRT anmelder du til under CRA artikel 14? Alle 27 koordinatorer, som ENISA anfører dem

Enhver guide til Cyber Resilience Acts anmeldelsespligt siger \"anmeld til jeres nationale CSIRT\" og stopper der. Siden den 10. september 2026 offentliggør ENISA det CSIRT, der er udpeget som koordinator, for hver af de 27 medlemsstater. Her er listen, reglen, der afgør staten, og de to stater, hvor koordinatoren ikke er det nationale CSIRT.

Sådan indgiver du en CRA-anmeldelse på ENISA's fælles anmeldelsesplatform, efter dens egen manual

Platformen åbnede den 11. september 2026 på portal.cra-srp.enisa.europa.eu. Hvem der kan logge ind, hvilken koordinator du vælger, hvad hver af de tre indgivelser spørger om, hvad platformens egen tæller regner forkert, og hvornår du må bede om udsat videregivelse. Læst i ENISA's vejledninger, FAQ, ordliste og vilkår, ikke i et resumé af dem.

Hvornår starter CRA's 24-timers ur? \"At få kendskab\", efter Kommissionens vejledning

De 24 og 72 timer løber fra det øjeblik, fabrikanten \"får kendskab\", og forordningen siger aldrig, hvad det betyder. Kommissionens vejledning af 27. juli 2026 gør det, i punkt 211 til 218: en rimelig grad af sikkerhed efter en indledende vurdering, overtaget ord for ord fra NIS2-gennemførelsesforordningen og GDPR-retningslinjerne om databrud. Hvad det gør en kundemail, en scanneralarm, en listet CVE i en komponent, en bug bounty-zero-day og en sårbarhed, I kendte før den 11. september, til.

Uret for den endelige CRA-rapport starter ikke, når I får kendskab

De fleste fremstillinger af artikel 14 i Cyber Resilience Act giver tre frister fra ét startpunkt: 24 timer, 72 timer, 14 dage. De to første løber fra kendskab. Den tredje gør ikke, og for en sårbarhed er dens anker en dato, der måske ikke findes endnu. Her står, hvad forordningen siger, stykke for stykke.

Er dit produkt omfattet af Cyber Resilience Act? Hvor SaaS står

Det hyppigste CRA-spørgsmål er ikke, hvordan man anmelder, men om forordningen overhovedet gælder for jer. Ren software as a service er udenfor og under NIS2; installeret og downloadet software er indenfor; fjernbehandling, som et produkt ikke kan fungere uden, er indenfor igen. Fastlæggelsen er jeres at træffe og dokumentere. Her er teksten, der afgør den.

Hvornår er software \"bragt i omsætning\" efter CRA, og hvilken af jeres builds er et produkt? Vejledningens regel for selvstændig software

Alt i CRA hænger på en dato og et navneord: den dato, et produkt bringes i omsætning, og om det, I udgiver, overhovedet er et produkt. For selvstændig software besvarer Kommissionens vejledning af 27. juli 2026 begge dele i punkt 13 til 21: En version bringes i omsætning én gang, når den første gang udbydes, og hver senere download tæller fra den dag; builds pr. operativsystem og funktionspakker er særskilte produkter; en webapp brugt i en browser er ikke et produkt, en browserudvidelse eller en installeret klient er. Hvad det betyder for den 11. december 2027, for betaer og for gamle versioner, I lader ligge online.

Hvilke dele af jeres backend ligger inden for CRA? Fjerndatabehandling, efter Kommissionens vejledning

Et produkt med digitale elementer omfatter sine fjerndatabehandlingsløsninger, og forordningen definerer dem i én sætning. Kommissionens vejledning af 27. juli 2026 gør den sætning til to kumulative tests, en afgrænsningsregel, en liste over det, der aldrig er med (CI/CD, HR, CRM, telemetri, websteder), tilfældene SaaS, PaaS og IaaS og et gennemregnet eksempel med mobilbank. For en softwarevirksomhed med en app og en sky er dette grænsen.

Hvem håndhæver Cyber Resilience Act i din medlemsstat? 7 ud af 27 har sagt det

CRA håndhæves nationalt af en markedsovervågningsmyndighed, som hver medlemsstat udpeger og registrerer hos Kommissionen. Den 11. september 2026, den dag anmeldelsespligten begyndte at gælde, havde syv stater registreret én. Her er registret, stat for stat, inklusive de tyve, der ikke har, og hvad det betyder for en lille fabrikant, der spørger, hvem der kommer og banker på.

Er dit produkt vigtigt eller kritisk efter Cyber Resilience Act? Bilag III og IV i fuld længde

Når et produkt er omfattet af CRA, er det standard, vigtigt (klasse I eller II) eller kritisk, og trinnet afgør, om I selv må vurdere eller skal bruge et bemyndiget organ. Her er de 19, 4 og 3 kategorier ordret fra EU-Tidende, hvad hvert trin ændrer efter artikel 32, og det ene, trinnet ikke ændrer.

Standard, vigtigt eller kritisk: de 26 tekniske beskrivelser i gennemførelsesforordning 2025/2392 og kernefunktionalitetstesten

Bilag III og IV til CRA nævner 26 produktkategorier på én linje hver. Kommissionens gennemførelsesforordning (EU) 2025/2392, i kraft siden den 21. december 2025, beskriver hver af dem teknisk, og Kommissionens vejledning af 27. juli 2026 siger, hvordan man klassificerer efter dem: efter produktets kernefunktionalitet, ikke efter hvad det også gør eller integrerer. Alle 26 beskrivelser ordret, vejledningens seks regler med dens eksempler (SOAR er ikke SIEM, en logviser er ikke SIEM, en router med firewall er en router), og hvad klassificeringen ændrer.

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.

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.

Hvad CRA kræver af jer for jeres afhængigheder: fornøden omhu, indberetning opstrøms og kendte udnyttelige sårbarheder, efter Kommissionens vejledning

Et softwareprodukt er mest andres kode. CRA gør fabrikanten ansvarlig for produktet som helhed og giver den tre pligter over for komponenterne i det: fornøden omhu efter artikel 13(5), indberetning af sårbarheder opstrøms og deling af rettelser efter artikel 13(6), og at bringe produktet i omsætning uden kendte udnyttelige sårbarheder. Kommissionens vejledning af 27. juli 2026, afsnit 3.4, 7.3 og 9.2, siger, hvad hver kræver, og hvad den ikke kræver: ingen dobbelte indberetninger, ingen pligt til at få jeres rettelse merget, og en definition af \"kendt\", der omfatter CVE-databasen og nyhederne.

CRA eller NIS2: Hvilken gælder for en softwarevirksomhed, og kan det være begge?

Cyber Resilience Act regulerer produkter, der bringes i omsætning; NIS2 regulerer enheder, der leverer tjenester. En softwarevirksomhed kan være under den ene, den anden, begge eller ingen, og svaret afhænger af to spørgsmål: Bringer I et produkt i omsætning, og er I en mellemstor eller større enhed i en opført sektor. Datoerne, anmeldelsesurene, bøderne og beslutningstabellen, fra de to tekster.

NIS2 eller CRA: hvilket hændelsesur løber for en softwarevirksomhed, og hvad gør en hændelse 'væsentlig'

Begge love giver jer 24 timer, 72 timer og en måned, og begge starter uret, når I 'får kendskab'. Næsten alt andet er forskelligt: hvad der udløser det, hvem der modtager det, på hvilken platform, og hvad der tæller. NIS2 artikel 23 og gennemførelsesforordning 2024/2690 for virksomheden, der driver en cloudtjeneste; CRA artikel 14 for virksomheden, der leverer et produkt; begge for virksomheden, der gør begge dele. Tærsklerne, kriterium for kriterium, og én procedure, der opfylder begge.

Skal software CE-mærkes efter CRA? Ja, og artikel 30 siger, hvor mærket skal sidde

Fra den 11. december 2027 kræves der CE-mærkning på ethvert produkt med digitale elementer, der bringes i omsætning på EU-markedet, software inklusive. For software sættes mærket på EU-overensstemmelseserklæringen eller på det websted, der ledsager produktet, før det bringes i omsætning. Hvad mærket hævder, hvem der må anbringe det, hvornår et bemyndiget organs nummer føjes til, og hvad erklæringen bag det skal indeholde.

EU-overensstemmelseserklæringen under CRA: bilag V punkt for punkt, den forenklede form og et udfyldt eksempel

Artikel 28 pålægger fabrikanten at udfærdige en EU-overensstemmelseserklæring, før produktet bringes i omsætning, efter modellen i bilag V, og artikel 28(4) gør underskriften til den handling, hvormed fabrikanten påtager sig ansvaret for produktet. De otte punkter i bilag V, den forenklede form på én sætning i bilag VI, reglerne omkring den (sprog, den enkelte erklæring, produktfamilier, 10 års opbevaring), et udfyldt eksempel, og hvad en manglende eller forkert erklæring koster efter artikel 58 og artikel 64.

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\".

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.

Hvor lang er supportperioden efter CRA? Mindst fem år, og tre andre ure, der hænger på den

Artikel 13, stk. 8, i Cyber Resilience Act kræver en supportperiode på mindst fem år, eller den forventede brugstid hvis den er kortere, hvor sårbarheder håndteres. Slutdatoen skal vises ved købet, mindst måned og år. Sikkerhedsopdateringer skal forblive tilgængelige i ti år eller supportperioden. Og den tekniske dokumentation, erklæringen og brugeroplysningerne opbevares lige så længe. De fire ure, fra teksten.

Hvilken opdatering bringer jeres eksisterende software ind under CRA? Væsentlige ændringer, efter Kommissionens vejledning

Software bragt i omsætning før den 11. december 2027 forbliver uden for CRA's design- og overensstemmelsespligter, indtil den ændres væsentligt. Kommissionens vejledning af 27. juli 2026 siger i punkt 103 til 113 og 122 til 124, hvad det betyder for en softwareopdatering, med elleve gennemregnede eksempler: en risiko, der ikke står i jeres risikovurdering, ikke størrelsen af diffen. Sikkerhedsopdateringer er som regel ude; et \"husk mig\"-felt kan være inde. Hvad der skal skrives ind i hver udgivelse, og hvad den første væsentlige ændring udløser og ikke udløser.

Hvad I skal anmelde efter CRA: de to udløsere, som forordningen definerer dem

Artikel 14 har to udløsere, og begge er defineret i teksten. En aktivt udnyttet sårbarhed er en, for hvilken der foreligger pålidelige beviser for, at en ondsindet aktør har udnyttet den i et system uden ejerens tilladelse (artikel 3, nr. 42). En alvorlig hændelse er en, der påvirker eller kan påvirke produktets evne til at beskytte følsomme data eller funktioner, eller som fører eller kan føre til ondsindet kode i produktet eller i en brugers systemer (artikel 14, stk. 5). Hvad der er inde, hvad der er ude, og pligten til at informere brugerne, der følger med begge.

Gælder CRA for open source-software? Tre tilfælde, og den lette ordning for forvaltere

Cyber Resilience Act når fri og open source-software kun, når den leveres som led i en kommerciel aktivitet. Et projekt, der ikke monetariseres, er ude. En virksomhed, der leverer et produkt bygget på open source-komponenter, er fabrikant af det produkt. Og fonde og virksomheder, der understøtter open source-produkter til kommerciel brug, er \"forvaltere af open source-software\" efter artikel 24: en cybersikkerhedspolitik, samarbejde med myndigheder og en indsnævret anmeldelsespligt, uden CE-mærkning og uden teknisk dokumentation. Betragtningerne og artiklen, citeret.

Er jeres open source-projekt \"kommercielt\" under CRA? Kommissionens syv tests, med dens eksempler

CRA når kun fri og open source-software, hvor den leveres som led i en kommerciel aktivitet, og forordningen overlader \"kommerciel\" til to betragtninger. Kommissionens vejledning af 27. juli 2026, afsnit 3, gør dem til syv tests: en pris, en betalt udgave eller open core, at tjene penge på andre tjenester eller personoplysninger, supporttjenester, donationer, sponsorering og almennyttig status, med 22 eksempler. Hvor en maintainer, en open core-virksomhed og en fond hver især lander, og hvad en pull request gør jer til.

Hvad CRA kræver af importører og distributører, og hvornår den gør dem til fabrikant

Hvis I videresælger software eller enheder ind i EU i stedet for at bygge dem, giver artikel 19 og 20 i Cyber Resilience Act jer en tjekliste at gennemgå, før produktet kommer til salg, en pligt til at give sårbarheder videre til fabrikanten, en pligt til at underrette myndighederne om væsentlige risici og ti års opbevaring. Artikel 21 gør jer til fabrikant, i det øjeblik I sælger under eget mærke eller ændrer produktet væsentligt. Pligterne, fra teksten.

EU's eget CRA-maskineri den dag, pligten begyndte: 0 bemyndigede organer, 0 harmoniserede standarder, 7 ud af 27 håndhævere

Cyber Resilience Act beder fabrikanter om at være klar. Her er, hvor klar de institutioner, den afhænger af, var den 11. og 12. september 2026, læst i Kommissionens egne registre: intet overensstemmelsesvurderingsorgan bemyndiget under CRA, ingen harmoniseret standard offentliggjort i EU-Tidende, syv medlemsstater med en registreret markedsovervågningsmyndighed, tretten med en bemyndigende myndighed, og listen over koordinerende CSIRT'er offentliggjort dagen før, hvor to stater nævner en anden myndighed end deres nationale CSIRT. Hvad det betyder for en fabrikant med et klasse I-produkt, og hvad der skal noteres.

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.

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.