Software, hvis væsentligste funktionalitet er identitetsstyring eller styring af privilegeret adgang, er et vigtigt produkt i klasse I. Den tekniske beskrivelse nævner udtrykkeligt single sign-on-software, engangskodesoftware, autentificeringssoftware og flerfaktorautentificeringssoftware.
Kategorien er den første i bilag III, klasse I. For et softwarehus med et login-produkt betyder det, at modul A kun kan bruges, hvis en harmoniseret standard eller tilsvarende er anvendt fuldt. Kravene gælder fra 11. december 2027.
Kategorien i forordningen
Bilag III, klasse I, punkt 1, lyder: “Software og hardware til identitetsstyringssystemer og til styring af privilegeret adgang, herunder autentificerings- og adgangskontrollæsere, herunder biometriske læsere.”
Ordlyden er kort og blander software og hardware. Derfor er gennemførelsesforordning (EU) 2025/2392 nødvendig for at afgøre, hvilke softwareprodukter der hører til.
Den tekniske beskrivelse
Gennemførelsesforordningens bilag I beskriver kategorien i to dele.
Identitetsstyringssystemer indeholder mekanismer til autentificering eller tilladelse. De kan omfatte livscyklusforvaltning af identitetsoplysninger, dvs. registrering, levering, vedligeholdelse og afregistrering, for fysiske og juridiske personer, enheder eller systemer. Kategorien omfatter også adgangsstyringssystemer til digitale ressourcer eller fysiske lokaliteter.
Software til styring af privilegeret adgang kontrollerer og overvåger adgangsrettigheder til IT- eller OT-systemer og følsomme oplysninger. Det omfatter differentierede politikker for privilegerede brugere.
Beskrivelsen nævner en række produkter, som kategorien omfatter, men som ikke udtømmer den:
- autentificerings- og adgangskontrollæsere, herunder biometriske læsere
- single sign-on-software
- samlet identitetsstyringssoftware
- engangskodesoftware
- hardwareautentificeringsudstyr som TAN-visere
- autentificeringssoftware
- flerfaktorautentificeringssoftware
Hvornår jeres produkt hører til
Afgørelsen følger den generelle prøve. Er identitetsstyring eller privilegeret adgang den væsentligste funktionalitet, hører produktet til kategorien. Har produktet blot et login, hører det ikke til. Prøven er gennemgået i vigtigt produkt eller ej.
Tre tænkte produkter viser forskellen. Vurderingerne er vores anvendelse af reglerne og ikke Kommissionens eksempler.
- (En tjeneste til fælles login for virksomhedens mange systemer) · Væsentligste funktionalitet: Autentificering og single sign-on · Vurdering: Kategorien i punkt 1
- (En app, der genererer engangskoder til andre systemer) · Væsentligste funktionalitet: Engangskoder til autentificering · Vurdering: Kategorien i punkt 1
- (Et lønsystem med eget login og tofaktor) · Væsentligste funktionalitet: Lønberegning · Vurdering: Uden for kategorien, login er en bifunktion
Det sidste eksempel er det, mange softwarehuse står i. At et forretningssystem har et godt login med flerfaktor, gør det ikke til et identitetsstyringsprodukt. Kommissionen forklarer (vejledningen punkt 141 til 142), at en funktion, produktet kan udføre, ikke afgør klassen, når den væsentligste funktionalitet er en anden.
Privilegeret adgang og fysisk adgang
Kategorien rækker videre end login for almindelige brugere. Software til styring af privilegeret adgang er med, og beskrivelsen lægger vægt på kontrol og overvågning af adgangsrettigheder og på differentierede politikker for privilegerede brugere. Et produkt, hvis hovedopgave er at udlevere, begrænse og logge administratorers adgang til servere eller OT-anlæg, ligger derfor tæt på kategoriens kerne.
Beskrivelsen nævner også adgangsstyringssystemer til fysiske lokaliteter. Et softwarehus, der udvikler programmet bag et adgangssystem til bygninger, kan derfor være omfattet, selv om læserne og dørene laves af andre. Det er vores læsning af beskrivelsen, og afgørelsen afhænger af, hvad programmet først og fremmest gør. Styrer det, hvem der får adgang og hvornår, peger det mod kategorien. Er det et bookingsystem, der blot sender en kode videre, peger det væk fra den.
Den indlejrede login-komponent
En særlig situation opstår, når et softwarehus integrerer en login-komponent fra en anden fabrikant i sit produkt. Efter artikel 7, stk. 1, flytter det samlede produkt ikke i klasse, blot fordi et vigtigt produkt er bygget ind. Hvordan reglen anvendes, står i reglen om indlejrede komponenter.
Sælger I selv login-komponenten som et bibliotek eller en tjeneste til andre udviklere, er det et andet spørgsmål. Er autentificering komponentens væsentligste funktionalitet, kan den selv være et vigtigt produkt i klasse I.
Hvad klassen ændrer i gennemgangen
For et produkt i klasse I bliver to spørgsmål centrale. Har I anvendt en harmoniseret standard, fælles specifikation eller certificeringsordning på mindst niveauet “betydeligt” fuldt for de relevante krav? Hvis ikke, kræver artikel 32, stk. 2, at et bemyndiget organ inddrages via modul B og C eller modul H.
Pr. november 2026 kender vi ingen CRA-standard, hvis reference står i EU-Tidende. Hvordan et klasse I-produkt planlægges, kan I læse i klasse I uden harmoniseret standard.
Uanset klasse skal risikovurderingen være omfattende (betragtning 6 i gennemførelsesforordningen). For et login-produkt vil risikovurderingen typisk dække de samme egenskaber, som bilag I, del I, stiller krav om, fx beskyttelse mod uautoriseret adgang. Hvordan adgangskontrol vurderes som produktkrav, står i adgangskontrol i softwaren.
Hvad det kræver, og hvad det koster at lade være
Det kræver en skrevet vurdering af, om produktets væsentligste funktionalitet er identitetsstyring eller privilegeret adgang, med henvisning til den tekniske beskrivelse og til produktets egen dokumentation.
Klassificerer et identitetsprodukt sig selv i standardkategorien uden begrundelse, kan det ende med en egenkontrol, der ikke var tilladt. Er et forretningssystem omvendt klassificeret i klasse I på grund af sit login, bruges der tid og et bemyndiget organ, hvor det ikke var nødvendigt.
Det skal I lade være med
- At lade et login gøre et forretningssystem til et vigtigt produkt · den væsentligste funktionalitet afgør.
- At se bort fra kategorien, fordi produktet også kan andet · ekstra funktioner udelukker ikke klassen.
- At regne med modul A uden en fuldt anvendt standard · artikel 32, stk. 2, kræver ellers et organ.
Det skal auditten kunne vise
- ☐ En skrevet klassificering med henvisning til bilag III, klasse I, punkt 1.
- ☐ Den væsentligste funktionalitet beskrevet ens i dokumentation og markedsføring.
- ☐ En valgt procedure, der passer til klassen.
- ☐ En risikovurdering, der dækker produktets rolle for andre systemers sikkerhed.
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 6 og bilag I, klasse I, punkt 1, læst 13. november 2026.
- Europa-Kommissionen, vejledning C(2026) 5252, punkt 141-142, 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 i én sætning, hvad jeres produkt først og fremmest gør, og se, om sætningen handler om identitet og adgang.
Læs også: Klar til det bemyndigede organ · Standarden dækker kun kernefunktionen
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
