Artikel 3(1) i Cyber Resilience Act, forordning (EU) 2024/2847, definerer et produkt med digitale elementer som "et software- eller hardwareprodukt og dets fjerndatabehandlingsløsninger". Artikel 3(2) definerer fjerndatabehandling som "databehandling på afstand, hvortil softwaren er designet og udviklet af fabrikanten eller under fabrikantens ansvar, og uden hvilken produktet med digitale elementer ikke ville kunne udføre en af sine funktioner". Om jeres produkt overhovedet er omfattet, afgøres af artikel 2 og betragtning 12. Når det er, er det næste spørgsmål for enhver virksomhed med en app og en sky, hvilke dele af skyen der kom med ind, for de dele hører i risikovurderingen, de væsentlige krav, den tekniske dokumentation og anmeldelsespligten.

Kommissionens vejledning om anvendelsen af forordningen, C(2026) 5252 af 27. juli 2026, afsnit 8, punkt 178 til 208, besvarer det spørgsmål mere præcist, end forordningen gør. Denne artikel er det afsnit med dets fem anvendelsestilfælde, læst for en softwarefabrikant.

To kumulative tests

Punkt 184 deler definitionen i tre elementer: om behandlingen sker på afstand, om dens fravær ville forhindre produktet i at udføre en af sine funktioner, og om softwaren er designet og udviklet af fabrikanten eller under dennes ansvar. Punkt 185 sætter derefter det første til side som "relevant, men ikke tilstrækkeligt": Sky, edge og fabrikantens egne servere på stedet tæller alle som på afstand (punkt 187), så det første element afgør sjældent noget. Punkt 188 opstiller reglen: Det andet og det tredje er "de to afgørende og kumulative spørgsmål", og "besvares begge spørgsmål bekræftende, kvalificerer fjerndatabehandlingen" som fjerndatabehandlingsløsning.

Punkt 202 giver de tre udfald. Begge ja: Det er en del af jeres produkt, og bilag I gælder for det. Funktionstesten nej: ikke en del af produktet, men "fabrikanter bør vurdere de risici, der udspringer af eksistensen af en sådan databehandling, som led i deres risikovurdering". Funktionstesten ja, men ansvarstesten nej: "Fabrikanter bør behandle tredjepartsløsningen som en komponent", vurdere og afbøde risiciene ved at integrere den og "udvise fornøden omhu".

Test et: Ville dens fravær standse en funktion

Ordet er "funktioner", ikke kernefunktionalitet. Punkt 189: "Begrebet 'funktioner' i denne definition er ikke begrænset til produktets 'kernefunktionalitet' eller 'tilsigtede formål'", og det dækker "både funktioner, der direkte opfylder det tilsigtede formål med produktet med digitale elementer, som brugerne oplever det, og funktioner, der understøtter produktets samlede ydeevne". Punkt 190 nævner seks eksempler på fjernbehandling, et produkt ikke kan undvære: "(i) at sende kommandoer til en enhed; (ii) at synkronisere filer; (iii) at onboarde brugeren; (iv) konfiguration (personalisering af produktet med digitale elementer); (v) automatiseret distribution af opdateringer, herunder funktionsopdateringer og sikkerhedsrettelser; (vi) identitets- og adgangsstyring".

To præciseringer betyder noget for software. En funktion, brugeren kan udføre både på afstand og manuelt, pæren tændt fra en app eller med hånden, tæller stadig: "At udføre denne funktion på afstand anses også for en del af de funktioner, produktet med digitale elementer tilbyder" (punkt 191). Og modeksemplet er telemetri: "Fjernanalyse af telemetridata indsamlet rent statistisk eller til fremtidig produktudvikling" er ikke en funktion, produktet har brug for, og altså ikke fjerndatabehandling (punkt 192), selv om punkt 193 tilføjer, at risiciene ved de fjerne komponenter stadig hører hjemme i risikovurderingen.

Websteder får deres eget punkt, 194. Et websted, der kun bærer oplysninger om produktet, er ikke med, "selv om produktet viderestiller til det websted". Et websted, der "muliggør eller understøtter en funktion", er: "En autentificeringsportal, der udsteder legitimationsoplysninger eller tokens, som produktet med digitale elementer behøver for at fungere, ville blive anset for RDPS." For de fleste softwarevirksomheder placerer den ene sætning login-tjenesten inden i produktet.

Test to: designet og udviklet af jer, eller under jeres ansvar

