Ufærdig software må efter artikel 4, stk. 3, i Cyber Resilience Act gøres tilgængelig, selv om den ikke overholder forordningen, når tre betingelser er opfyldt. Den skal være ufærdig, den må kun være ude i den begrænsede tid, afprøvningen kræver, og den skal bære et synligt skilt om, at den ikke overholder forordningen og kun er til afprøvning.
Bestemmelsen er skrevet til alfa- og betaversioner og release candidates. Den giver plads til feedback fra brugere, men den er ingen permanent udvej, og en testudgave, der bliver stående hos kunder, kan efter vores vurdering falde uden for den.
Ordlyden
Artikel 4, stk. 3, i forordning (EU) 2024/2847 lyder sådan.
“Medlemsstaterne må ikke forhindre tilgængeliggørelse på markedet af ufærdig software, der ikke overholder denne forordning, såfremt softwaren kun gøres tilgængelig i et begrænset tidsrum, der er nødvendigt til afprøvningsformål, og med et synligt skilt, hvoraf det tydeligt fremgår, at den ikke overholder denne forordning og ikke vil være tilgængelig på markedet til andre formål end afprøvning.”
Stk. 4 tilføjer, at stk. 3 ikke gælder sikkerhedskomponenter efter anden EU-harmoniseringslovgivning. For de fleste rene softwareprodukter er det uden betydning, men det er værd at kontrollere, hvis produktet indgår i et andet reguleret produkt.
Hvad betragtning 37 lægger til
Betragtning 37 nævner udtrykkeligt alfaversioner, betaversioner og versioner, der er klar til frigivelse. Undtagelsen gælder kun i den tid, der er nødvendig for at afprøve og samle feedback. Betragtningen beskriver også, hvad fabrikanterne bør gøre i den periode.
- Først frigive efter en risikovurdering · En kort vurdering af testudgaven, før den sendes ud
- Opfylde egenskabskravene i videst muligt omfang · De krav i bilag I, del I, der allerede er løst, fjernes ikke for testens skyld
- Gennemføre kravene til sårbarhedshåndtering i videst muligt omfang · Fund i testudgaven tages ind i den normale proces
- Ikke tvinge brugerne til at opgradere til testversioner · Testudgaven er et tilvalg
Ordet er bør, og højre kolonne er vores eksempler. Kommissionens tjenestegrenes FAQ (1.6, vejledende) gentager betragtningen.
Det, der slet ikke er bragt i omsætning
Kommissionens vejledning C(2026) 5252, som er vejledende, siger i punkt 23 og fodnote 8, at kode, der stadig er under udvikling og kun deles for at blive testet eller gennemset, ikke er bragt i omsætning. En build, der deles med en enkelt samarbejdspartner til kodegennemgang, falder derfor uden for forordningen, før spørgsmålet om artikel 4, stk. 3, overhovedet opstår.
Artikel 4, stk. 3, bliver relevant, når testudgaven gøres tilgængelig for en bredere kreds af brugere, fx en åben betakanal.
Hvor længe er et begrænset tidsrum
Ingen kilde fastsætter en frist. Forordningen siger kun, at tidsrummet skal være begrænset og nødvendigt til afprøvning. Det er derfor praksis at skrive testperiodens forventede længde og formål ned, når testen starter, så det senere kan vises, at perioden var afgrænset.
Den glemte testudgave
Tag et tænkt tilfælde, hvor en kunde fik en betaversion for at prøve en ny funktion og aldrig skiftede til den færdige. Efter vores tolkning opfylder testudgaven så ikke længere betingelserne i artikel 4, stk. 3, fordi den ikke længere er ude af hensyn til afprøvning. Tolkningen bygger på ordlyden og betragtning 37. Ingen kilde siger det direkte.
En gennemgang kan derfor spørge til, hvor testudgaver ligger, og hvornår de udløber. Det er praksis at give testudgaver en udløbsdato eller en mekanisme, der flytter brugerne til den færdige version.
Sårbarheder i en testudgave
En testudgave er også software hos rigtige brugere, og den kan rumme fejl, der bliver udnyttet. Betragtning 37 forventer, at kravene til sårbarhedshåndtering gennemføres i videst muligt omfang i testperioden. I praksis betyder det, at en sårbarhed, der findes i betaen, registreres og vurderes i samme proces som fund i de færdige versioner, og at rettelsen også når testbrugerne. Hvordan pligten til at indberette efter artikel 14 forholder sig til en testudgave, som ikke overholder forordningen, behandler de læste kilder ikke, og spørgsmålet bør tages med forbehold.
Mærkningen
Skiltet skal være synligt og tydeligt sige to ting: at softwaren ikke overholder forordningen, og at den kun er til afprøvning. Forordningen siger ikke, hvor skiltet skal sidde i software. Det er naturligt at vise det ved installation, i programmet og på downloadsiden, men placeringen er et valg, I bør kunne begrunde.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at testudgaver har et formål, en periode og en mærkning, og at nogen holder styr på, hvem der har dem. Kravene gælder fra 11. december 2027.
Uden styr på testudgaverne kan en betaversion hos en kunde ende som et produkt, der hverken er færdigt eller omfattet af undtagelsen. Det er en situation, der er svær at forklare.
Det skal I lade være med
- At bruge betastatus til at udskyde kravene på en version i almindelig drift · undtagelsen gælder kun afprøvning.
- At sende testudgaver ud uden synlig mærkning · skiltet er en betingelse.
- At tvinge brugere over på en testversion · betragtning 37 siger, at det bør I ikke.
Det skal auditten kunne vise
- ☐ En liste over aktuelle testudgaver med formål og forventet periode.
- ☐ Mærkningen, som den vises for brugeren.
- ☐ Hvem der har testudgaverne, og hvordan de flyttes til den færdige version.
- ☐ Hvordan fund i testudgaverne tages ind i sårbarhedshåndteringen.
Kilder
- Forordning (EU) 2024/2847, dansk tekst, artikel 4, stk. 3 og 4, og betragtning 37, læst 13. november 2026 i Publikationskontorets kopi.
- Kommissionens vejledning C(2026) 5252, punkt 23 og fodnote 8, ikke bindende, læst 13. november 2026.
- Kommissionens tjenestegrenes FAQ om CRA, version 1.4, FAQ 1.6, vejledende, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find de testudgaver, der er ude hos brugere i dag, og giv hver et formål og en slutdato.
Læs også: Ny sårbarhed kort før release · Kildekode leveret til kunden
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
