En harmoniseret standard, der dækker produktets væsentligste funktionalitet, kan åbne for egenkontrol efter modul A for hele produktet. Formodningen om overensstemmelse gælder til gengæld kun de risici, standarden dækker. Produktets øvrige funktioner skal fabrikanten selv risikovurdere og dokumentere.
Kommissionen viser det med et eksempel om et antivirusprodukt. Skellet mellem adgang til modul A og formodning om overensstemmelse er to forskellige ting, og de blandes let sammen. Kravene gælder fra 11. december 2027.
To begreber, der ofte blandes
Adgang til modul A. For et klasse I-produkt afhænger valget af procedure af, om standarder, fælles specifikationer eller certificering er anvendt helt og fuldt (artikel 32, stk. 2). Kommissionen forklarer i vejledningen (punkt 148 til 149), at standarden skal anvendes med alle relevante krav, og at dens anvendelsesområde skal dække mindst alle risici ved den væsentligste funktionalitet.
Formodning om overensstemmelse. Artikel 27, stk. 1, knytter formodningen om overensstemmelse til standarder, hvis reference står i EU-Tidende, og formodningen omfatter de krav, standarden dækker. Kommissionen forklarer (vejledningen punkt 153 til 155 og eksempel 64 og 65), at formodningen kun gælder de risici, standarden dækker.
Adgangen til modul A afhænger altså af, at standarden dækker kernen. Formodningen gælder kun det, standarden faktisk dækker.
Kommissionens antiviruseksempel
Vejledningens eksempel 62 (punkt 151) handler om et antivirusprodukt med to ekstra funktioner: diskrensning og anti-tracking. Antimalware er en kategori i klasse I.
I eksemplet risikovurderer fabrikanten hele produktet. Den anvender en harmoniseret standard for den væsentligste funktionalitet, altså antivirusdelen. For de øvrige funktioner træffer den ekstra foranstaltninger. På det grundlag må fabrikanten bruge modul A for hele produktet.
Det, eksemplet viser, er rækkefølgen. Risikovurderingen kommer først og dækker alt. Standarden dækker kernen og giver adgang til proceduren. De ekstra tiltag dækker resten og skal dokumenteres af fabrikanten selv.
Hullet mellem standard og produkt
Vejledningen (punkt 151) siger, at hvor der er et hul mellem standardens dækning og produktet, skal fabrikanten dokumentere de ekstra tiltag. Hullet kan være større, end det ser ud til, fordi produkter vokser med funktioner, som en standard for kategorien ikke har forudset.
Tænkte eksempler på funktioner, der kan ligge uden for en standard for kernen:
- en synkroniseringstjeneste til flere enheder
- et plugin til et kontorprogram, der følger med produktet
- en indbygget rapportfunktion, der sender data til en server
- et administrationsmodul til virksomhedskunder
For hver af dem skal risikovurderingen sige, hvilke krav i bilag I der er relevante, og hvordan de er opfyldt. Den dokumentation hører til den tekniske dokumentation efter bilag VII.
Sådan kan kortlægningen se ud
En enkel måde at gøre hullet synligt på er at tage risikovurderingens liste over funktioner og sætte et mærke ved hver: dækket af standarden, delvis dækket eller ikke dækket. For de to sidste skrives det, hvilke krav i bilag I der er relevante, hvilke tiltag der er truffet, og hvor beviset ligger, fx en testrapport eller en designbeslutning. Det er praksis og ikke en metode, forordningen foreskriver.
Kortlægningen bliver samtidig en tjekliste ved næste release. Kommer der en ny funktion til, skal den have et mærke, før den frigives. På den måde vokser dokumentationen med produktet i stedet for at halte bagefter.
Standarden erstatter ikke risikovurderingen
Kommissionens FAQ (punkt 4.1.7) henviser til Kommissionens Blue Guide og siger, at harmoniserede standarder ikke erstatter risikovurderingen. Fabrikanten skal selv kontrollere, om standarden dækker alle produktets risici. Vejledningen (punkt 150) siger det samme.
For en gennemgang betyder det, at en henvisning til en standard ikke kan stå alene. Gennemgangen spørger, hvilke risici standarden dækker, hvilke den ikke dækker, og hvor dokumentationen for resten ligger. Metoden er praksis.
Når produktet integrerer et andet vigtigt produkt
Vejledningen (punkt 152 og eksempel 63) behandler en router med indbygget firewall. Det er helhedens væsentligste funktionalitet, der tæller, så routeren klassificeres og vurderes som router. Firewallfunktionen skal stadig risikovurderes. Gælder der en standard for routere, dækker den ikke nødvendigvis firewallen. Den del skal fabrikanten dokumentere selv. Reglen om integrerede produkter er beskrevet i integrerede vigtige produkter.
Status i november 2026
Da vi tjekkede i november 2026, var der efter vores oplysninger ikke offentliggjort referencer til harmoniserede CRA-standarder. Kommissionens side om standardisering nævner, at standardiseringsanmodningen blev ændret den 10. november 2026, så fristerne for alle vertikale og nogle horisontale standarder er forlænget med tre måneder. Hvordan tidsplanen lægges, står i klasse I uden harmoniseret standard, og det, der beskrives her, bliver først praktisk, når standarderne er offentliggjort.
Hvad det kræver, og hvad det koster at lade være
Det kræver en risikovurdering af hele produktet, en kortlægning af hvilke funktioner standarden dækker, og skrevet dokumentation af tiltag for de funktioner, den ikke dækker.
Henviser den tekniske dokumentation kun til standarden, står de ekstra funktioner uden dokumentation. En myndighed, der spørger til en af dem, får intet svar, og formodningen hjælper ikke, fordi den ikke rækker dertil.
Det skal I lade være med
- At skrive, at standarden dækker hele produktet · formodningen gælder kun det, standarden dækker.
- At lade risikovurderingen følge standardens omfang · den skal dække alle produktets funktioner.
- At glemme funktioner, der kom til efter første version · de ligger ofte uden for standarden.
Det skal auditten kunne vise
- ☐ En risikovurdering af hele produktet.
- ☐ En kortlægning af, hvilke funktioner og risici standarden dækker.
- ☐ Dokumenterede ekstra tiltag for funktioner uden for standarden.
- ☐ Opdatering af kortlægningen, når produktet får nye funktioner.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 27, stk. 1, og artikel 32, stk. 2, læst 13. november 2026.
- Europa-Kommissionen, vejledning C(2026) 5252, punkt 148-155 og eksempel 62-65, læst 13. november 2026.
- Europa-Kommissionen, FAQs on the Cyber Resilience Act, version 1.4, punkt 4.1.7, læst 13. november 2026.
- Europa-Kommissionen, Cyber Resilience Act: Standardisation, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv jeres produkts funktioner op i to kolonner: dem, en standard for kategorien vil dække, og dem, den ikke vil.
- Vigtige softwareklasser og vurdering med tredjepart
- Cybersikkerhedsrisikovurderingen for et softwareprodukt
Læs også: Vigtigt produkt eller ej? · Den tekniske dokumentation efter bilag VII
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
