Er softwaren et produkt efter forordningen?

Alt arbejde med Cyber Resilience Act begynder med ét spørgsmål pr. produkt: er det her et produkt med digitale elementer, og er det jer, der er fabrikant? Svaret afhænger af, hvordan softwaren når brugeren, hvem der sætter navn på den, hvornår den enkelte version kom på markedet, og om en af de få undtagelser rammer. Artiklerne her gør prøven konkret og viser den begrundelse, der skal stå på skrift, også når konklusionen er, at et produkt falder udenfor.

Prøven og begrundelsen

• Hvad er en CRA-gennemgang af et softwareprodukt, når den hverken er CE-vurdering eller certifikat? Hvad rapporten kan bruges til, og hvad den ikke afgør.
• Leveret til brugeren og kørt hos brugeren: prøven for, om jeres software er et produkt Tre led, prøvet for hvert produkt.
• Software uden betaling, freemium og betaling med data: hvornår er det erhvervsmæssigt? Forretningsmodellen læst, ikke prisskiltet.

Leveranceformen

• Ren SaaS er uden for CRA: de tre veje, tjenesten alligevel kommer ind Klient, app eller et produkt, der kalder tjenesten.
• Fjerndatabehandling: hvilke dele af jeres backend hører med til produktet? Grænsen trukket ved det, klienten taler med.
• Mobilapps: eget produkt eller en del af en andens udstyr? Appens rolle afgør, hvem der dokumenterer.
• I udgiver en udvidelse til en platform, I ikke styrer: hvad kan I selv opfylde? Egen kode skilt fra værtsplatformen.
• Kildekode leveret til kunden: Kommissionen regner den også som et produkt Også når kunden selv kompilerer.
• Appbutikker og markedspladser: hvad forordningen siger om salgskanalens rolle Kanalens rolle og fabrikantens faste pligter.

Komponenter og andres software

• Biblioteker, SDK’er og komponenter solgt særskilt: komponentfabrikantens pligter Det, integratoren skal have fra jer.
• Tredjeparts-SaaS, platform og infrastruktur i produktet: behandlet som komponenter Indkøbte tjenester vurderes som byggesten.
• Tillægsmoduler solgt særskilt: modulets egen klasse og egen procedure Egen licens giver eget produkt.

Hvem er fabrikant?

• Software udviklet til én erhvervskunde: stadig et produkt, og de to krav, der kan aftales fra Skræddersyning, der skal kunne bevises.
• I udvikler, kunden sælger under eget navn: hvem er fabrikant, og hvad skal I levere? Navnet på produktet flytter rollen.
• White label: aftalen med den egentlige producent, når I sælger under eget navn Adgang til dokumentation og rettelser i aftalen.

Versioner og datoer

• Hvornår er softwaren bragt i omsætning? Første udbud af en version afgør datoen Et register over versioner og datoer.
• Versioner fra før 11. december 2027: sporet pr. release, og pligten begrænset til den ændrede del Hver release efterlader en beslutning.
• Designet før 2027, ny version efter: risikovurdering uden redesign og uden historiske testbeviser Gammel kodebase, aktuel vurdering.
• Betaversioner og release candidates: hvad må ud, før kravene er opfyldt? Begrænset periode og synlig mærkning.
• Udgaver, varianter og produktfamilier: hvornår er det ét produkt, og hvad kan genbruges? Hvornår vurdering og erklæring kan deles.
• Kravet kan ikke opfyldes fuldt: ældre protokoller, interoperabilitet og kompenserende foranstaltninger Begrænsningen skrevet ned og kompenseret.

Undtagelser og andre regelsæt

• Software, der selv er medicinsk udstyr, er undtaget: hvad med softwaren omkring udstyret? Undtagelsen og dens grænse.
• Software til forsvar og national sikkerhed: undtagelsen gælder kun det, der udelukkende er udviklet til formålet Civil anvendelse bringer softwaren ind.
• AI-funktioner i softwaren: CRA og AI-forordningen i samme produkt Én opfyldelse, der kan tælle i begge.
• CRA og dataforordningen: pligten til at dele produktdata skal med i risikovurderingen Delingen er en angrebsflade som andre.

Sådan kommer I i gang

Skriv alle jeres produkter, moduler, apps og biblioteker op på én liste, også dem, der kun findes hos en enkelt kunde. Notér for hvert, hvordan det leveres, hvem der står som producent, og hvornår den første version kom på markedet i EU. Tag derefter prøven fra leveret og kørt hos brugeren linje for linje, og skriv svaret og grunden i samme række. Listen bliver grundlaget for resten af CRA-arbejdet, og den er det første, en myndighed eller en kunde spørger efter. Den almene metode til en audit af organisationen, fx efter NIS2, står på sitet om sikkerhedsaudit.

Hvad det kræver, og hvad det koster at lade være

Afgrænsningen kræver en produktchef, der kender salgskanalerne, en udvikler, der ved, hvor koden faktisk kører, og et par dages arbejde for et typisk produktkatalog. Springes den over, opdager softwarehuset først sent, at en app, en klient eller et bibliotek skulle have haft risikovurdering, komponentliste og supportperiode, og så er der ikke tid til at bygge det ind i udviklingen.

Det skal I lade være med

• At antage, at alt i skyen er uden for forordningen · klienten og fjerndatabehandlingen kan trække det ind.
• At afgøre spørgsmålet én gang for hele firmaet · prøven tages pr. produkt og pr. udgave.
• At lade et nej stå uden begrundelse · fravalget skal kunne forklares bagefter.

Det skal auditten kunne vise

• ☐ En produktliste med leveranceform, fabrikantrolle og dato for første udbud.
• ☐ En skriftlig begrundelse for hvert produkt, der er vurderet omfattet eller ikke omfattet.
• ☐ Hvilke undtagelser der er påberåbt, og hvad de bygger på.
• ☐ Hvem der ajourfører listen, når et nyt produkt eller en ny salgskanal kommer til.

Senest gennemgået: november 2026.

Næste skridt

• Leveret til brugeren og kørt hos brugeren
• Hvad er en CRA-gennemgang af et softwareprodukt?

Læs også: Open source · Risikovurdering og udviklingsproces

→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT