Artikel 69(2) i Cyber Resilience Act, forordning (EU) 2024/2847, siger, at produkter med digitale elementer bragt i omsætning før den 11. december 2027 "kun er omfattet af kravene i denne forordning, hvis de fra denne dato underkastes væsentlige ændringer". Anmeldelsespligten i artikel 14 gælder for dem uanset, siden den 11. september 2026. Alt andet, de væsentlige krav i bilag I, overensstemmelsesvurderingen, den tekniske dokumentation, CE-mærkningen, venter på den første væsentlige ændring. For en softwarevirksomhed med et produkt, der allerede er på markedet, er "hvad er en væsentlig ændring" derfor det spørgsmål, der afgør, om og hvornår forordningen overhovedet når det produkt. Og for et produkt bragt i omsætning efter den dato afgør det, om en udgivelse kræver en ny overensstemmelsesvurdering.

Forordningen definerer begrebet i artikel 3(30) og forklarer det i betragtning 39, og Kommissionens vejledning af 27. juli 2026, C(2026) 5252, afsnit 4.3, punkt 103 til 113, anvender det på softwareopdateringer med elleve gennemregnede eksempler. Afsnit 4.4.2 og 5 siger, hvad der følger. Denne artikel er de punkter, læst for et hold, der udgiver hver uge.

Testen er risikovurderingen, ikke ændringens størrelse

Punkt 104 gentager betragtning 39: Et produkt er væsentligt ændret, "hvor en ændring ændrer niveauet af cybersikkerhedsrisiko, og hvor denne ændrede eller yderligere risiko ikke er blevet taget i betragtning af fabrikanten i dens risikovurdering og dermed i dens gennemførelse af de væsentlige krav". Fabrikanten "bør derfor fra sag til sag vurdere, om en softwareopdatering indfører nye eller øgede cybersikkerhedsrisici, og om sådanne risici allerede var behandlet i dens risikovurdering".

To følger heraf, og vejledningen drager begge. For det første er en ændring af produktets tilsigtede formål sandsynligvis en: Punkt 105 siger, at hvor nye funktioner "medfører en ændring af produktets tilsigtede formål som helhed, er det sandsynligt, at fabrikanten ikke tog sådanne ændringer i betragtning i sin risikovurdering", og eksempel 40 er et overvågningsdashboard, der får evnen til at styre de maskiner, det overvåger. For det andet er størrelse ikke testen. Punkt 107: "Vurderingen af væsentlig ændring bør derfor ikke bygge på ændringens omfang eller kompleksitet, men på dens mulige negative indvirkning på cybersikkerhedsrisikoprofilen." Eksempel 44 er det, ethvert produkthold bør læse: En "husk mig"-funktion, der gemmer autentificeringstokens lokalt, "indfører nye risici for tokentyveri, uautoriseret adgang og sessionskapring, som ikke blev taget i betragtning i risikovurderingen", og applikationen "er blevet væsentligt ændret". Eksempel 45 er en diagnosefunktion, der eksporterer detaljerede logfiler, tilsyneladende lille, som gemmer følsomme driftsdata ukrypteret: væsentligt ændret.

Den anden side er punkt 106. Hvor fabrikanten "har forudset udviklingen af disse funktioner, allerede har beskrevet og vurderet de tilknyttede risici og har gennemført passende afbødende foranstaltninger", "bør opdateringen derfor ikke" anses for en væsentlig ændring. Eksempel 42 er en beskedapp, hvis oprindelige risikovurdering dækkede den senere indførelse af gruppebeskeder, "herunder for eksempel den øgede kompleksitet i beskedrouting"; når gruppechat udgives med de forudsete administrator- og moderationskontroller, er intet væsentligt ændret. Eksempel 43 er et overvågningssystem leveret med styringssløjfer til stede, men deaktiveret og vurderet; at aktivere dem er ikke en væsentlig ændring.

Det er hele mekanismen. En risikovurdering, der navngiver køreplanen, absorberer køreplanen. En risikovurdering skrevet én gang, for produktet som det var, gør enhver betydningsfuld funktion til en væsentlig ændring.

Sikkerhedsopdateringer: som regel ikke, med to undtagelser

