CE‑mærke på software: selvvurdering eller bemyndiget organ?

Med Cyber Resilience Act skal software, der er omfattet, have CE-mærke fra 11. december 2027, efter at I som fabrikant har lavet en overensstemmelsesvurdering og en EU-overensstemmelseserklæring. Standardprodukter kan som hovedregel selvvurderes. Vigtige produkter i bilag III og kritiske produkter i bilag IV har en skrappere vurdering, typisk med et bemyndiget organ eller en certificeringsordning. Afgørende er produktets kernefunktion, og det er det første spørgsmål, ledelsen skal have svar på. Teksten erstatter ikke juridisk rådgivning.

De tre kategorier

CRA inddeler produkterne efter risiko:

• Standardprodukter. Alt, der ikke står i bilagene. Kan som hovedregel selvvurderes. Fagudtrykket er modul A, og det betyder, at I selv kontrollerer og erklærer, at produktet opfylder kravene.
• Vigtige produkter, bilag III. Inddelt i klasse I og klasse II. Vurderingen er skrappere.
• Kritiske produkter, bilag IV. Vurderingen er ligeledes skrappere.

Et bemyndiget organ er en uafhængig instans, som er udpeget til at vurdere produkter. Reglerne om bemyndigelse af overensstemmelsesvurderingsorganer gælder siden 11. juni 2026.

Kernefunktionen afgør det

En almindelig fejl er at tro, at et produkt er vigtigt, fordi det indeholder en sikkerhedsfunktion. Ifølge Kommissionens vejledning, afsnit 6, er det produktets kernefunktion, der tæller. Vejledningen nævner SIEM, altså systemer til indsamling og analyse af sikkerhedslogs, som klasse I og firewalls og indtrængningsdetektion som klasse II.

Tænkt eksempel 1. Et økonomisystem har login og logning. Sikkerhedsfunktionerne er en del af produktet, men kernefunktionen er økonomi. Det peger væk fra bilag III.

Tænkt eksempel 2. Et softwarehus sælger et værktøj, hvis hele formål er at opdage indtrængen på kundernes systemer. Kernefunktionen ligger her tæt på vejledningens eksempler, og bilag III skal læses nøje.

Eksemplerne er tænkte. Læs bilagene selv, og skriv begrundelsen ned. Vejledningen er ikke bindende.

Hvad dokumentationen indeholder

Selvvurdering betyder ikke, at der er mindre at lave. Den tekniske dokumentation er beskrevet i forordningens bilag VII, og det er den, I skal læse, når I går i gang. I praksis samler arbejdet sig om:

• Cybersikkerhedsrisikovurderingen. Hvad kan gå galt, og hvad har I gjort ved det?
• Beskrivelsen af produktet og designet. Her kan arkitekturbeskrivelsen på tre sider være et udgangspunkt, selv om den er skrevet til kunder.
• Komponenter. Softwarekomponentlisten, se tredjepartsbiblioteker, SBOM og byggepipeline.
• Håndtering af sårbarheder. Hvordan I tager imod, retter og melder.
• Supportperioden. Hvordan den er fastsat, se supportperiode.
• Test. Hvad I har testet, og hvad resultatet blev.

Listen er vores praktiske opdeling af arbejdet. Bilag VII er det gældende. EU-overensstemmelseserklæringen er derefter jeres egen skriftlige erklæring om, at produktet opfylder kravene, så den, der underskriver, skal kende grundlaget.

Standarderne

Harmoniserede standarder er fælles tekniske standarder, som kan støtte vurderingen. Her skal I være varsomme med planen. Første leverancer var planlagt til 3. kvartal 2026 og flere til 30. oktober 2027, men om de første er kommet, er ikke bekræftet. Slå status op hos Kommissionen, før I bygger en plan på dem. Arbejdet med risikovurdering og dokumentation kan begynde, uanset hvornår de kommer.

Sådan griber I det an

1. Afgør, om produktet er omfattet. Brug de tre spørgsmål om omfanget.
2. Bestem kategorien. Formuler kernefunktionen i én sætning, og sammenlign med bilag III og IV. Passer sætningen med markedsføringen? Ændrer I den, kan kategorien ændre sig.
3. Vælg vurdering. Standardprodukt betyder som hovedregel selvvurdering. Er produktet vigtigt eller kritisk, så afklar tidligt, hvilken vurdering der kræves, og hvem der kan udføre den.
4. Byg dokumentationen op. Lav den som en del af det daglige arbejde, med en mappe pr. version.
5. Placer ansvaret. Hvem underskriver? Den person skal forstå, hvad der skrives under på, og kunne se vurderingerne af væsentlige ændringer.
6. Afklar mærkningen. Hvordan CE-mærket placeres på software, der leveres digitalt, skal læses i forordningens tekst.

Hvad ledelsen skal spørge om

• Hvad er vores produkts kernefunktion, i én sætning?
• Stemmer den sætning med hjemmesiden og salgsmaterialet?
• Hvem skriver under, og hvad bygger den person sin underskrift på?
• Hvem ejer dokumentationen, når folk skifter job?
• Hvad er vores plan frem mod december 2027? Datoerne står i regler for softwarevirksomheder.

Det skal I lade være med

• At antage, at en sikkerhedsfunktion gør produktet vigtigt · det er kernefunktionen, der tæller.
• At vente på standarderne · risikovurdering og dokumentation kan starte nu.
• At lave dokumentationen som et slutprojekt · den skal bygges op undervejs.

Det skal I kræve af den eksterne

• ☐ En skriftlig kategorisering med begrundelse.
• ☐ En plan for dokumentationen efter bilag VII.
• ☐ En status på standarderne med dato.
• ☐ En navngiven underskriver, der forstår grundlaget.
• ☐ En klar markering af, hvad der kræver en advokat.

Kilder

• Kommissionen: resumé af CRA: pligter og kategorier.
• Kommissionens vejledning C(2026) 5252: ikke bindende, afsnit 6, nr. 145 ff.
• Kommissionen: gennemførelse af CRA: standarder og bemyndigelse, sidst opdateret 27. juli 2026.
• Forordning (EU) 2024/2847: bilag III, IV og VII.

Senest gennemgået: november 2026.

Næste skridt

• Sikkerhed i produktet og i udviklingsprocessen
• Cyber Resilience Act: hvad betyder den for jeres produkt?

Læs også: Sikker softwareudvikling i et lille team · Teknisk køreplan ved siden af produktkøreplanen

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