Jeres software afhænger af systemer, I ikke styrer, fx en kundes backend, internettet eller en driftsplatform. CRA kræver ikke, at I styrer dem, men risikovurderingen skal have dem med, og softwaren selv skal være bygget til at modstå det, de kan udsætte den for.
Det er Kommissionens læsning i vejledningen C(2026) 5252, punkt 168-169, som ikke er bindende. Grundlaget er pligten i artikel 13, stk. 2 og 3, i forordning (EU) 2024/2847 til at vurdere risiciene ved produktet ud fra formål, forudsigelig brug og driftsmiljø. Pligten gælder fra 11. december 2027.
Grænsen for fabrikantens ansvar
Vejledningen trækker en klar linje. Risikovurderingen omfatter risici, der stammer uden for produktet, fx fra eksterne net og miljøfaktorer. Forordningen kræver ikke, at fabrikanten styrer det ydre miljø. Den kræver, at risiciene identificeres og afbødes gennem produktets eget design, og hvor det er nødvendigt med oplysninger og anvisninger om risici ved integration og udrulning (punkt 168).
Punkt 169 siger det samme fra den anden side. CRA regulerer, hvordan produktet reagerer. Det regulerer ikke, hvordan backend-infrastrukturen organiseres, bemandes eller drives. Drift af de systemer hører til andre regler og til kunden. Hvordan den daglige drift af integrationer kontrolleres hos kunden, er et andet emne.
Tre slags afhængigheder
Det er nyttigt at skille tre slags fra hinanden, fordi de behandles forskelligt.
Fjerndatabehandling. Backend-tjenester, som jeres klient taler direkte med, og som I har designet eller fået designet, er en del af produktet. De vurderes som en del af selve produktet.
Tredjepartskomponenter. Biblioteker og tjenester, der bygges ind i produktet, håndteres efter artikel 13, stk. 5, om omhu ved integration af komponenter fra tredjeparter. Det er et andet spor (vejledningens punkt 167 og 170-173).
Eksterne afhængigheder. Systemer bag fjerndatabehandlingen, som produktet ikke taler direkte med, og miljøet, produktet kører i, er eksterne afhængigheder. De skal med i risikovurderingen og afbødes med kontroller i produktet (punkt 206). Også databehandling, der ikke understøtter en funktion, kan give risici, der skal vurderes (punkt 193).
Det, produktet skal kunne
Vejledningens punkt 169 giver konkrete eksempler, der passer direkte på software.
Risikoen for, at uvedkommende får adgang til et backend-system uden for produktet og sender ondsindede kommandoer, skal imødegås i produktet. Det kan ske med kryptografisk autentificering af fjernkommandoer, kontrol af integriteten af konfigurationsændringer og sikkerhedslogs eller alarmer ved unormal adfærd.
Falder en ekstern tjeneste ud, fx ved strømsvigt eller fejl i infrastrukturen, kan det kræve, at produktet ikke går i en usikker tilstand.
Oversat til kontrolpunkter for et softwareprodukt kan det se sådan ud. Kontrolpunkterne er vores omsætning af punkt 169:
- Autentificerer softwaren de kommandoer og konfigurationer, den modtager udefra, eller stoler den på alt fra en kendt adresse?
- Kontrollerer softwaren svar fra eksterne tjenester, før den handler på dem?
- Hvad gør softwaren, når en tjeneste ikke svarer? Låser den op, falder den tilbage til en usikker standard, eller stopper den kontrolleret?
- Logger softwaren eller advarer den, når den modtager noget uventet?
Et tænkt eksempel
Et softwarehus laver et skrivebordsprogram, der henter licens og konfiguration fra kundens egen server. Serveren drives af kunden. Programmet er produktet, serveren er en ekstern afhængighed.
Risikovurderingen bør her tage stilling til, hvad der sker, hvis serveren er kompromitteret og sender en konfiguration, der slår logning fra. Den bør også tage stilling til, hvad programmet gør, hvis serveren er nede. Svarene ligger i programmets design: signerede konfigurationer, kontrol af værdier og en sikker tilstand ved manglende forbindelse.
Hvad det kræver, og hvad det koster at lade være
Det kræver en liste over produktets afhængigheder, skilt i de tre slags, og for hver ekstern afhængighed en beskrivelse af, hvordan produktet håndterer, at den svigter eller er kompromitteret. Det meste kan bygge på arkitekturtegninger, I allerede har.
Uden den sondring ender risici let i et tomrum. Udviklingen regner med, at kunden sikrer serveren, og kunden regner med, at programmet ikke stoler blindt på den. Forordningen placerer produktets del af svaret hos jer.
Det skal I lade være med
- At skrive en ekstern afhængighed ud af vurderingen, fordi I ikke driver den · den skal med, selv om I ikke styrer den.
- At stole på kommandoer, fordi de kommer fra en kendt server · vejledningen nævner autentificering af fjernkommandoer.
- At blande eksterne afhængigheder og tredjepartskomponenter · de følger hver sit spor.
Det skal auditten kunne vise
- ☐ En liste over produktets afhængigheder, skilt i fjerndatabehandling, komponenter og eksterne afhængigheder.
- ☐ For hver ekstern afhængighed: risici og de foranstaltninger i produktet, der afbøder dem.
- ☐ Test eller beskrivelse af produktets adfærd, når en afhængighed svigter.
- ☐ Brugeroplysninger om forudsætninger for sikker integration og udrulning, hvor det er nødvendigt.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 2, 3 og 5, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 167-173, 193 og 206, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Tag arkitekturtegningen for jeres vigtigste produkt, og markér hver forbindelse som fjerndatabehandling, komponent eller ekstern afhængighed.
Læs også: Tredjeparts-SaaS, platform og infrastruktur i produktet · Integritet
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
