Et softwareprodukt må fra 11. december 2027 kun gøres tilgængeligt på markedet uden kendte sårbarheder, der kan udnyttes. Kravet gælder øjeblikket for frigivelsen, og I skal kunne vise, hvad I vidste den dag, og hvordan I vurderede det.
Forordning (EU) 2024/2847 har kravet som litra a under bilag I, del I, nr. 2. Det bygger på risikovurderingen og gælder, hvor det er relevant. Kravet kan let læses som et krav om fejlfri software. Kommissionens FAQ afviser den læsning, som det fremgår nedenfor.
Tre ord, forordningen selv definerer
Artikel 3 giver tre definitioner, som afgør, hvad kravet rammer. En sårbarhed er en svaghed, modtagelighed eller fejl ved et produkt, som en cybertrussel kan udnytte (nr. 40). En sårbarhed, der kan udnyttes, er en, som en modstander potentielt kan udnytte effektivt under praktiske operationelle forhold (nr. 41). En aktivt udnyttet sårbarhed kræver pålidelig dokumentation for, at nogen har udnyttet den uden systemejerens tilladelse (nr. 42).
Litra a handler om nr. 41. Det afgørende led er de praktiske forhold. En fejl i kode, som produktet aldrig kører, eller som kun kan nås med adgang, ingen angriber realistisk får, er i den forstand en anden sag end en fejl i en åben grænseflade.
Kommissionens FAQ siger det direkte. Forordningen kræver ikke, at et produkt er fri for alle sårbarheder. Om en sårbarhed kan udnyttes, afgøres konkret, og FAQ’en peger på tre forhold: hvor ofte produktet bruger den sårbare kode, hvor meget adgang en angriber skal have i forvejen, og hvilke kompenserende kontroller der allerede virker.
Hvornår er en sårbarhed kendt?
Forordningen siger ikke selv, hvornår en sårbarhed er kendt. Det skriver Kommissionen i sin vejledning fra juli 2026, som ikke er bindende. Vejledningen giver to slags kilder til kendskab.
Den første er offentlig. En sårbarhed regnes for kendt, når den står i relevante offentlige sårbarhedsdatabaser, som den europæiske sårbarhedsdatabase efter NIS2-direktivets artikel 12, stk. 2, eller andre fremtrædende databaser.
Den anden er viden, der ikke er offentlig. Det kan være en melding fra en sikkerhedsforsker under koordineret offentliggørelse, resultater af jeres egne test og analyser, også når I bruger AI-baserede tjenester til dem, eller omtale i pålidelige medier.
Vejledningen tilføjer en nuance, der betyder meget i praksis. At en sårbarhed er meldt eller fundet, betyder ikke af sig selv, at den gælder produktet eller kan udnyttes. Fabrikanten skal undersøge og bekræfte, og der kan gå en begrænset tid fra den første melding til bekræftelsen.
Den sene opdagelse
Dukker en ny sårbarhed op tæt på frigivelsen, er det ifølge vejledningen fabrikantens afgørelse på grundlag af risikovurderingen, om versionen kan gå ud, eller om den skal rettes først. Alvor, udnyttelighed og mulig virkning indgår. Fabrikanten kan også veje risikoen ved at udskyde, for eksempel hvis den nye version retter andre sårbarheder.
Det betyder, at en frigivelse med en kendt sårbarhed kan være forsvarlig. Forudsætningen er, at beslutningen er truffet bevidst, at den er begrundet, og at begrundelsen ligger skriftligt.
Mellem frigivelse og ibrugtagning
Kravet knytter sig til omsætningstidspunktet (artikel 13, stk. 1). Hvad så med sårbarheder, der bliver opdaget, efter at versionen er frigivet, men før brugeren tager den i brug? FAQ’en svarer, at fabrikanten ikke forventes at rette dem i distributionskæden. Fabrikanten skal i stedet håndtere og afhjælpe dem straks ud fra risikoen efter bilag I, del II, nr. 2, eventuelt med en opdatering, når produktet tages i brug.
For software, der hentes direkte, er den kæde ofte kort. Vores læsning er derfor, at spørgsmålet især betyder noget for software, der ligger på lager hos en distributør eller er forudinstalleret. Det er en tolkning.
Beviset for status ved frigivelse
Forordningen siger ikke, hvordan I dokumenterer status. Den kræver, at sårbarheder og komponenter identificeres og dokumenteres (bilag I, del II, nr. 1), og at risikovurderingen tager stilling til hvert krav i del I.
En almindelig fremgangsmåde er at køre komponentlisten for den konkrete version mod offentlige databaser på frigivelsesdatoen og gemme resultatet med dato. Hvert fund får en dateret vurdering. Kan sårbarheden udnyttes under praktiske forhold? Er den rettet? Er den vurderet uden betydning, og hvorfor? Den samme vurdering gælder fund fra egne test og meldinger udefra, der endnu ikke er offentlige.
Det er praksis, og ingen standard foreskriver det. Pr. november 2026 har vi ikke set harmoniserede standarder til forordningen offentliggjort i EU-Tidende, så der findes heller ingen formodning at læne sig op ad.
Hvad det kræver, og hvad det koster at lade være
Det kræver en fast handling i frigivelsesforløbet, hvor nogen samler de kendte sårbarheder for netop denne version og træffer en dokumenteret beslutning. Det kræver også, at komponentlisten er så komplet, at scanningen giver mening.
Uden den handling kan I ikke vise, hvad der var kendt på frigivelsesdagen. Spørger en markedsovervågningsmyndighed senere, står I med en version, som måske var i orden, men som ikke kan bevises at have været det.
Det skal I lade være med
- At love kunder fejlfri software · forordningen kræver det ikke, og løftet kan ikke holdes.
- At regne en melding som bekræftet med det samme · vurderingen af, om den gælder jer, hører med.
- At udskyde uden begrundelse · en udskudt rettelse kræver en skriftlig risikoafvejning.
- At overskrive scanningen ved næste build · resultatet for den frigivne version skal kunne findes igen.
Det skal auditten kunne vise
- ☐ En dateret oversigt over kendte sårbarheder i den frigivne version, også fra ikke-offentlige kilder.
- ☐ En vurdering af udnyttelighed for hvert fund med de kriterier, der er brugt.
- ☐ En begrundet beslutning, hvis versionen blev frigivet med en kendt sårbarhed.
- ☐ Spor af, hvordan fund opdaget efter frigivelsen blev håndteret efter bilag I, del II, nr. 2.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 3, nr. 40-42, artikel 13, stk. 1, bilag I, del I, nr. 2, litra a, og del II, nr. 1-2, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 232-237, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.2.2 og 4.2.3, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find den seneste frigivne version, og se, om I kan vise, hvilke sårbarheder der var kendt på dagen.
- Bilag I, del I: softwarens egenskaber krav for krav
- Ny sårbarhed kort før release: frigiv eller udskyd
Læs også: Softwarekomponentlisten (SBOM) efter CRA · “Ikke berørt”: den dokumenterede vurdering
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
