...
Alle artikler
Her står hver eneste artikel på sitet, ordnet i de tretten emner, temasiderne også bruger. Rækkefølgen følger arbejdet med et softwareprodukt: først spørgsmålet om, hvorvidt det er omfattet, så risikovurderingen og kravene til selve produktet, derefter komponenter, sårbarheder og indberetning og til sidst dokumentation, handelsled, tilsyn og ansvar. Inden for hvert emne kommer de grundlæggende artikler før de mere specielle.
Er softwaren et produkt efter forordningen?
- Hvad er en CRA-gennemgang af et softwareprodukt, når den hverken er CE-vurdering eller certifikat?
- Leveret til brugeren og kørt hos brugeren: prøven for, om jeres software er et produkt
- Ren SaaS er uden for CRA: de tre veje, tjenesten alligevel kommer ind
- Mobilapps: eget produkt eller en del af en andens udstyr?
- I udgiver en udvidelse til en platform, I ikke styrer: hvad kan I selv opfylde?
- Biblioteker, SDK’er og komponenter solgt særskilt: komponentfabrikantens pligter
- Kildekode leveret til kunden: Kommissionen regner den også som et produkt
- Fjerndatabehandling: hvilke dele af jeres backend hører med til produktet?
- Tredjeparts-SaaS, platform og infrastruktur i produktet: behandlet som komponenter
- Software udviklet til én erhvervskunde: stadig et produkt, og de to krav, der kan aftales fra
- I udvikler, kunden sælger under eget navn: hvem er fabrikant, og hvad skal I levere?
- White label: aftalen med den egentlige producent, når I sælger under eget navn
- Software uden betaling, freemium og betaling med data: hvornår er det erhvervsmæssigt?
- Udgaver, varianter og produktfamilier: hvornår er det ét produkt, og hvad kan genbruges?
- Hvornår er softwaren bragt i omsætning? Første udbud af en version afgør datoen
- Versioner fra før 11. december 2027: sporet pr. release, og pligten begrænset til den ændrede del
- Betaversioner og release candidates: hvad må ud, før kravene er opfyldt?
- Tillægsmoduler solgt særskilt: modulets egen klasse og egen procedure
- Designet før 2027, ny version efter: risikovurdering uden redesign og uden historiske testbeviser
- Kravet kan ikke opfyldes fuldt: ældre protokoller, interoperabilitet og kompenserende foranstaltninger
- Software, der selv er medicinsk udstyr, er undtaget: hvad med softwaren omkring udstyret?
- Software til forsvar og national sikkerhed: undtagelsen gælder kun det, der udelukkende er udviklet til formålet
- AI-funktioner i softwaren: CRA og AI-forordningen i samme produkt
- CRA og dataforordningen: pligten til at dele produktdata skal med i risikovurderingen
- Appbutikker og markedspladser: hvad forordningen siger om salgskanalens rolle
Open source
- Open source i jeres forretning: fabrikant, forvalter eller ingen af delene?
- Community-udgave og betalt udgave: to produkter og to roller i samme virksomhed
- Betalt support til open source uden licensbetaling: sådan læses tilbud og aftaler
- I udgiver et bibliotek uden at tjene på det og bruger det selv i produktet: forvalter af egen kode
- Forvalterens pligter: cybersikkerhedspolitik, samarbejde med myndigheden og indberetning efter støttens art
- I installerer og tilpasser open source hos kunden: hvornår bliver I fabrikant?
Risikovurdering og udviklingsproces
- Cybersikkerhedsrisikovurderingen for et softwareprodukt: det, gennemgangen kontrollerer
- “Ikke relevant”: begrundelser, der holder, og begrundelser, der ikke gør
- Tilsigtet formål og forudsigelig brug: produktside, dokumentation og integrationsscenarier
- Afhængigheder uden for produktet: risici, softwaren selv skal kunne modstå
- CRA foreskriver ingen metode: hvad måler en gennemgang af udviklingsprocessen så imod?
- Ny sårbarhed kort før release: frigiv eller udskyd, og sporet efter beslutningen
- Hvornår i udviklingsforløbet skal gennemgangen ligge?
- Restrisiko: jeres egen risikovillighed, omkostninger og kommercielle hensyn tæller ikke
- Risikoen kan ikke flyttes til brugeren: forudsigelig fejlanvendelse, og hvad anvisninger må bære
- Risikovurderingen i supportperioden: hvad udløser en ajourføring, og hvordan ses det bagefter?
- Regelmæssige afprøvninger og gennemgange i supportperioden: et program, der følger truslerne
- Ny byggekæde, ny proces eller ændret standard: proceduren efter artikel 13, stk. 14
- Kode skrevet af AI-assistenter: de samme krav i bilag I og det spor, en gennemgang beder om
Bilag I, del I: softwarens egenskaber krav for krav
- Ingen kendte udnyttelige sårbarheder ved frigivelse: hvornår er en sårbarhed “kendt” og “udnyttelig”?
- Sikker standardkonfiguration i software: installation, første opstart og standardkonti
- Automatiske sikkerhedsopdateringer som standard: fravalg, undtagelser, og hvor jeres ansvar slutter
- Adgangskontrol i softwaren: autentificering, roller og melding om uautoriseret adgang
- Fortrolighed: kryptering i hvile og under transport, styresystemets funktioner og skift af algoritme
- Integritet: afviser softwaren ændrede data, kommandoer og konfiguration, og melder den korruption?
- Dataminimering i softwaren: telemetri, fejlrapporter og logfiler
- Tilgængelighed: væsentlige funktioner ved udfald, og softwaren må ikke genere andre
- Begrænsning af angrebsflader: grænseflader, porte og fejlsøgningsfunktioner, ingen bruger
- Når noget går galt inde i softwaren: adskillelse mellem dele, så én fejl ikke giver alt
- Sikkerhedslogning som produktkrav: hvad softwaren skal registrere, og brugerens fravalg
- Sikker sletning og flytning af data: afinstallation, eksport og lukket konto
Softwarekomponentliste (SBOM), afhængigheder og tredjepartskomponenter
- Softwarekomponentlisten (SBOM) efter CRA: det, gennemgangen kontrollerer
- Øverste niveau er lovens minimum: afstanden til det, sårbarhedsovervågningen kræver
- Skal kunderne have komponentlisten? Myndighed, kunder og offentlighed
- Overvågning af komponenter for hver understøttet version: beviset for en løbende pligt
- “Ikke berørt”: den dokumenterede vurdering, når en sårbarhed i en afhængighed ikke rettes
- Valg af open source- og tredjepartskomponenter: det, gennemgangen beder om at se
- Sårbarhed i en andens komponent: meld opstrøms og del rettelsen
- Komponentens support slutter, eller projektet står uden vedligeholder
- Den tyske retningslinje TR-03183-2 som målestok for komponentlisten, indtil der findes standarder
- En komponentliste for hver version: den tyske regel, og hvad forordningen kræver gemt, når der frigives hver uge
Sårbarhedshåndtering, opdateringer og supportperiode
- Håndtere eller rette: gennemgang af rettefrister og sårbarhedsregister
- Politik for koordineret offentliggørelse og det centrale kontaktpunkt: gennemgang af praksis
- Sårbarheden kan ikke rettes: afbødning, lukning af en funktion eller tilbagetrækning af en version
- Når rettelsen er ude: pligten til at offentliggøre oplysninger om sårbarheden, og retten til at vente
- Sikkerhedsopdateringer adskilt fra funktionsopdateringer
- Kun nyeste version understøttes: betingelserne i artikel 13, stk. 10, ved hyppige releases
- Væsentlig ændring: de fire spørgsmål, hver release skal igennem, og hvad et ja betyder
- Skriv de planlagte funktioner ind i risikovurderingen fra start
- I ændrer en andens kommercielle software: ændret produkt eller nyt produkt bygget af komponenter?
- Sikker distribution af opdateringer: beskrivelsen i dokumentationen og kontrollen i klienten
- Uden betaling og uden unødigt ophold: sikkerhedsopdateringer bag supportaftale eller licensnøgle
- Hver sikkerhedsopdatering skal kunne hentes i ti år: opdateringsarkivet
- Supportperioden: begrundelsen i den tekniske dokumentation
- Under fem år: de to tilfælde fra Kommissionen, og beviset for forventet brugstid
- Slutdatoen ved købet og beskeden i programmet, når supporten er slut
- Gamle versioner: salg efter supportens udløb og offentlige arkiver med advarsel
- Softwarehuset indstiller driften: underretning af myndighed og brugere
- Jeres licens- og supportvilkår efter CRA: det, der skal ændres før december 2027
Indberetning efter artikel 14
- Indberetningspligten gælder nu: kan I nå 24 timer, 72 timer og slutrapporten?
- Aktivt udnyttet sårbarhed: hvornår har I “fået kendskab”?
- Alvorlig hændelse: kompromitteret kodelager, byggemiljø eller opdateringsserver
- Den fælles indberetningsplatform: repræsentanter, den danske koordinator og en arbejdsgang, der er prøvet af
- Felterne i varsling, 72-timers meddelelse og slutrapport: de registre, I skal have i forvejen
- Underretning af brugerne efter artikel 14, stk. 8: hvor langt pligten rækker, og hvornår CSIRT’en overtager
- En udnyttet sårbarhed i et bibliotek, mange bruger: en gennemspillet sag om, hvem der indberetter
- Samme hændelse, tre pligter: CRA-indberetning, NIS2-underretning og persondatabrud
- Fundet af egne testere, dusørjægere eller forskere: nuldagssårbarheder uden indberetningspligt
- Produkter fra før 2027, hvor byggemiljøet er væk: I skal kun indberette, men kan I det?
- Frivillig indberetning efter artikel 15: sårbarheder, trusler og nærvedhændelser
- Kan indberetningen holdes tilbage fra andre landes CSIRT’er? CSIRT’ens skøn og jeres tre særlige tilfælde
- Efter indberetningen: hvem får oplysningerne, hvornår kan CSIRT’en gå offentligt ud, og hvad ender i den europæiske sårbarhedsdatabase?
- Platformens vilkår: personlige adgange, ansvaret for repræsentanterne og fem års tavshedspligt
- Ret og opdatér en indgivet indberetning, før slutrapporten låser den
- Hvilken CSIRT er jeres koordinator? Hovedforretningssted i en koncern med udvikling i flere lande
Vigtige softwareklasser og vurdering med tredjepart
- Vigtigt produkt eller ej? Gennemgang af klassificeringen efter væsentligste funktionalitet
- Identitetsstyring, fælles login og flerfaktorsoftware: klasse I
- SIEM eller logværktøj? Kernefunktionen afgør klassen
- Indlejret browser, VPN-bibliotek eller login-komponent i jeres app gør ikke appen til et vigtigt produkt
- Adgangskodeværktøjer, VPN, netstyring, PKI, opstartsprogrammer og virtuelle netværksgrænseflader: de øvrige softwarekategorier i klasse I
- Styresystemer, hypervisorer, containerafviklere, firewalls og indtrængningsdetektion: platforms- og sikkerhedssoftware i klasse I og II
- Klasse I uden harmoniseret standard: hvad gør I, mens standarderne mangler?
- Standarden dækker kernefunktionen: de ekstra funktioner skal I selv dokumentere
- Modul H for softwarehuse med mange produkter: kvalitetssystemets otte elementer, og hvorfor en ISO 9000-akkreditering ikke er nok
- Klar til det bemyndigede organ: forberedelse af typeafprøvning af et softwareprodukt
- Efter attesten: ændringer skal meldes til organet, og sårbarhedshåndteringen bliver kontrolleret
- Findes der et bemyndiget organ til jeres software? Udpegning, uafhængighed og opslaget i NANDO
Dokumentation, erklæring og mærkning
- Den tekniske dokumentation for software efter bilag VII: gennemgang punkt for punkt
- Oplysninger og anvisninger til brugeren efter bilag II, når softwaren ikke har en manual
- EU-overensstemmelseserklæringen for software: indhold, forenklet udgave og ny version
- CE-mærket på software: på erklæringen eller på hjemmesiden, og let at finde
- Modul A for et softwareprodukt: egenkontrollen trin for trin, og hvad en uvildig gennemgang bidrager med
- Mikro- og små softwarehuse: lempelserne, og det, der ikke lempes
- Mens standarderne mangler: hvad kan en gennemgang måle efter, og hvad giver ikke formodning?
- Journalsystemer og sundhedssoftware: to forordninger, én vurderingsprocedure og én erklæring
- Teknisk dokumentation, når softwaren udkommer hver uge: alle versioner, ændringerne og ti års opbevaring
Importør, forhandler og kundernes krav
- Importør af software fra en producent uden for EU: kontrollen, før I sælger
- Forhandler af andres software: distributørens kontrol, og hvad der gælder for produkter fra før 2027
- Importør eller forhandler hører om en sårbarhed: stop salget, underret, dokumentér
- Bemyndiget repræsentant for en softwareproducent uden for EU
- Kunden beder om CRA-dokumentation før december 2027: hvad kan I ærligt sige?
- NIS2-enhed og fabrikant på samme tid: hvorfor et ISO 27001-certifikat ikke dækker produktet, og hvad der måske kan genbruges
- Hvem købte I af, og hvem solgte I til? Sporbarhed i handelsleddet i ti år
Dansk tilsyn og sanktioner
- CRA-tilsyn i Danmark: Styrelsen for Samfundssikkerhed i lovudkastet fra oktober 2026
- Tilsyn hos et softwarehus: hvad markedsovervågningen kan bede om
- Bøder og straf efter CRA: tre niveauer i forordningen og en dansk model i udkastet
- Væsentlig cybersikkerhedsrisiko: fra evaluering til tilbagetrækning af software
- Formelle mangler: CE-mærke, erklæring og dokumentation, som tilsynet kan se udefra
- Produktet overholder kravene, men udgør alligevel en risiko: artikel 57 og de ikke-tekniske faktorer
- Koordinerede kontrolaktioner: når en hel produktkategori bliver set efter på tværs af EU
- Hvad sker der med det, I udleverer? Tavshedspligt, kildekode og aktindsigt
- I sælger software i andre EU-lande: hvem fører tilsyn, og på hvilket sprog skal oplysningerne være?
Produktansvar for software
- Software er et produkt i det nye produktansvarsdirektiv: bevisstillingen for et softwarehus
- SaaS og kildekode: hvor CRA og produktansvaret trækker grænsen forskelligt
- Manglende sikkerhedsopdatering som defekt: supportperioden og produktansvaret
Anledninger og organisering
- Produktporteføljen: rækkefølgen efter forordningens egne kriterier
- Udfasning før 2027: ledelsens beslutning, og hvad der gælder for de solgte versioner
- Hvem ejer CRA i en produktvirksomhed? Produktchef, release-ansvarlig, support og den, der kan indberette om natten
- Køreplan til 11. december 2027: det, et softwarehus skal have klar, og hvornår
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.
