Når et softwarehus bygger komponenter fra andre ind i sit produkt, skal det fra 11. december 2027 kunne vise, at det har undersøgt dem med passende omhu, så de ikke bringer produktets cybersikkerhed i fare. Det følger af artikel 13, stk. 5, og gælder også for open source, der er stillet til rådighed uden betaling og uden for en kommerciel aktivitet.
Niveauet skal stå i forhold til komponentens art og risiko. En lille hjælpefunktion kræver mindre end et kryptografisk bibliotek. Artiklen viser, hvad en forholdsmæssig kontrol af tredjepartskomponenter kan bestå af, og hvad en gennemgang typisk beder om at se.
Kravet, omskrevet
Artikel 13, stk. 5, siger med vores ord, at fabrikanten ved integrering af komponenter fra tredjeparter skal undersøge dem med passende omhu og sikre, at de ikke bringer produktets cybersikkerhed i fare. Formålet er at opfylde stk. 1, altså at produktet er designet, udviklet og produceret efter kravene i bilag I, del I. Kravet gælder også komponenter, der er open source stillet til rådighed uden betaling og uden for en kommerciel aktivitet. Gengivelsen er en omskrivning og ikke et citat af stykket.
Kommissionens FAQ siger, at niveauet afhænger af komponentens art og risiko, og at produktets risikovurdering bestemmer det.
Kommissionens liste over handlinger
FAQ’en gengiver en række mulige handlinger, som stammer fra betragtning 34. Fabrikanten kan:
- kontrollere, om komponenten allerede er CE-mærket,
- kontrollere, at komponenten får regelmæssige sikkerhedsopdateringer, for eksempel ved at se på historikken,
- slå komponentens sårbarheder op i den europæiske sårbarhedsdatabase eller andre offentlige databaser og designe produktet, så de ikke bringer det i fare,
- lave supplerende sikkerhedstest. FAQ’en nævner fuzz-test og penetrationstest som eksempler.
FAQ’en nævner flere eksempler: analyse af softwaresammensætningen, sandboxing eller isolering af meget kritiske komponenter, gennemgang af komponentens egen softwarekomponentliste, når den findes, kontrol af komponentens supportperiode, kontrol af, at komponentens tilsigtede formål passer til den måde, den bruges på, og vurdering af komponentproducentens sikkerhedsniveau.
Listen er ikke en tjekliste, hvor alt skal krydses af. Det er et katalog, hvorfra fabrikanten vælger det, der passer til risikoen. Hvilke handlinger der er valgt, og hvorfor de andre er fravalgt, bør stå i dokumentationen, så valget kan efterprøves. Det sidste er vores anbefaling og ikke en gengivelse af kilden.
Forholdsmæssighed i praksis
Kommissionens vejledning beskriver tankegangen. Fabrikanten skal ud fra risikovurderingen fastlægge, hvad produktet kræver af komponenten, for eksempel kryptografi, en opdateringsmekanisme eller sikker kommunikation, og kontrollere det risikobaseret. Beviset kan være dokumentation fra komponentproducenten, for eksempel tekniske specifikationer, sikkerhedsdokumentation eller dokumentation for overensstemmelse, og, hvor det er passende, egne test.
Vejledningen tilføjer, at komponenter fra tredjepart indgår i risikovurderingen, men behandles som leverede komponenter, hvis egenskaber kontrolleres ved integrationen.
En forholdsmæssig opdeling kunne se sådan ud. Den er et tænkt eksempel og ikke en model fra kilderne.
- (Lille hjælpebibliotek uden netværk eller brugerdata) · (Opslag i offentlige databaser, kontrol af vedligehold)
- (Bibliotek, der fortolker data udefra) · (Som ovenfor, plus analyse af sammensætning og evt. fuzz-test)
- (Kryptografi eller login) · (Som ovenfor, plus krav til komponentproducentens dokumentation og egne test)
CE-mærket er ikke et krav
FAQ’en er tydelig om, at komponenter uden CE-mærke må integreres. Det gælder open source uden for forordningen, komponenter bragt i omsætning før forordningen gælder, og komponenter, der aldrig er bragt i omsætning. Fabrikanten skal ikke bringe dem i overensstemmelse med bilag I, del I, før de integreres. Er komponenten CE-mærket, kan det forenkle visse pligter, fordi fabrikanten kan støtte sig til komponentens EU-overensstemmelseserklæring og dokumentation.
Lige efter overgangsperioden vil CE-mærket ofte ikke kunne kontrolleres, fordi få komponenter har det. FAQ’en henviser til betragtning 35, der siger, at fabrikanten da må bruge andre midler.
Open source
Open source uden for forordningen og fra open source-forvaltere må integreres, skriver FAQ’en. Kommissionen kan oprette frivillige programmer for sikkerhedsattestering af open source-komponenter. Vi har ikke set sådanne programmer pr. november 2026, så det er en mulighed og ikke noget, der kan bruges i dag.
Det, gennemgangen beder om at se
I praksis vælger en gennemgang ofte et antal komponenter fra komponentlisten, fra både den lette og den tunge ende, og beder om beviset for hver. Hvorfor blev komponenten valgt? Hvad krævede produktet af den? Hvilke af handlingerne i Kommissionens katalog blev brugt, og hvorfor var det nok? Hvornår blev kontrollen gentaget?
Svarene holdes op mod risikovurderingen. Et kryptografisk bibliotek, der kun er slået op i en database, er et fund. Et lille hjælpebibliotek med samme kontrol er det typisk ikke.
Hvad det kræver, og hvad det koster at lade være
Det kræver en regel for, hvordan komponenter godkendes, en inddeling efter risiko og en registrering af den kontrol, der er udført for hver komponent.
Uden det kan I ikke vise, at kravet i artikel 13, stk. 5, er opfyldt, og I opdager først en dårligt vedligeholdt komponent, når den har en sårbarhed, ingen retter.
Det skal I lade være med
- At kræve CE-mærke af alle komponenter · forordningen kræver det ikke, og få har det endnu.
- At give alle komponenter samme kontrol · niveauet skal følge risikoen.
- At lade valget ligge hos den enkelte udvikler uden spor · beviset skal kunne findes.
Det skal auditten kunne vise
- ☐ En regel for godkendelse af tredjepartskomponenter, med niveauer efter risiko.
- ☐ For udvalgte komponenter: hvad produktet kræver af dem, og hvilke kontroller der er udført.
- ☐ Kontrol af vedligehold og supportperiode for kritiske komponenter.
- ☐ Kobling mellem kontrollen og risikovurderingen.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 1 og 5, og betragtning 34-35, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 170-172, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.4.1-4.4.4, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Vælg de tre mest kritiske komponenter i jeres produkt, og skriv ned, hvilken kontrol I lavede, da de blev valgt.
Læs også: Komponentens support slutter · Sårbarhed i en andens komponent
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
