Hvornår er en opdatering en væsentlig ændring?

Spørgsmålet afgør, om et ældre produkt kommer ind under hovedkravene i Cyber Resilience Act. Produkter, der er bragt i omsætning før 11. december 2027, er kun omfattet af de krav, hvis de væsentligt ændres fra den dato. Sikkerhedsopdateringer er generelt ikke væsentlige ændringer, men de kan være det, hvis de ændrer det tilsigtede formål ud over det forudsete eller tilføjer nye eller større risici. Underretningspligten gælder uanset. For et softwarehus, der udgiver hver uge, er svaret derfor en fast del af releaseprocessen, og det er noget, ledelsen skal have besluttet. Konkrete sager hører til hos en advokat.

Hvorfor spørgsmålet betyder noget

Mange softwarehuse har et produkt, der allerede er på markedet. Så længe det ikke væsentligt ændres, gælder hovedkravene ikke for det efter 11. december 2027. Fra det øjeblik en ændring er væsentlig, skal produktet opfylde kravene, med risikovurdering, teknisk dokumentation, overensstemmelsesvurdering og CE-mærke, se overblikket over CRA.

En ændring kan altså udløse et stort dokumentationsarbejde. Det skal være en bevidst beslutning.

Reglerne om underretning, se 24 timer til ENISA, gælder også produkter fra før datoen. Et gammelt produkt står altså ikke helt uden for.

Det, Kommissionen peger på

Vejledningen siger følgende, og den er ikke bindende:

• Sikkerhedsopdateringer er generelt ikke væsentlige ændringer (betragtning 39 og vejledningen nr. 108).
• En opdatering kan alligevel være det, hvis den ændrer det tilsigtede formål ud over det forudsete, eller hvis den tilføjer nye eller større risici. Vejledningen nævner nye eksterne grænseflader og ændrede datastrømme (nr. 109).
• Nye versioner uden væsentlig ændring ændrer ikke datoen for omsætning (nr. 15).

Grænsen følger altså formål og risiko.

Eksempler til vurderingen

Eksemplerne her er tænkte og er vores læsning af vejledningen. De er et sted at starte, og hvert produkt skal vurderes for sig.

Peger typisk væk fra væsentlig ændring:

• En rettelse af en sårbarhed i et login-modul, uden ny funktion.
• Opdatering af et bibliotek til en nyere version.
• Fejlrettelser og små forbedringer af brugerfladen.
• Bedre ydeevne uden nye datastrømme.

Kræver en nærmere vurdering:

• Et nyt offentligt API, som kunder eller andre systemer kan bruge. Det er en ny ekstern grænseflade.
• En ny integration, der sender data til en tredjepart. Det ændrer datastrømmene.
• En funktion, der gør, at produktet nu styrer noget, det før alene viste.
• En tilføjet AI-funktion, der handler på brugerens vegne eller læser kundens data.
• At en hidtil lokal løsning får fjernadgang.
• At produktet markedsføres til et nyt formål, fx sikkerhedsopgaver. Så skal også kategorien tjekkes, se CE-mærke på software.

En fast vurdering i releaseprocessen

Vurderingen må ikke være et stort projekt hver gang. Sådan kan den bygges ind:

1. Markér de få releases, der er relevante. Tre spørgsmål i udgivelsens tjekliste er nok: Ændrer den produktets formål? Kommer der en ny ekstern grænseflade? Ændrer den, hvilke data der flytter sig hvorhen?
2. Svar ja eller nej. Er alle tre nej, noteres det, og udgivelsen fortsætter. Det tager et øjeblik.
3. Lav en kort vurdering ved et ja. Ejeren af produktets sikkerhed skriver, hvad der ændres, hvilke nye risici der følger, og konklusionen.
4. Eskaler. Peger vurderingen mod en væsentlig ændring, går sagen til ledelsen, inden funktionen udgives.
5. Gem det. Vurderingen ligger sammen med den version, den hører til. Skriv den som et kort notat, se skriv de tekniske beslutninger ned.

Selve releasen skal i øvrigt kunne gennemføres uden drama, se hver release er en risiko.

Beslutningen for ledelsen

Viser det sig, at en ændring er væsentlig, er der flere veje.

• Tag ændringen og kravene med. Det giver mening, når produktet skal leve videre, og I alligevel skal i gang.
• Del funktionen ud. Læg den nye grænseflade i et nyt produkt, som fra start er bygget efter kravene, og lad det gamle fortsætte uændret. Få en advokat til at vurdere, om det holder.
• Vent. Udskyd ændringen, til den nye version er klar.

Valget hænger sammen med, om det gamle produkt skal skrives om, se skal produktet skrives om?. Har I et ældre produkt med mange kunder, er det værd at planlægge det nu, så I ikke møder december 2027 med en ændring, der skal ud med det samme.

Tegn på, at spørgsmålet ikke er på plads

• Ingen kan sige, hvilke produkter der var på markedet før datoen.
• Nye API’er udgives, uden at nogen spørger om konsekvensen.
• Salg kalder en stor ny funktion for en opdatering, og produktchefen kalder den et nyt produkt.
• Vurderinger findes i hovedet på én person.

Det skal I lade være med

• At måle ændringen på antallet af kodelinjer · det er formål og risiko, der tæller.
• At vente med sikkerhedsrettelser af frygt for reglerne · rettelser er generelt ikke væsentlige ændringer.
• At kalde alt for en sikkerhedsopdatering · en ny funktion bliver ikke en rettelse af navnet.

Det skal I kræve af den eksterne

• ☐ Tre faste spørgsmål i releaseprocessen.
• ☐ Et kort notat ved hvert ja, gemt pr. version.
• ☐ En liste over produkter og datoer for omsætning.
• ☐ En klar vej til ledelsen ved tvivl.
• ☐ Forslag til, hvad der gøres ved en væsentlig ændring.

Kilder

• Kommissionens vejledning C(2026) 5252: ikke bindende, nr. 15, 108 og 109.
• Kommissionens FAQ: afsnit 1.4 om produkter fra før datoen.
• Forordning (EU) 2024/2847: art. 69, stk. 2 og 3, og betragtning 39.

Senest gennemgået: november 2026.

Næste skridt

• Sikkerhed i produktet og i udviklingsprocessen
• Supportperiode: hvor længe lover I at rette sårbarheder?

Læs også: Teknisk køreplan ved siden af produktkøreplanen · Et produkt, der er vokset fra sin teknologi

→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT