Et softwareprodukt, hvis version kom på markedet inden skæringsdatoen 11. december 2027, skal først leve op til kravene, hvis det fra den dato ændres væsentligt. Derfor bør hver release af et ældre produkt efterlade en beslutning om, hvorvidt ændringen er væsentlig, og er den det, kan pligterne efter Kommissionens vejledning som udgangspunkt begrænses til den ændrede del.
Undtagelsen gælder ikke indberetning. Artikel 14 rammer også de ældre produkter, og den har gjaldt siden 11. september 2026.
Overgangsreglen
Artikel 69, stk. 2, i forordning (EU) 2024/2847 lader de ældre produkter stå uden for kravene, indtil de efter skæringsdatoen undergår en væsentlig ændring. Indberetningen er undtaget fra den regel, for efter stk. 3 rammer artikel 14 alle omfattede produkter. Kommissionens tjenestegrenes FAQ (1.4 og 5.3, vejledende) siger det samme og tilføjer, at forordningen for de ældre produkter ikke kræver de øvrige pligter, fx sårbarhedshåndteringen.
Definitionen i artikel 3, nr. 30, rammer en ændring, der sker efter omsætningen og enten rører ved opfyldelsen af egenskabskravene i bilag I, del I, eller flytter produktets formål ud over det, der blev vurderet.
Hvad der gør en ændring væsentlig
Betragtning 39 giver retningen. Sikkerhedsopdateringer, der ikke ændrer formålet, er normalt ikke væsentlige. Mindre funktionsopdateringer som visuelle forbedringer, nye piktogrammer eller nye sprog er det generelt heller ikke. Funktionsopdateringer, der ændrer de oprindelige funktioner eller produktets type eller ydeevne, kan være det.
I afsnit 4.3 af Kommissionens vejledning, som ikke er bindende, står der, at størrelsen af ændringen er uden betydning. Det er virkningen på risikoprofilen, der tæller. Vejledningen stiller fire spørgsmål, som ikke er udtømmende.
- Giver ændringen nye trusselsvektorer, fx grænseflader, kanaler, kørselsmiljøer eller afhængigheder?
- Giver den nye angrebsscenarier?
- Ændrer den sandsynligheden for kendte scenarier?
- Ændrer den virkningen af kendte scenarier?
Vejledningens eksempler peger begge veje. En login-funktion, der husker brugeren med lokalt gemte tokens, er væsentlig (eksempel 44), og det samme er en ny eksport af ukrypterede diagnoselogs (eksempel 45). En gruppechat, der var forudset og vurderet fra start, er ikke væsentlig (eksempel 42), og det er en rettelse af inputvalidering heller ikke (eksempel 46). De fire spørgsmål er uddybet i artiklen om væsentlig ændring.
Beslutningen pr. release
For et ældre produkt er det praksis at lade hver release efterlade en kort beslutning. Ingen regel kræver den. Det er den, der viser, at produktet stadig falder under overgangsreglen. En beslutning kan indeholde disse oplysninger, her med tænkte eksempler.
- Release og dato · (7.4.0, dato)
- Hvad er ændret · (Ny eksport af rapporter til regneark)
- Svar på de fire spørgsmål · (Ny eksportkanal, ingen nye grænseflader udadtil)
- Konklusion · (Ikke væsentlig, begrundet)
- Hvem har besluttet · (Produktchef)
Beslutningen er nemmest at træffe i den release-proces, I allerede har. Er der tvivl, er det et tegn på, at ændringen bør vurderes grundigere.
Når ændringen er væsentlig
Vejledningens punkt 124 er det, der giver luft. En væsentlig ændring, som den oprindelige fabrikant foretager på et produkt fra før skæringsdatoen, kræver ikke i sig selv, at hele produktet bringes i fuld overensstemmelse. Pligterne begrænses til de væsentligt ændrede dele, medmindre ændringen påvirker produktets cybersikkerhed som helhed negativt.
Punkt 123 tilføjer, at de dele, ændringen lader urørt, kan beholde deres hidtidige dokumentation og testresultater, og at vurderingen bør samle sig om de ændrede dele.
Begrænsningen er vejledningens og gælder den oprindelige fabrikant. For andre, der ændrer et produkt væsentligt, gælder artikel 22, som har sin egen artikel.
Ajourføring uanset svaret
Vejledningens punkt 113 minder om pligten til løbende at ajourføre risikovurderingen og den tekniske dokumentation efter artikel 13, stk. 7, og artikel 31, stk. 2, uanset om en opdatering er væsentlig. Efter vores læsning gælder det kun produkter, der er omfattet af kravene. For et produkt fra før december 2027, der aldrig ændres væsentligt, er det beslutningssporet og indberetningsberedskabet, der bærer.
Hvad det kræver, og hvad det koster at lade være
Det kræver et fast punkt i release-processen og en person, der kan svare på de fire spørgsmål. For produkter med mange releases er det en vane, der skal indarbejdes før december 2027.
Uden sporet kan en væsentlig ændring glide ind uden at blive opdaget, og produktet står så uden den overensstemmelsesvurdering, det skulle have haft.
Det skal I lade være med
- At vurdere ændringer efter antallet af kodelinjer · vejledningen ser på virkningen på risikoprofilen.
- At bringe hele produktet i overensstemmelse ved første væsentlige ændring uden at se på punkt 124 · pligten kan som udgangspunkt begrænses.
- At glemme indberetningen for de ældre versioner · artikel 14 gælder dem også.
Det skal auditten kunne vise
- ☐ En liste over de produkter og versioner, der kom på markedet før skæringsdatoen.
- ☐ For hver release efter den dato en begrundet beslutning om væsentlig ændring.
- ☐ Ved væsentlig ændring en afgrænsning af de ændrede dele og deres vurdering.
- ☐ Beredskab til indberetning efter artikel 14 for de ældre versioner.
Kilder
- Forordning (EU) 2024/2847, dansk tekst, artikel 3, nr. 30, artikel 69, stk. 2 og 3, og betragtning 39, læst 13. november 2026 i Publikationskontorets kopi.
- Kommissionens vejledning C(2026) 5252, punkt 103 til 113, 123 og 124 og eksempel 42 til 46, ikke bindende, læst 13. november 2026.
- Kommissionens tjenestegrenes FAQ om CRA, version 1.4, FAQ 1.4 og 5.3, vejledende, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Læg et fast punkt ind i release-processen, hvor de fire spørgsmål besvares og gemmes.
Læs også: Hvornår er softwaren bragt i omsætning? · Væsentlig ændring
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
