Kræver produktets formål en ældre protokol eller en standard, hvis sikkerhed ikke længere er tidssvarende, kan et væsentligt krav være umuligt at opfylde fuldt. Forordningen og Kommissionens vejledning beder så fabrikanten om at begrunde begrænsningen i risikovurderingen, kompensere for den, oplyse brugerne og genvurdere den løbende, og vejledningen forventer, at den sikre løsning er slået til som standard, hvor produktet kan understøtte den.
Reglerne giver altså en metode til at dokumentere en begrænsning, så den kan forklares bagefter.
Grundlaget i forordningen
Betragtning 55 i forordning (EU) 2024/2847 beskriver situationen. Er et væsentligt krav uforeneligt med produktets karakter, fx fordi formålet kræver anerkendte interoperabilitetsstandarder, hvis sikkerhedsfunktioner ikke længere er på det aktuelle tekniske niveau, skal fabrikanten give en klar begrundelse i risikovurderingen. Risiciene skal imødegås på anden vis, fx ved at begrænse formålet til pålidelige miljøer eller ved at informere brugerne.
Kommissionens tjenestegrenes FAQ (4.1.3, vejledende) gentager betragtningen. Den regel, der bærer begrundelsen i dokumentationen, er artikel 13, stk. 4, om krav, der ikke er relevante.
Vejledningens fire skridt
Vejledningen fra Kommissionen, C(2026) 5252, er uden bindende virkning og går mere i detaljer i punkt 31 og 32. Fabrikanten bør identificere og dokumentere begrænsningerne, vurdere risiciene og gennemføre passende alternative eller kompenserende foranstaltninger. Teknisk dokumentation og brugeroplysninger efter bilag II beskriver begrænsningerne, risiciene og foranstaltningerne. Og fabrikanten bør periodisk genvurdere, om begrænsningerne stadig findes, og opdatere produktet, når de kan lempes.
Ordet er bør. Punkt 32 står i et afsnit om komplekse systemer, men fodnote 10 siger, at punktet efter omstændighederne kan gælde alle produkter. Det er derfor relevant for almindelig software.
Den sikre protokol som standard
Eksempel 10 i vejledningen handler om et produkt, der kan understøtte både en sikker og en ældre protokol. Fabrikanten forventes at gennemføre den sikre og slå den til som standard. Den ældre er kun tilladt, hvor interoperabilitet kræver det.
For et softwarehus kan det fx betyde, at en integration med ældre systemer hos kunden tilbyder den nye protokol først og kun falder tilbage til den gamle, når modparten ikke kan andet. Eksemplet er vores og ikke vejledningens.
Sådan dokumenteres en begrænsning
Det er praksis at samle hver begrænsning i én post med de oplysninger, punkt 31 og 32 nævner. Felterne nedenfor er vores forslag, og parenteserne er tænkte.
- Krav i bilag I, der ikke opfyldes fuldt · (Beskyttelse af data under transport)
- Hvorfor · (Kundens maskiner understøtter kun en ældre protokol)
- Risiko · (Aflytning på det lokale net)
- Kompenserende foranstaltning · (Forbindelsen begrænses til det interne net, og data krypteres i applikationen)
- Standardindstilling · (Den nyere protokol er slået til, den ældre kun ved behov)
- Oplysning til brugeren · (Afsnit i brugervejledningen om begrænsningen)
- Næste genvurdering · (Dato)
Posten hører hjemme i risikovurderingen og den tekniske dokumentation. Oplysningen til brugeren skal stå i brugeroplysningerne efter bilag II.
Når det ikke er en begrænsning
Ikke alt, der er besværligt, er en begrænsning i betragtning 55’s forstand. Betragtningen taler om krav, der er uforenelige med produktets karakter, fx fordi formålet kræver en bestemt interoperabilitetsstandard. At den nye protokol kræver arbejde, eller at en kunde helst vil vente, er en anden sag.
Vejledningens punkt 163 er tydelig på det punkt. Står en risiko ubehandlet, så kravene ikke bliver opfyldt, kan det ikke forsvares med, at løsningen ville være dyr eller svær at sælge. En begrundelse, der i virkeligheden handler om tid eller budget, holder derfor ikke. Efter vores læsning er den første prøve derfor, om det er formålet og modparten, der kræver den ældre løsning, eller jeres egen plan. Hvordan restrisici i øvrigt vurderes, står i artiklen om restrisiko.
Genvurderingen i supportperioden
En begrænsning kan ophøre. Vejledningen beder fabrikanten genvurdere den periodisk og opdatere produktet, når den kan lempes. Ophører kunderne med at bruge den ældre protokol, eller kommer der en sikker afløser, er det en anledning til at fjerne fallback-muligheden. Risikovurderingen skal under alle omstændigheder ajourføres i relevant omfang i supportperioden (artikel 13, stk. 3).
Det er naturligt at lægge genvurderingen ind i den faste gennemgang af risikovurderingen, så den ikke afhænger af, at nogen husker den.
Driften hos kunden
Hvordan kunden selv afgrænser og overvåger den ældre protokol i sit net, er et driftsspørgsmål. Det hører til en teknisk gennemgang af kundens miljø. Her er spørgsmålet, hvad fabrikanten skal kunne vise om produktet.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at begrænsningen er kendt og beskrevet, før produktet bringes i omsætning, og at nogen ejer genvurderingen. Kravene gælder fra 11. december 2027.
Står begrænsningen ingen steder, vil en myndighed eller kunde se den som en mangel. Med begrundelse, kompenserende foranstaltninger og oplysning til brugerne kan I vise, at den er en bevidst og vurderet beslutning.
Det skal I lade være med
- At lade den ældre protokol være standard, fordi den virker overalt · vejledningen forventer den sikre som standard.
- At skjule begrænsningen for brugerne · den skal stå i brugeroplysningerne.
- At regne begrænsningen for afgjort én gang for alle · den skal genvurderes periodisk.
Det skal auditten kunne vise
- ☐ En liste over krav, der ikke kan opfyldes fuldt, med begrundelse.
- ☐ Kompenserende foranstaltninger for hver begrænsning.
- ☐ Standardindstillingen og hvornår den ældre løsning tages i brug.
- ☐ Dato og resultat af seneste genvurdering.
Kilder
- Forordning (EU) 2024/2847, dansk tekst, artikel 13, stk. 3 og 4, betragtning 55 og bilag II, læst 13. november 2026 i Publikationskontorets kopi.
- Kommissionens vejledning C(2026) 5252, punkt 31 og 32, fodnote 10 og eksempel 10, ikke bindende, læst 13. november 2026.
- Kommissionens tjenestegrenes FAQ om CRA, version 1.4, FAQ 4.1.3, vejledende, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find de steder, hvor produktet bruger ældre protokoller af hensyn til kunderne, og skriv en post for hver.
Læs også: Designet før 2027, ny version efter · Risikoen kan ikke flyttes til brugeren
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