Punkt 195: Software bygget i eget hus opfylder testen, og det gør software, en ekstern leverandør bygger til jer, også, men "under fabrikantens ansvar" betyder "skræddersyet til fabrikanten", tilfælde hvor "softwaren er bygget udelukkende af eller på vegne af fabrikanten på grundlag af design og specifikationer leveret af denne". At licensere en eksisterende tjeneste, "eller let ændrede udgaver af den", er ikke det.

Hvem der driver den, er uden betydning. Punkt 196: "Begrebet 'hvem der driver løsningen' er ikke en afgørende faktor, da CRA-definitionen kun henviser til design og udvikling." En backend, I har skrevet, og et hostingfirma driver, er jeres.

Punkt 197 til 200 sorterer derefter de tre skymodeller. På tredjeparts-IaaS udruller I jeres egne operativsystemer og applikationer; den software "er designet og udviklet af fabrikanten eller under dennes ansvar og kan derfor kvalificere" (punkt 198). På tredjeparts-PaaS udruller I jeres egen applikation på udbyderens kørselsmiljø; "applikationen er derfor designet og udviklet af fabrikanten" og kan kvalificere (punkt 199). En tredjeparts-SaaS-applikation integreret i jeres produkt "er derfor ikke designet og udviklet af fabrikanten" (punkt 200) og er ikke fjerndatabehandling, uanset hvilken funktion den understøtter.

Det, der falder uden for definitionen, falder ikke uden for jeres ansvar. Punkt 201: Hypervisoren under jeres IaaS, operativsystemet under jeres PaaS, tredjeparts-SaaS'en "bør betragtes som svarende til tredjepartskomponenter", hvor de påvirker produktets sikkerhed, og fabrikanten "er forpligtet til at identificere og vurdere risici knyttet til integrationen af disse elementer og til at håndtere dem ved at gennemføre de væsentlige krav på selve produktet med digitale elementer", med "en forpligtelse svarende til pligten til fornøden omhu i artikel 13(5)".

Grænsen: de moduler, jeres produkt taler med, ikke alt bagved

Det er den del, der afgør, hvor stor den tekniske dokumentation bliver. Punkt 205: Den fjerndatabehandling, der er omfattet af produktets overensstemmelsesvurdering, "bør begrænses til de softwaremoduler, der er ansvarlige for funktionaliteten i produktet med digitale elementer, og til de grænseflader, disse moduler bruger mod eksterne tjenester. Yderligere backend-systemer, der udfører efterfølgende behandling, og som produktet med digitale elementer ikke interagerer direkte med, anses ikke for RDPS." Punkt 206 beholder dem i risikovurderingen som "eksterne afhængigheder, der skal vurderes" og afbødes "gennem foranstaltninger på produktniveau".

Punkt 182 opregner, hvad definitionen aldrig skulle nå, med støtte i betragtning 11: "Interne systemer vedrørende fabrikantens egne personaleforhold, lønninger, kunderelationsstyring, CI/CD-pipelines (continuous integration/continuous delivery), distribution af sikkerhedsopdateringer til edge-lokationer bør ikke anses for RDPS", og heller ikke "systemer knyttet til revisions- og testaktiviteter såsom penetrationstest, threat hunting og red teaming". CRA dækker produktet, ikke "hele en organisations IT-infrastruktur". Det er NIS2's område, og betragtning 12 siger det.

Mobilbanktilfældet, som er de fleste softwarevirksomheders tilfælde

Afsnit 8.3.1 gennemgår en banks app med en selvhostet backend og en tredjeparts supportchat. Appen taler med en "bankgrænseflade", banken har bygget, som igen forespørger et kontostyringssystem og en hovedbog. Grænsefladen autentificerer kunden, indsender overførselsordrer og returnerer deres status; den "er nødvendig for, at appen kan udføre sine funktioner", og "er designet og udviklet under fabrikantens ansvar", så den er fjerndatabehandling og "skal derfor indgå i cybersikkerhedsrisikovurderingen og i gennemførelsen af de væsentlige krav". Kontostyringssystemet og hovedbogen er det ikke: "Appen interagerer ikke direkte med dem", og "selv om deres tilgængelighed kan være nødvendig for at fuldføre en funktion, dækker CRA kun de dele af systemet, der interagerer direkte med produktet". De forbliver eksterne afhængigheder, hvis kompromittering "kunne give en angriber mulighed for at påvirke transaktionsresultater", som skal afbødes på produktniveau, "såsom stærk autentificering af backend-grænseflader, integritetsbeskyttelse af transaktionsdata, sikre kommunikationskanaler og verifikation af de svar, appen modtager".