Punkt 108, igen fra betragtning 39: "Sikkerhedsopdateringer skal som regel ikke anses for væsentlige ændringer, da deres primære formål er at sænke niveauet af cybersikkerhedsrisiko." Det gælder, "selv hvor opdateringen kan indebære betydelige tekniske ændringer", og det dækker funktioner, der "ændres eller begrænses udelukkende for at afbøde identificerede sårbarheder". Eksempel 46 er en rettelse af en inputvalideringsfejl eller en sessionstokenkontrol. Eksempel 47 er hærdning: stramme firewallregler, lukke porte, ændre standardpolitikker for adgangskoder, gøre multifaktorgodkendelse obligatorisk, hvor den allerede fandtes. Eksempel 48 er at bytte en forældet algoritme ud med en stærkere, som designet allerede understøttede.

Punkt 109 giver undtagelserne: en sikkerhedsopdatering, der ændrer det tilsigtede formål ud over det forudsete, eller "væsentligt ændrer produktets grænser eller afhængighedsstruktur på en måde, der ikke var forudset i risikovurderingen, f.eks. ved væsentligt at ændre datastrømme eller tilføje nye udefra tilgængelige grænseflader". Eksempel 49 erstatter lokal filkryptering med en fjernkrypteringstjeneste drevet af fabrikanten: Produktet gør nu noget andet, så det er væsentligt ændret trods sikkerhedsmotivet. Eksempel 50 erstatter en internt forvaltet nøglelivscyklus med en tredjeparts nøglestyringstjeneste og tilføjer "nye eksterne grænseflader og afhængighed af tredjepartstjenester, der ikke var taget i betragtning i risikovurderingen": væsentligt ændret.

De fire spørgsmål til hver udgivelse

Punkt 110 opregner, hvad en fabrikant "kan overveje", og det er kort nok til en pull request-skabelon. Indfører opdateringen:

a. nye trusselsvektorer, såsom yderligere grænseflader, kommunikationskanaler, kørselsmiljøer eller eksterne afhængigheder, hvorigennem trusler kunne materialisere sig; b. muliggør den nye angrebsscenarier, herunder for eksempel nye måder, hvorpå uautoriseret adgang til, manipulation af, indgreb i eller misbrug af produktet med digitale elementer eller af de data, det behandler, plausibelt kunne forekomme; c. ændrer den sandsynligheden for tidligere identificerede angrebsscenarier, for eksempel ved at sænke den indsats eller ekspertise, der kræves for at udnytte dem, øge eksponeringen over for ikke-betroede aktører eller svække eksisterende sikkerhedsforanstaltninger; d. ændrer den den mulige konsekvens af tidligere identificerede angrebsscenarier, herunder for eksempel omfanget af berørte data eller funktioner, alvoren af driftsmæssige, sikkerhedsmæssige eller økonomiske følger eller evnen til at opdage, inddæmme eller komme sig efter en hændelse.

Punkt 111: fire gange nej, "forudsat at de antagelser og afbødende foranstaltninger, risikovurderingen bygger på, forbliver gyldige og effektive", betyder, at "det derfor er sandsynligt, at opdateringen ikke" udgør en væsentlig ændring. Punkt 112: Ethvert ja betyder, at "fabrikanten bør revurdere cybersikkerhedsrisiciene" og "afgøre, om de væsentlige krav fortsat er opfyldt". Punkt 113 tilføjer den pligt, der ikke afhænger af svaret: "Uanset om softwareopdateringer udgør væsentlige ændringer eller ej, skal fabrikanter holde risikovurderingen og den tekniske dokumentation nøjagtig, fuldstændig og løbende ajourført i overensstemmelse med artikel 13(7) og 31(2)."

Hvad den første væsentlige ændring udløser

Afsnit 4.4.2 handler om den oprindelige fabrikant, som er det almindelige softwaretilfælde. Punkt 122: Fabrikanten "forbliver fabrikanten", men "det væsentligt ændrede produkt med digitale elementer skal anses for nyligt bragt i omsætning". Punkt 123 begrænser arbejdet: I overensstemmelse med afsnit 2.1 i Den Blå Vejledning "kan fabrikanten genbruge eksisterende dokumentation og test for de aspekter af produktet med digitale elementer, der ikke berøres af den væsentlige ændring", overensstemmelsesvurderingen "bør fokusere på de væsentligt ændrede dele", og et bemyndiget organ, hvor et er involveret, "bør fokusere sin vurdering på de væsentligt ændrede dele".

