En browserudvidelse eller et plugin, som I udgiver i erhvervsøjemed, er efter Cyber Resilience Act et produkt med digitale elementer, og I er dets fabrikant. Platformen, udvidelsen kører i, er uden for jeres kontrol, så risikovurderingen skal vise, hvad udvidelsen selv klarer, og hvordan platformen behandles som en ekstern afhængighed.
Ingen kilde fordeler kravene i bilag I mellem en udvidelse og dens platform. Det, der følger, er derfor for en stor del vores tolkning, og den er markeret.
Udvidelsen er et produkt
Kommissionens vejledning C(2026) 5252, punkt 20, nævner udtrykkeligt browserudvidelsen. Software, der leveres og kører hos brugeren, opfylder kriterierne for et produkt med digitale elementer. Vejledningen binder ingen, men den viser, hvordan Kommissionen forstår forordning (EU) 2024/2847 på dette punkt.
Er udvidelsen bragt i omsætning som led i erhvervsvirksomhed, gælder fabrikantens pligter i artikel 13 fra 11. december 2027. Udgiver I udvidelsen uden betaling, afhænger svaret af forretningsmodellen. Efter betragtning 15 kan det tale for erhvervsvirksomhed, hvis I tjener penge via andre tjenester, eller hvis brugeren skal afgive personoplysninger, der bruges til mere end sikkerhed.
Hvad forordningen siger om omgivelserne
Efter vejledningens punkt 168 og 172 skal risikovurderingen også se på trusler udefra, herunder fra det, produktet hviler på. Fabrikanten forventes ikke at have magt over omgivelserne. Forventningen er, at produktet selv er bygget til at modstå dem, og at brugerne får at vide, hvad der skal til for at installere og bruge det sikkert.
For en udvidelse er platformen det oplagte eksempel på et sådant ydre miljø. Den bestemmer, hvilke rettigheder udvidelsen kan få, hvordan den opdateres, og hvordan den isoleres fra andre udvidelser.
Kommissionens tjenestegrenes FAQ (4.1.4, vejledende) tilføjer, at fabrikanter af komponenter, som mange andre bruger, bør overveje, om integration indgår i formål og forudsigelig anvendelse, og oplyse brugerne om forudsætningerne for sikker installation og brug.
En mulig fordeling
Den følgende fordeling er vores forslag til, hvordan risikovurderingen kan ordnes. Den bygger ikke på en kilde, der deler kravene op.
- Rettigheder og angrebsflade · Typisk i udvidelsen selv: At bede om færrest mulige rettigheder og grænseflader · Typisk afhængigt af platformen: Hvordan rettighederne håndhæves
- Beskyttelse af data · Typisk i udvidelsen selv: Kryptering og opbevaring af egne data · Typisk afhængigt af platformen: Isolationen mellem udvidelser
- Kendte sårbarheder ved frigivelse · Typisk i udvidelsen selv: Egen kode og egne komponenter · Typisk afhængigt af platformen: Sårbarheder i platformens kerne
- Distribution af opdateringer · Typisk i udvidelsen selv: Hvornår og hvordan rettelser udgives · Typisk afhængigt af platformen: Platformens kanal og signering
- Sårbarhedshåndtering · Typisk i udvidelsen selv: Hele processen efter bilag I, del II · Typisk afhængigt af platformen: Intet
Den sidste linje er vigtig. Del II af bilag I om håndtering af sårbarheder gælder hele supportperioden uden undtagelse. Ingen platform tager den del af jeres ansvar.
Når et krav ikke kan opfyldes i udvidelsen
Artikel 13, stk. 4, er den regel, der bærer dokumentationen. Er et væsentligt krav ikke relevant for produktet, skal fabrikanten medtage en klar begrundelse i den tekniske dokumentation. Egenskabskravene i del I, nr. 2, af bilag I hviler på risikovurderingen og anvendes, hvor de er relevante.
Kan udvidelsen ikke selv opfylde et krav, fordi platformen bestemmer det, er det efter vores læsning den begrundelse, der skal stå. Begrundelsen bør sige, hvad platformen gør, hvad udvidelsen gør for at afbøde den rest, der er tilbage, og hvad brugeren skal vide. Hvornår en sådan begrundelse holder, står i artiklen om “ikke relevant”.
Et tænkt eksempel
Et softwarehus udgiver en udvidelse, der henter kundens ordrer fra et webshop-system og viser dem i browseren. Udvidelsen beder om adgang til alle websteder, fordi det var nemmest under udviklingen. I risikovurderingen bliver det et fund. Adgangen kan begrænses til de to domæner, udvidelsen faktisk taler med, og det kan udvidelsen selv gøre. Hvordan browseren håndhæver begrænsningen, kan softwarehuset derimod ikke ændre. Det beskrives som en afhængighed, og brugeroplysningerne fortæller, hvilke rettigheder udvidelsen beder om og hvorfor. Eksemplet er tænkt og viser kun, hvordan fordelingen kan se ud på papir.
Det, I ikke kan bygge på
Ingen læst kilde siger noget om platformens egne pligter over for udgiverne af udvidelser. I kan altså ikke henvise til en regel om, at platformen skal hjælpe jer. Det, I kan beskrive, er de sikkerhedsfunktioner, platformen faktisk har, og hvordan udvidelsen bruger dem.
Ændrer platformen sine regler, fx for rettigheder eller opdateringer, bør risikovurderingen tages frem på ny. Vurderingen skal holdes ajour i supportperioden i det omfang, det er relevant (artikel 13, stk. 3).
Hvad det kræver, og hvad det koster at lade være
Det kræver, at udviklerne kan beskrive, præcis hvilke rettigheder og grænseflader udvidelsen bruger, og hvorfor. Det kræver også, at nogen holder øje med platformens ændringer.
Uden den beskrivelse ender risikovurderingen med at sige, at platformen klarer sikkerheden. Den forklaring holder ikke, når kravene i bilag I, del II, under alle omstændigheder ligger hos jer.
Det skal I lade være med
- At skrive, at platformen dækker et krav, uden at sige hvordan · begrundelsen efter artikel 13, stk. 4, skal være klar.
- At bede om bredere rettigheder end nødvendigt · det øger den angrebsflade, I selv svarer for.
- At regne sårbarhedshåndteringen som platformens opgave · den ligger hos fabrikanten af udvidelsen.
Det skal auditten kunne vise
- ☐ En liste over de rettigheder og grænseflader, udvidelsen bruger, med begrundelse.
- ☐ En risikovurdering, der beskriver platformen som ekstern afhængighed.
- ☐ Begrundelser efter artikel 13, stk. 4, for krav, udvidelsen ikke selv kan opfylde.
- ☐ Oplysninger til brugeren om forudsætningerne for sikker brug.
Kilder
- Forordning (EU) 2024/2847, dansk tekst, artikel 13, stk. 3 og 4, og bilag I, læst 13. november 2026 i Publikationskontorets kopi.
- Kommissionens vejledning C(2026) 5252, punkt 20, 168 og 172, ikke bindende, læst 13. november 2026.
- Kommissionens tjenestegrenes FAQ om CRA, version 1.4, FAQ 4.1.4, vejledende, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Beskriv udvidelsens rettigheder og grænseflader, og marker for hvert krav i bilag I, hvem der bærer det.
Læs også: Biblioteker, SDK’er og komponenter solgt særskilt · “Ikke relevant”: begrundelser, der holder
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
