Et softwareprodukt er et vigtigt produkt, når dets væsentligste funktionalitet hører under en af kategorierne i bilag III til forordningen. Klassen afgør, om fabrikanten kan nøjes med sin egen vurdering, eller om et bemyndiget organ skal ind, og derfor er klassificeringen et af de første punkter i en gennemgang.
Kommissionen bruger på engelsk “core functionality”. I den danske tekst hedder det “væsentligste funktionalitet”. Vi bruger “kernefunktion” som forklaring hist og her, men den juridiske term er den danske. Kravene til vigtige produkter gælder fra 11. december 2027.
Reglen i artikel 7
Artikel 7, stk. 1, siger, at produkter, hvis væsentligste funktionalitet henhører under en kategori i bilag III, er vigtige produkter og omfattet af procedurerne i artikel 32, stk. 2 og 3. At et vigtigt produkt integreres i et andet produkt, gør ikke i sig selv det andet produkt omfattet af de procedurer.
Kategorierne er udvalgt efter to kriterier i artikel 7, stk. 2. Enten udfører produktet primært funktioner, der er afgørende for andre produkters, netværks eller tjenesters cybersikkerhed, fx autentifikation og adgang, forebyggelse og opdagelse af indtrængen, adgangspunktssikkerhed eller netværksbeskyttelse. Eller produktet har en funktion med betydelig risiko for at afbryde, kontrollere eller skade mange andre produkter eller brugernes sundhed eller sikkerhed, fx netværksstyring, konfigurationskontrol, virtualisering eller behandling af personoplysninger.
Bilag III deler kategorierne i klasse I og klasse II. Kommissionens gennemførelsesforordning (EU) 2025/2392 beskriver hver kategori teknisk.
Hvad klassen betyder for vurderingen
Artikel 32 fastlægger procedurerne:
- Standard · Modul A, B og C, H eller certificeringsordning (stk. 1)
- Klasse I · Modul A kun ved fuld anvendelse af standard, fælles specifikation eller certificering (mindst “betydeligt”); ellers B og C eller H for de krav (stk. 2)
- Klasse II · B og C, H eller certificering på mindst niveauet “betydeligt” (stk. 3)
Kommissionen forklarer i sin FAQ, at intet bemyndiget organ deltager ved modul A, og at kun ét bemyndiget organ deltager ved B og C og ved H. Fabrikanten kan efter Kommissionens vejledning altid vælge en strengere procedure. Software, der er open source og stilles til rådighed uden betaling, kan efter artikel 32, stk. 5, bruge proceduren for standardkategorien, hvis den tekniske dokumentation gøres offentlig.
Hvordan den væsentligste funktionalitet findes
Begrebet er ikke defineret i forordningen. Kommissionen forklarer i vejledningen (punkt 138 til 139), at det er produktets vigtigste egenskaber og tekniske kapaciteter, uden hvilke det ikke kan opfylde sit tilsigtede formål. Den vurderes bl.a. ud fra brugsanvisning, salgs- og reklamemateriale og teknisk dokumentation.
Tre regler fra vejledningen og gennemførelsesforordningen styrer vurderingen:
- Ekstra funktioner udelukker ikke klassen. Et produkt med en kategoris væsentligste funktionalitet bliver i kategorien, selv om det kan mere (betragtning 4 i gennemførelsesforordningen, vejledningen punkt 140).
- En evne gør ikke en kategori. Et produkt, der kan udføre en kategoris funktion, men hvis væsentligste funktionalitet er en anden, hører ikke til kategorien (betragtning 5, vejledningen punkt 141 til 142).
- De tekniske egenskaber tæller. Hvor beskrivelsen i markedsføringen ikke svarer til produktet, er det produktets egenskaber, der afgør (vejledningen punkt 142).
Kommissionen tilføjer (punkt 143 og 144), at fabrikanten ikke må fremstille den væsentligste funktionalitet misvisende for at undgå en procedure. Tegnene er klare uoverensstemmelser mellem reklame, brugsanvisning og teknisk dokumentation. Et produkt har i denne sammenhæng kun én væsentligste funktionalitet, og den bør fremgå klart af den tekniske dokumentation.
Moduler solgt hver for sig
Vejledningen (punkt 145) siger, at moduler, der også sælges, licenseres eller abonneres hver for sig, er selvstændige produkter og klassificeres hver for sig. Moduler, der kun leveres som del af helheden, klassificeres på helhedens niveau. Kommissionens eksempel 61 er en sikkerhedssuite med et SIEM-modul i klasse I, et modul til indtrængningsdetektion i klasse II og et analysemodul i standardkategorien. Hvordan særskilt salg virker, står i tillægsmoduler solgt særskilt.
Risikovurderingen gælder uanset klasse
Klassen afgør proceduren. Den fritager ikke for risikovurderingen. Betragtning 6 i gennemførelsesforordningen og Kommissionens FAQ (punkt 3.3) siger, at fabrikanten uanset klasse skal lave en omfattende risikovurdering. FAQ’en bruger to VPN-produkter med forskellig risiko som eksempel. Eksemplerne i gennemførelsesforordningen er ifølge betragtning 7 kun illustrative og ikke udtømmende.
Det, en gennemgang efterprøver
En gennemgang af klassificeringen holder fabrikantens begrundelse op mod tre kilder: den tekniske beskrivelse af kategorien, produktets egen dokumentation og det materiale, kunderne ser. Den spørger, om produktsiden lover funktioner, som dokumentationen nedtoner. Den spørger også, om modulerne sælges hver for sig. Gennemgangen ser også efter, om klassificeringen er gentaget, når produktet har fået nye funktioner, fordi en ny hovedfunktion kan flytte produktet til en anden kategori. Metoden er praksis. Brud på artikel 32 kan efter vejledningen (punkt 146) give administrative bøder efter artikel 64, stk. 3.
Hvad det kræver, og hvad det koster at lade være
Det kræver en skrevet klassificering for hvert produkt og modul med henvisning til kategorien i bilag III og gennemførelsesforordningen, og en gennemlæsning af markedsføringen med samme øjne.
En forkert klassificering opdages måske først, når et bemyndiget organ eller en myndighed spørger. Så kan en vurdering, der skulle have haft et organ med, være gennemført som egenkontrol, og produktet kan stå uden en gyldig overensstemmelsesvurdering.
Det skal I lade være med
- At klassificere efter hvad produktet kan · det er den væsentligste funktionalitet, der tæller.
- At beskrive produktet forskelligt i salg og dokumentation · Kommissionen ser det som et tegn på misvisning.
- At glemme moduler, der sælges særskilt · de klassificeres hver for sig.
Det skal auditten kunne vise
- ☐ En skrevet klassificering pr. produkt og modul med henvisning til bilag III.
- ☐ Den væsentligste funktionalitet beskrevet i den tekniske dokumentation.
- ☐ Overensstemmelse mellem markedsføring, brugsanvisning og dokumentation.
- ☐ En valgt procedure efter artikel 32, der passer til klassen.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 7, artikel 32 og bilag III, læst 13. november 2026.
- Kommissionens gennemførelsesforordning (EU) 2025/2392, betragtning 2-7, læst 13. november 2026.
- Europa-Kommissionen, vejledning C(2026) 5252, punkt 138-146 og eksempel 61, læst 13. november 2026.
- Europa-Kommissionen, FAQs on the Cyber Resilience Act, version 1.4, punkt 3.1, 3.3 og 6.1-6.3, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv for hvert produkt én sætning om den væsentligste funktionalitet, og hold den op mod jeres produktside.
Læs også: Indlejret browser eller login-komponent i jeres app · Modul A for et softwareprodukt
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