For software, der allerede var på markedet før den 11. december 2027, er punkt 124 sætningen at beholde. En væsentlig ændring foretaget af den oprindelige fabrikant "kræver ikke i sig selv, at fabrikanten bringer hele det produkt med digitale elementer, der blev bragt i omsætning før denne dato, i fuld overensstemmelse med CRA, medmindre ændringen påvirker cybersikkerheden i produktet med digitale elementer som helhed negativt. Hvor ændringen ikke påvirker cybersikkerheden i produktet med digitale elementer som helhed, bør den oprindelige fabrikants forpligtelser i forbindelse med ændringen begrænses til de væsentligt ændrede dele." Den første "husk mig"-funktion efter december 2027 stiller altså login-stien, ikke hele det eksisterende produkt, under bilag I; en omskrivning, der ændrer produktets grænser, stiller det hele derunder.

Afsnit 5 tilføjer supportperioden. Punkt 128: "Hver væsentligt ændret version af et softwareprodukt med digitale elementer, der bringes i omsætning, skal have en erklæret supportperiode, der opfylder artikel 13(8)", mindst fem år, medmindre den forventede brugstid påviseligt er kortere, og hvor ændringen ikke ændrer de faktorer, der lå bag den oprindelige forventede brugstid, "er den oprindelige supportperiode uberørt". Punkt 131, for produkter udgivet med korte mellemrum: Fabrikanten skal erklære en supportperiode for hver væsentligt ændret version og kan støtte sig til artikel 13(10) for at ophøre med at afhjælpe sårbarheder i tidligere versioner, "når brugerne kan opgradere til en senere version gratis og uden at pådrage sig yderligere omkostninger", hvilket punkt 130 læser som udelukkende "obligatoriske køb af ny hardware, udskiftning af infrastruktur eller grundlæggende ændringer af driftsmiljøet", men ikke normal opgraderingsindsats. Artiklen om supportperioden dækker resten af artikel 13(8).

Hvad det betyder for et hold, der udgiver ugentligt

Tre praksisser følger af punkterne, ingen af dem ny teknik.

Skriv køreplanen ind i risikovurderingen. Punkt 106 og eksempel 42 og 43 belønner en risikovurdering, der navngiver de funktioner, I agter at udgive, og vurderer dem, før de findes. Det er billigere end en ny overensstemmelsesvurdering pr. funktion, og det er forskellen mellem eksempel 42 og eksempel 44. Risikovurderingen efter artikel 13 er der, hvor den hører hjemme.

Besvar punkt 110 i hver udgivelse. Fire spørgsmål, fire svar, én sætning hver, i udgivelsesnotatet. Hvor alle fire er nej, siger notatet, hvorfor den eksisterende vurdering stadig holder. Hvor et er ja, venter udgivelsen på den revurdering, punkt 112 kræver, og risikovurderingen og den tekniske dokumentation opdateres efter punkt 113, hvilket alligevel skyldes.

Afgør spørgsmålet om eksisterende produkter én gang. Noter for hvert produkt, der er på markedet før den 11. december 2027, versionen pr. den dato, så den første væsentlige ændring derefter kan identificeres, og noter ved hver senere udgivelse, om den var en, og efter punkt 124, om den berørte produktets sikkerhed som helhed eller kun en del.

StandardOS fører den tekniske CRA-dokumentation og risikovurderingen som levende registreringer frem for dokumenter, så en udgivelse kan knyttes til de fire svar og den vurdering, den støtter sig til. Om produktet overhovedet er omfattet, kommer først.

Kilder

  • Forordning (EU) 2024/2847, artikel 3(30), artikel 13(7), (8) og (10), artikel 31(2), artikel 21 og 22, artikel 69(2), betragtning 39 til 42 og 60.
  • Europa-Kommissionen, Kommissionens vejledning om anvendelsen af forordning (EU) 2024/2847, C(2026) 5252 final af 27. juli 2026, bilag, afsnit 4.3 (punkt 103 til 113, eksempel 40 til 50), afsnit 4.4 (punkt 114 til 124), afsnit 5 (punkt 125 til 131).
  • Europa-Kommissionen, Den Blå Vejledning om gennemførelsen af EU's produktregler, afsnit 2.1, som vejledningen citerer den.

Dette er ikke juridisk rådgivning. De elleve eksempler fylder to sider og er tættere på et produktholds virkelighed end noget andet i vejledningen; læs dem med jeres seneste ti udgivelser ved siden af.