Supportchatten, "udviklet og drevet af en tredjepartsudbyder", er nødvendig for en funktion, men dumper ansvarstesten, så den er "ikke en RDPS" og "bør behandles som en tredjepartskomponent", isoleret fra kernefunktionerne, med fornøden omhu over for udbyderen.

Overført til en typisk B2B-SaaS med en desktop- eller mobilklient: API-gatewayen og autentificeringstjenesten, klienten kalder, er i produktet; datavarehuset tre hop bagved er en ekstern afhængighed; de indlejrede tredjeparts-widgets til analyse, chat eller betaling er komponenter. De fire andre tilfælde bekræfter mønstret: En termostats skyfunktioner på tredjeparts-IaaS er med (8.3.2), en e-læsers tredjeparts-SaaS-lager er en komponent (8.3.3), en robots synstjeneste på IaaS er med (8.3.4), og en telefons 5G-net er ingen af delene, "kun en kommunikationskanal", uden fornøden omhu over for operatøren (8.3.5).

Hvad der hører i dokumentationen, og hvad I kan genbruge

Punkt 204: Fabrikanter "bør (i) angive i den tekniske dokumentation, at deres produkt med digitale elementer har RDPS eller er afhængigt af tredjeparts fjernløsninger, og (ii) beskrive disse løsninger", og hvor én backend betjener flere produkter, angives den i hvert produkts dokumentation, og dokumentationen "kan genbruges fra én overensstemmelsesvurdering til en anden".

For de tredjepartstjenester, I er afhængige af, opregner punkt 207 de dokumentationsartefakter, der kan genbruges til støtte for jeres vurdering og fornødne omhu: dokumentation for udbyderens overholdelse af NIS2-gennemførelsesforordningen, af DORA, et certifikat under en europæisk cybersikkerhedscertificeringsordning eller "dokumentation for overensstemmelse med ISO/IEC 27017:2015 eller ISO/IEC 27001:2022". Punkt 208 tilføjer den kontraktlige side: sikkerhedsgarantier i serviceniveauaftaler, "herunder forsikringer om, at udbyderne håndterer sårbarheder tilstrækkeligt", og en større ændring hos en udbyder er ikke en væsentlig ændring af jeres produkt, men kan kræve, at jeres risikovurdering revideres.

Læst fra den anden side er punkt 207(d) også det, jeres egne kunder kan bede jer om. Er jeres produkt fjerndatabehandling for deres, er jeres ISO 27001-certifikat den artefakt, vejledningen nævner til deres dokumentation.

Afgørelsen, på seks linjer

Noter for hver fjerntjeneste, jeres produkt kalder:

  1. Tjenesten og den funktion, den understøtter, i vejledningens betydning af funktion.
  2. Test et: Ville produktet miste den funktion uden den. Telemetri og informationswebsteder: nej.
  3. Test to: Bygget af jer eller efter jeres specifikation, eller en licenseret tredjepartsapplikation. IaaS og PaaS lægger jeres kode på indersiden; SaaS lægger applikationen på komponentsiden.
  4. Udfaldet efter punkt 202: en del af produktet, en komponent, der skal vurderes med fornøden omhu, eller en ekstern afhængighed, der skal vurderes.
  5. Grænsen efter punkt 205: hvilke moduler produktet interagerer direkte med, og hvilke systemer der ligger bagved.
  6. Den artefakt, I har for hver tredjepartstjeneste, fra listen i punkt 207, og den dato, I fik den.

Den tabel er afsnittet om fjernbehandling i den tekniske dokumentation, input til den risikovurdering, artikel 13 kræver, og svaret på det andet spørgsmål i vores afgørelse om anvendelsesområde. Det er også listen over de systemer, hvis kompromittering starter anmeldelsesuret, for punkt 178 siger, at produktet, fjernbehandling inklusive, er det, artikel 14 anmelder om.

Kilder

  • Forordning (EU) 2024/2847, artikel 3(1), (2) og (4), artikel 13(2), (3) og (5), betragtning 11 og 12.
  • Europa-Kommissionen, Kommissionens vejledning om anvendelsen af forordning (EU) 2024/2847, C(2026) 5252 final af 27. juli 2026, bilag, afsnit 8, punkt 178 til 208 og anvendelsestilfælde 8.3.1 til 8.3.5.
  • Direktiv (EU) 2022/2555 (NIS2) og Kommissionens gennemførelsesforordning (EU) 2024/2690, for de skytjenester, vejledningen overlader til dem.

Dette er ikke juridisk rådgivning. Afsnit 8 er elleve sider, og de fem tilfælde er den klareste del af hele vejledningen; læs dem, før I trækker jeres egen grænse.