Et bibliotek, et SDK eller en anden softwarekomponent, som I bringer i omsætning for sig, er selv et produkt efter Cyber Resilience Act, og I er dets fabrikant. Pligterne er tilpasset, at andre bygger videre, og tre ting fylder mest: integrationen i risikovurderingen, en sikker standardkonfiguration for det, I leverer, og oplysninger til den, der integrerer.
Pligterne får virkning 11. december 2027, og tiden frem til da kan bruges på at få dokumentationen til at passe til den måde, komponenten faktisk bliver brugt på.
Komponenten er selv et produkt
Artikel 3, nr. 1, i forordning (EU) 2024/2847 lader begrebet produkt med digitale elementer omfatte software- og hardwarekomponenter, der bringes i omsætning separat. Nr. 6 definerer en komponent som software eller hardware, der er beregnet til integration i et elektronisk informationssystem.
Det betyder, at et kommercielt bibliotek eller SDK har sin egen risikovurdering, sin egen tekniske dokumentation, sin egen overensstemmelsesvurdering og sin egen EU-overensstemmelseserklæring. Kunden, der bygger det ind, er fabrikant af sit eget produkt og har sine egne pligter ved siden af.
Ét forhold er værd at kende. Efter artikel 7, stk. 1, bliver kundens produkt ikke vigtigt, blot fordi der er bygget et vigtigt produkt ind i det. Komponentens klasse smitter altså ikke af på kundens produkt.
Integrationen hører med i risikovurderingen
Kommissionens tjenestegrenes FAQ (4.1.4, vejledende) anbefaler, at komponentfabrikanter overvejer integration som en del af det tilsigtede formål og den forudsigelige anvendelse. For et bibliotek er integrationen jo selve formålet.
I praksis betyder det, at risikovurderingen bør beskrive de typiske måder, komponenten bliver brugt på, og hvad der går galt, hvis den bruges forkert. Et kryptobibliotek bliver kaldt fra mange slags programmer. Et SDK til betaling bliver bygget ind i apps med meget forskellig sikkerhed. Scenarierne er ikke fastlagt i nogen kilde, så hvor mange I medtager, er et skøn, der bør begrundes.
Sikker standardkonfiguration for det, I leverer
Bilag I, del I, kræver, at produkter leveres med en sikker standardkonfiguration. FAQ 4.2.4 forklarer, hvordan kravet virker for en komponent. Det gælder komponenten, som den bringes i omsætning. Komponentfabrikanten svarer ikke for, hvordan integratoren senere ændrer konfigurationen.
FAQ’en nævner selv et kryptobibliotek som eksempel, hvor forældede algoritmer er slået fra som standard, og certifikatvalidering er slået til. Vælger kunden at slå en forældet algoritme til, er det kundens beslutning og kundens risiko i kundens eget produkt.
Automatiske opdateringer gælder ikke på samme måde
Ifølge betragtning 56 falder kravene om automatiske opdateringer i bilag I bort for produkter, hvis hovedformål er at indgå som en komponent i en andens produkt. Det er logisk. Et bibliotek kan ikke opdatere sig selv inde i en andens app.
Sårbarhedshåndteringen består efter vores læsning. Kravene i bilag I, del II, om at håndtere sårbarheder og stille sikkerhedsopdateringer til rådighed gælder også en komponent. Forskellen ligger i, hvordan rettelsen når frem, og her er det integratoren, der skal bygge den ind.
Oplysninger til integratoren
Bilag II, nr. 8, litra f, kræver, at brugeroplysningerne for produkter beregnet til integration indeholder de oplysninger, integratoren har brug for for at opfylde bilag I og dokumentationskravene i bilag VII. Det er den pligt, der adskiller en komponent mest fra et færdigt program.
Hvad integratoren typisk har brug for, kan ordnes i en liste. Den er vores forslag og ikke en udtømmende gengivelse af loven.
- Hvilken konfiguration der er sikker, og hvad en ændring betyder · Egen risikovurdering og standardkonfiguration
- Komponentens egne afhængigheder · Egen softwarekomponentliste
- Hvordan sikkerhedsopdateringer udgives og meldes · Egen sårbarhedshåndtering
- Supportperiode for komponenten · Egen supportperiode
- Kontaktpunkt for sårbarhedsrapporter · Melding af fund opstrøms
Erhvervskunder, der kontrollerer jer som leverandør, vil ofte bede om de samme oplysninger. Hvordan kunden griber den kontrol an, er beskrevet fra kundens side på leverandøraudit af IT-leverandører.
Hvornår en komponent ikke er bragt i omsætning
Ikke alle komponenter er produkter. Bruger I et bibliotek alene inde i jeres egne produkter, er det en del af dem og ikke et særskilt produkt. Udgiver I det som open source uden at tjene på det, gælder reglerne for open source, som har deres egen gruppe af artikler. Det afgørende er, om komponenten bliver gjort tilgængelig for andre som led i erhvervsvirksomhed.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at nogen skriver integratorens dokumentation med samme omhu som koden, og at standardkonfigurationen bliver valgt bevidst og begrundet. Det kræver også en proces for at melde sikkerhedsopdateringer til kunder, I måske ikke kender.
Uden oplysningerne kan integratoren ikke opfylde sine egne krav, og spørgsmålene ender hos jer, typisk sent og fra mange kunder på én gang.
Det skal I lade være med
- At levere med usikre standardindstillinger for nemheds skyld · kravet gælder komponenten, som den leveres.
- At gå ud fra, at integratoren selv finder ud af det · bilag II, nr. 8, litra f, lægger oplysningerne hos jer.
- At regne komponenten for undtaget fra sårbarhedshåndtering · kun kravet om automatiske opdateringer falder bort.
Det skal auditten kunne vise
- ☐ En risikovurdering, der beskriver de typiske integrationsscenarier.
- ☐ En dokumenteret og begrundet standardkonfiguration.
- ☐ Brugeroplysninger til integratoren efter bilag II, nr. 8, litra f.
- ☐ En kanal, hvor kunder får besked om sikkerhedsopdateringer.
Kilder
- Forordning (EU) 2024/2847, dansk tekst, artikel 3, nr. 1 og 6, artikel 7, stk. 1, betragtning 56, bilag I og bilag II, nr. 8, læst 13. november 2026 i Publikationskontorets kopi.
- Kommissionens tjenestegrenes FAQ om CRA, version 1.4, FAQ 4.1.4 og 4.2.4, vejledende, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv de oplysninger ned, en integrator har brug for, og sammenhold dem med bilag II.
Læs også: Udgiver I en udvidelse til en platform? · Tillægsmoduler solgt særskilt
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
