...
Spørgsmål om Cyber Resilience Act
Her er de spørgsmål, softwarehuse oftest stiller om forordning (EU) 2024/2847, med et kort svar på hvert. Linket under svaret fører til artiklen, der går i dybden. Svarene forenkler reglerne og er generel viden, ikke juridisk rådgivning. Hvor intet andet står, gælder kravene fra 11. december 2027; indberetningspligten i artikel 14 gælder allerede.
Gennemgangen
Hvornår træder Cyber Resilience Act i kraft?
Forordningen trådte i kraft 10. december 2024 og gælder i tre trin efter artikel 71: bemyndigede organer fra 11. juni 2026, indberetningspligten fra 11. september 2026 og alt det øvrige fra 11. december 2027.
→ Køreplan til 11. december 2027
Hvad er en CRA-gennemgang?
En uvildig kontrol af ét softwareprodukt og den udviklings- og sårbarhedsproces, der ligger bag, målt mod forordningens krav. Den viser afstanden til kravene og det bevis, der mangler.
Giver en uvildig gennemgang CE-mærket?
Nej. CE-mærket følger af fabrikantens egen overensstemmelsesvurdering eller et bemyndiget organs vurdering. En gennemgang kan forberede den, men den afgør ikke overensstemmelse.
→ Gennemgang, CE-vurdering og certifikat
Hvornår i udviklingen giver en gennemgang mest?
Mens designet og risikovurderingen stadig kan ændres, før første frigivelse eller ved en væsentlig ændring. Hvert tidspunkt finder noget forskelligt.
Hvad måler en gennemgang imod, når der ingen standarder er?
Mod forordningens krav, bilag I og en målestok, fabrikanten vælger og begrunder, fx en udkaststandard eller en anden teknisk specifikation. Det giver ingen formodning om overensstemmelse.
→ CRA foreskriver ingen metode
Er produktet omfattet?
Hvornår er software et produkt efter CRA?
Når brugeren får den leveret og afvikler den på sit eget udstyr. Software, der kun kører hos jer og tilgås over nettet, er normalt ikke i sig selv et produkt.
→ Prøven for, om softwaren er et produkt
Er SaaS omfattet?
En ren SaaS-løsning er som udgangspunkt uden for. En installeret klient, en app eller et produkt, der er afhængigt af tjenesten, kan trække den ind som fjerndatabehandling.
Hvilke dele af backenden hører med til produktet?
Den fjerndatabehandling, fabrikanten har ansvaret for, og som produktet ikke kan udføre en funktion uden. Grænsen trækkes ved det, klienten taler direkte med.
Er en mobilapp et selvstændigt produkt?
Det kommer an på, hvad appen gør. Styrer den fx en andens apparat, kan den høre til det apparat, og det flytter dokumentationen.
Er et plugin eller en browserudvidelse omfattet?
Ja, som udgangspunkt er udvidelsen et produkt. I dokumenterer jeres egen kode og beskriver afhængigheden af den platform, I ikke styrer.
→ Udvidelser til andres platform
Gælder CRA for et bibliotek eller et SDK, vi sælger?
Ja. Sælger I en komponent særskilt, er I fabrikant af den, og integratoren skal have de oplysninger, forordningen kræver.
Er kildekode, vi licenserer til kunder, også et produkt?
Kommissionen regner kildekode, der leveres til kunder, som bragt i omsætning, også når kunden selv kompilerer den.
→ Kildekode leveret til kunden
Er software udviklet til én kunde undtaget?
Nej, den er stadig et produkt. To krav kan fraviges ved aftale med en erhvervskunde, og skræddersyningen skal kunne dokumenteres.
→ Software til én erhvervskunde
Hvem er fabrikant, når kunden sælger vores software under eget navn?
Kunden, fordi den markedsfører produktet under sit navn. Kunden vil derfor bede jer om dokumentation, komponentliste og hjælp med sårbarheder.
→ Kunden sælger under eget navn
Hvad gælder for white label?
Står jeres varemærke på en andens software, bliver I fabrikant. Aftalen med producenten skal give jer adgang til dokumentation og rettelser.
Er software, der ikke koster noget, uden for forordningen?
Ikke nødvendigvis. Freemium, betaling med data eller indtægt fra tilknyttede ydelser kan gøre leveringen erhvervsmæssig.
Hvornår er en version bragt i omsætning?
Når den første gang udbydes i EU. Alle senere kopier af samme version følger den dato, og derfor skal I have et register over versioner.
→ Hvornår er softwaren bragt i omsætning?
Gælder kravene for versioner, der kom ud før 11. december 2027?
Kun hvis en senere release er en væsentlig ændring, og så kun for den del, der er ændret. Indberetningspligten gælder dog alle omfattede produkter.
→ Versioner fra før 11. december 2027
Må vi udgive betaversioner?
Ja, ufærdig software må stilles til rådighed til afprøvning i en begrænset periode og med tydelig mærkning af, at den ikke opfylder kravene.
→ Betaversioner og release candidates
Er et tillægsmodul et eget produkt?
Sælges modulet særskilt med egen licens eller eget abonnement, behandler Kommissionens vejledning det som et selvstændigt produkt med egen klasse.
Kan flere varianter dele én risikovurdering?
Kun hvis de har samme komponenter og funktioner. Builds, der adskiller sig der, er særskilte produkter.
→ Udgaver, varianter og produktfamilier
Hvad gør vi, når et krav ikke kan opfyldes fuldt?
Dokumenter begrænsningen, fx en ældre protokol, som interoperabilitet kræver, oplys brugeren om den, og kompenser med andre foranstaltninger.
→ Kravet kan ikke opfyldes fuldt
Er medicinsk software undtaget?
Undtagelsen gælder software, som i sig selv er medicinsk udstyr. Software omkring udstyret skal efter vores læsning stadig prøves efter CRA.
Hvad med software med AI-funktioner?
Er produktet et højrisiko-AI-system, kan opfyldelse af CRA give formodning om AI-forordningens krav til cybersikkerhed.
Open source
Gælder CRA for open source?
Ja, men rollen findes for hvert projekt for sig, og svaret kan blive fabrikant, forvalter eller ingen pligter.
→ Open source i jeres forretning
Hvad er en open source software-forvalter?
En organisation, der løbende støtter et open source-projekt, som bruges kommercielt, men som ikke selv er fabrikant af det. Forvalteren har lettere pligter og skal have en dokumenteret cybersikkerhedspolitik.
Bliver vi fabrikant, hvis vi har en betalt udgave ved siden af community-udgaven?
For den betalte udgave, ja. Community-udgaven kan have en anden rolle, så pligterne skal holdes adskilt.
→ Community-udgave og betalt udgave
Gør betalt support os til fabrikant?
Det afhænger af aftalen. Nogle klausuler kan vippe rollen, så supportaftalen skal læses punkt for punkt.
→ Betalt support til open source
Bliver et konsulenthus fabrikant ved at tilpasse open source hos kunden?
Installation og rådgivning gør det ikke. En væsentlig ændring kan, og derfor skal ændringerne dokumenteres.
Risikovurdering og udvikling
Hvad skal risikovurderingen indeholde?
Formål, rimeligt forudsigelig brug, driftsmiljø, forventet brugstid og en stillingtagen til hvert krav i bilag I.
→ Cybersikkerhedsrisikovurderingen
Må vi skrive “ikke relevant” ved et krav?
Ja, med en klar begrundelse, der passer med softwarens faktiske adfærd.
Hvilken risikometode kræver CRA?
Ingen bestemt. I vælger metoden og begrunder valget, og den skal kunne efterprøves.
→ CRA foreskriver ingen metode
Kan vi acceptere en risiko, fordi det er for dyrt at fjerne den?
Nej. Restrisikoen måles mod et passende niveau, og egne omkostninger eller kommercielle hensyn begrunder ikke en ubehandlet risiko.
Kan en advarsel i manualen dække en designfejl?
Nej. Risiko ved forudsigelig fejlanvendelse kan ikke flyttes over på brugeren med en anvisning.
→ Risikoen kan ikke flyttes til brugeren
Hvad gør vi med en sårbarhed, der dukker op lige før release?
Afgør ud fra risikovurderingen, om versionen kan gå ud, og skriv beslutningen og grunden ned.
→ Ny sårbarhed kort før release
Hvor tit skal risikovurderingen opdateres?
Når noget ændrer risikobilledet i supportperioden, fx nye trusler, nye funktioner eller ændrede afhængigheder.
→ Risikovurderingen i supportperioden
Hvad betyder regelmæssige afprøvninger?
Kommissionen læser det som et program, der følger nye trusler og sårbarheder, ikke som en fast kalender.
Krav til produktet
Hvornår er en sårbarhed “kendt” ved frigivelse?
Forordningen definerer begge ord, og Kommissionen afviser, at kravet betyder fejlfri software. I skal kunne vise, hvad I vidste på frigivelsesdagen, og hvordan I vurderede det.
→ Ingen kendte udnyttelige sårbarheder
Hvad betyder sikker som standard?
At en ny installation er sikker, uden at brugeren skal ændre indstillinger, og at den kan nulstilles til den sikre tilstand.
→ Sikker standardkonfiguration
Skal sikkerhedsopdateringer være automatiske?
De skal være slået til fra starten, hvor det giver mening, og brugeren skal kunne slå dem fra. Forordningen har undtagelser, og jeres ansvar har en grænse.
→ Automatiske sikkerhedsopdateringer
Kræver CRA kryptering?
Kryptering er forordningens eksempel på at beskytte fortrolighed. Produktet må gerne bygge på platformens kryptering, og der bør være en plan for at skifte algoritme.
Gælder dataminimering også telemetri uden personoplysninger?
Ja. Kravet gælder alle data, produktet behandler, ikke kun personoplysninger.
Skal softwaren have en sikkerhedslog?
Ja, relevante hændelser skal registreres, og brugeren skal kunne fravælge logningen.
Skal brugeren kunne slette sine data?
Ja, permanent, og data skal kunne flyttes sikkert til et andet produkt, hvor det er muligt.
→ Sikker sletning og flytning af data
SBOM og komponenter
Kræver CRA en SBOM?
Ja. Fabrikanten skal udarbejde en softwarekomponentliste i et almindeligt anvendt, maskinlæsbart format.
→ Softwarekomponentlisten efter CRA
Hvor dybt skal komponentlisten gå?
Lovens minimum er de øverste afhængigheder. Sårbarhedsovervågning kræver i praksis ofte mere.
Skal vi give kunderne vores SBOM?
Myndigheden kan kræve den efter en begrundet anmodning. Over for kunder er det frivilligt, og den skal ikke offentliggøres.
→ Skal kunderne have komponentlisten?
Skal hver version have sin egen komponentliste?
Den tyske retningslinje siger ja. Forordningen kræver ajourført dokumentation, der gemmes i ti år, og det trækker i samme retning.
→ En komponentliste for hver version
Hvad gør vi med en sårbarhed i en afhængighed, der ikke rammer os?
Lav en skrevet vurdering af, hvorfor den ikke kan udnyttes i jeres produkt, og gem den som bevis.
Skal vi melde en fejl i en andens komponent?
Ja, til den, der vedligeholder komponenten, og I skal dele rettelsen, hvis I har lavet en.
→ Sårbarhed i en andens komponent
Hvad hvis en komponent mister sin vedligeholder?
Jeres pligt fortsætter. Sammenhold komponentens forventede levetid med jeres supportperiode, og læg en plan.
→ Komponent uden vedligeholder
Sårbarheder og opdateringer
Har CRA en fast frist for at rette sårbarheder?
Nej, ingen frist i dage. Hver sårbarhed skal vurderes og håndteres efter risiko, og registret viser, om jeres egne frister holder.
Skal vi have en politik for koordineret offentliggørelse?
Ja, og et kontaktpunkt, hvor sårbarheder kan meldes. Politikken skal også følges i praksis.
Må sikkerhedsopdateringer koste penge?
Nej, de skal være uden betaling og uden unødigt ophold. Undtagelser gælder for skræddersyede produkter efter aftale.
→ Uden betaling og uden ophold
Må vi kun rette i nyeste version?
Det kan I, når artikel 13, stk. 10, er overholdt. Visse pligter gælder stadig alle versioner.
→ Kun nyeste version understøttes
Skal sikkerhedsrettelser udgives adskilt fra nye funktioner?
Hvor det er teknisk muligt. Frigivelseshistorikken viser, om det sker.
→ Adskilte sikkerhedsopdateringer
Hvor længe skal en sikkerhedsopdatering kunne hentes?
Mindst ti år fra udgivelsen, og længere, hvis supportperioden rækker videre.
Hvornår er en release en væsentlig ændring?
Kommissionen bruger fire prøvesten. En ren sikkerhedsopdatering er som udgangspunkt ikke en væsentlig ændring.
Hvor lang skal supportperioden være?
Den skal afspejle, hvor længe produktet forventes brugt, og er som udgangspunkt mindst fem år.
Kan supportperioden være kortere end fem år?
Kun hvis produktet forventes brugt i kortere tid, og det skal kunne bevises.
Hvor skal slutdatoen for support stå?
Ved købet med måned og år, og brugeren skal have besked i programmet, når supporten udløber, hvor det er teknisk muligt.
Hvad skal vi gøre, hvis virksomheden lukker?
Underrette myndigheden og brugerne, før lukningen får virkning.
→ Softwarehuset indstiller driften
Indberetning
Gælder indberetningspligten allerede?
Ja. Artikel 14 har været i kraft siden 11. september 2026, og ældre produkter på markedet er med.
→ Indberetningspligten gælder nu
Hvad skal indberettes?
Aktivt udnyttede sårbarheder og alvorlige hændelser, der påvirker produktets sikkerhed.
→ Indberetning efter artikel 14
Hvilke frister gælder?
Først en tidlig varsling på højst 24 timer, så en meddelelse på højst 72 timer og til sidst en slutrapport. For en sårbarhed kommer slutrapporten senest to uger efter, at brugerne kan få en rettelse eller afbødning.
→ 24 timer, 72 timer og slutrapporten
Hvornår begynder fristen at løbe?
Fra det tidspunkt, hvor I har fået kendskab, dvs. når en første vurdering gør det rimelig sikkert, at nogen udnytter sårbarheden.
→ Hvornår har I fået kendskab?
Hvor indberetter vi?
På den fælles indberetningsplatform, som ENISA driver, med personligt login og flerfaktorgodkendelse. Indberetningen går til den koordinerende CSIRT.
→ Den fælles indberetningsplatform
Er et hacket byggemiljø en alvorlig hændelse?
Det kan det være, hvis det påvirker produktets sikkerhed, fx ved en kompromitteret opdateringsserver.
Skal en sårbarhed fundet af vores egne testere indberettes?
Ikke efter artikel 14, når intet tyder på, at den er udnyttet. Vurderingen skal dokumenteres.
→ Fundet af egne testere eller forskere
Skal brugerne have besked?
Ja, de berørte brugere skal underrettes om sårbarheden eller hændelsen og om, hvad de kan gøre.
Dækker en NIS2-underretning også CRA?
Nej. Pligterne har forskellige modtagere, frister og indhold, og samme hændelse kan udløse begge og en anmeldelse af persondatabrud.
Kan vi melde frivilligt?
Ja, artikel 15 åbner for frivillig indberetning af sårbarheder, trusler og nærvedhændelser. Den bestemmelse gælder fra 11. december 2027.
Kan en indberetning rettes, efter den er sendt?
Ja, indtil den endelige rapport er indgivet.
→ Ret og opdatér en indberetning
Vigtige produkter
Hvad er et vigtigt produkt?
Et produkt, hvis væsentligste funktionalitet svarer til en kategori i bilag III, klasse I eller II.
Bliver vores app et vigtigt produkt, fordi den indeholder en VPN-komponent?
Ikke i sig selv. Det er kernefunktionen, der afgør klassen, men komponenten skal stadig vurderes.
Er et logværktøj det samme som et SIEM?
Nej. SIEM står i klasse I, et simpelt logværktøj er generelt ikke et vigtigt produkt.
Skal et klasse I-produkt altid have et bemyndiget organ?
Ja, medmindre I følger en harmoniseret standard, fælles specifikationer eller en europæisk certificeringsordning hele vejen. Da ingen standarder var offentliggjort i november 2026, skal I planlægge med et organ.
→ Klasse I uden harmoniseret standard
Hvordan finder vi et bemyndiget organ?
Ved opslag i Kommissionens database NANDO. Reglerne om organerne har gældt siden 11. juni 2026.
→ Findes der et bemyndiget organ?
Hvad er modul H?
Fuld kvalitetssikring, hvor et organ godkender softwarehusets kvalitetssystem og fører løbende kontrol. Passer til virksomheder med mange produkter.
→ Modul H
Dokumentation og erklæring
Hvad skal den tekniske dokumentation indeholde?
De punkter, bilag VII lister, blandt andet produktbeskrivelse, design, risikovurdering, sårbarhedsproces og testresultater.
→ Teknisk dokumentation efter bilag VII
Hvor længe skal dokumentationen gemmes?
I ti år efter, at produktet er bragt i omsætning, eller i supportperioden, hvis den er længere.
→ Dokumentation ved ugentlige releases
Hvor skal CE-mærket stå på software?
På EU-overensstemmelseserklæringen eller på den hjemmeside, der følger produktet, og det skal være let at finde.
Hvem underskriver EU-overensstemmelseserklæringen?
Fabrikanten selv. Hverken en rådgiver eller et bemyndiget organ kan underskrive den i jeres sted.
→ EU-overensstemmelseserklæringen
Hvad er modul A?
Fabrikantens egen kontrol af produktet efter bilag VIII, del I. Det er den almindelige vej for produkter, der ikke er vigtige eller kritiske.
→ Modul A
Får små softwarehuse lempelser?
Nogle: en forenklet teknisk dokumentation, lavere gebyrer og en bødefritagelse ved visse frister. Kravene til produktet lempes ikke.
Er der harmoniserede standarder under CRA?
Ikke pr. november 2026. Der arbejdes på dem, og flere frister er forlænget.
Handelsled og kunder
Hvad skal en importør af software kontrollere?
At fabrikanten har gennemført den rette vurdering, at dokumentation og CE-mærke findes, og at brugeroplysningerne følger med.
Hvad gør en forhandler, der hører om en sårbarhed?
Underretter fabrikanten og i visse tilfælde myndigheden, stopper salget, hvis det er nødvendigt, og dokumenterer forløbet.
→ Importør eller forhandler hører om en sårbarhed
Hvad kan vi svare kunder, der beder om CRA-dokumentation nu?
Vis beredskabet til indberetning og status for arbejdet med resten. Lov ikke overensstemmelse, før kravene gælder.
→ Kunden beder om CRA-dokumentation
Dækker vores ISO 27001-certifikat CRA?
Nej. Certifikatet handler om organisationen, CRA om produktet. Noget dokumentation kan genbruges.
Hvor længe skal vi kunne vise, hvem vi har købt af og solgt til?
Ti år regnet fra leveringen.
Tilsyn og sanktioner
Hvem fører tilsyn med CRA i Danmark?
Ifølge et dansk høringsudkast bliver det Styrelsen for Samfundssikkerhed. Pr. 13. november 2026 var lovforslaget endnu ikke lagt frem.
Hvad kan myndigheden bede et softwarehus om?
Oplysninger, dokumentation, eksemplarer af produktet og adgang til miljøer og lokaler.
Hvordan straffes overtrædelser?
Forordningen har et bødeloft i tre niveauer. Det danske udkast lader domstolene udmåle bøden efter politianmeldelse.
Hvad er formelle mangler?
Fejl ved CE-mærke, erklæring eller teknisk dokumentation, som myndigheden kan konstatere uden at undersøge selve softwaren.
Kan myndigheden gribe ind, selv om produktet opfylder kravene?
Ja, efter artikel 57, hvis produktet alligevel udgør en væsentlig risiko.
Hvad sker der med kildekode, vi udleverer til myndigheden?
Den er omfattet af tavshedspligt efter artikel 63, og det danske lovudkast lægger op til at begrænse aktindsigten.
Produktansvar
Er software omfattet af produktansvar?
Ja. Direktiv 2024/2853 regner software som et produkt, og reglerne gælder for produkter med omsætningsdato efter 9. december 2026.
→ Software i det nye produktansvarsdirektiv
Kan en manglende sikkerhedsopdatering gøre produktet defekt?
Ja, fabrikanten kan hæfte for skade, hvis en opdatering inden for dens kontrol mangler.
→ Manglende sikkerhedsopdatering som defekt
Behandles SaaS ens i CRA og produktansvaret?
Nej, de to regelsæt trækker grænsen forskelligt for SaaS og kildekode.
Organisering
Hvilke produkter skal vi begynde med?
Dem, der tager længst tid: vigtige produkter, produkter med store planlagte ændringer og lange supportperioder.
Hvad med produkter, vi udfaser før 2027?
Solgte versioner er stadig omfattet af indberetningspligten, også efter at salget er stoppet.
Hvem skal eje CRA i virksomheden?
Pligterne bør fordeles på produktchef, release-ansvarlig, support og en, der kan indberette uden for arbejdstid, med stedfortrædere.
Senest gennemgået: november 2026.
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
Skal jeres software gennemgås?
Skriv kort, hvilket produkt det drejer sig om, og hvad der sætter det i gang. Så vender jeg tilbage. Gennemgangen er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.
