Cyber Resilience

Oplysninger og anvisninger til brugeren efter bilag II, når softwaren ikke har en manual

Oplysninger og anvisninger til brugeren efter bilag II, når softwaren ikke har en manual

Bilag II i forordning (EU) 2024/2847 lister ni punkter, som skal ledsage et produkt med digitale elementer. Mange softwareprodukter har ingen samlet manual, så fra 11. december 2027 er opgaven at kunne pege på, hvor hvert af de ni punkter står.

Brugeroplysninger efter CRA bilag II ligger i et typisk softwarehus i mange kanaler. Noget står i installationsguiden, noget i hjælpeteksterne, noget på produktsiden og noget i supportaftalen. Artiklen viser, hvordan en gennemgang holder de spredte oplysninger op mod listen i bilaget.

De ni punkter

Bilag II kræver, at brugeren får:

  1. Hvem fabrikanten er, med navn, firmanavn eller varemærke, en postadresse, en e-mail eller en anden digital kontaktvej og et websted, hvis der er et.
  2. Det centrale kontaktpunkt til indberetning af sårbarheder og stedet, hvor politikken for koordineret offentliggørelse findes.
  3. Produktets navn og type og det, der gør det entydigt identificerbart.
  4. Formålet med produktet, det sikkerhedsmiljø, det er tænkt til, og dets væsentlige funktioner og sikkerhedsegenskaber.
  5. Situationer, også fejlbrug, som er kendte eller kan forudses, og som kan give betydelige cybersikkerhedsrisici.
  6. Adressen på nettet, hvor erklæringen om overensstemmelse ligger, hvis der er en.
  7. Hvilken teknisk sikkerhedsstøtte der ydes, og hvornår supportperioden slutter.
  8. Detaljerede anvisninger eller en internetadresse til dem om sikker ibrugtagning og brug, om hvordan ændringer kan påvirke datasikkerheden, om installation af sikkerhedsopdateringer, om sikker nedlukning og fjernelse af brugerdata, om hvordan automatisk installation af sikkerhedsopdateringer slås fra, og oplysninger til integratorer.
  9. Hvor komponentlisten kan findes, hvis fabrikanten har valgt at give brugeren adgang til den.

Krav til formen

Artikel 13, stk. 18, siger, at oplysningerne gives på papir eller elektronisk, på et sprog brugere og myndigheder let forstår, og at de skal være klare, forståelige og læselige. Ligger de på nettet, gælder en frist på ti år efter omsætningen for, hvor længe de skal være at finde. Er supportperioden længere, er det den, der tæller.

Bilaget kræver, at produktet ledsages af oplysningerne. Det kræver ikke en samlet manual. At oplysningerne derfor må ligge spredt i hjælpetekst, installationsvejledning og på et websted, er vores tolkning af “i papirform eller i elektronisk form”. Forordningen siger det ikke med de ord, og der findes endnu ingen vejledning eller praksis, der bekræfter det.

Tre punkter, som andre artikler i forordningen skærper

Kontaktpunktet. Efter artikel 13, stk. 16 og 17, skal fabrikantens kontaktoplysninger og det centrale kontaktpunkt også fremgå af bilag II-oplysningerne. Kontaktpunktet skal lade brugeren vælge kommunikationsmiddel og må ikke begrænse midlerne til automatiserede værktøjer. En formular med en chatrobot som eneste vej holder altså ikke.

Identifikationen. Artikel 13, stk. 15, kræver et type-, parti- eller serienummer eller anden identifikation. For software er versionsnummeret det nærliggende, men det skal kunne findes af brugeren, fx i programmets om-dialog.

Slutdatoen. Artikel 13, stk. 19, kræver, at slutdatoen for supportperioden, mindst måned og år, angives klart på købstidspunktet. Hvor det er teknisk muligt, vises en meddelelse, når supporten er slut. Datoen i bilag II er derfor også et salgsspørgsmål.

Sådan prøver en gennemgang de spredte oplysninger

En almindelig fremgangsmåde er at lave et kort over kilderne. Det er praksis og ikke et krav. Gennemgangen tager de ni punkter og skriver for hvert, hvor oplysningen står i dag, i hvilken version, og om en almindelig bruger kan finde den uden at kontakte support.

Typiske huller i et softwareprodukt er punkt 5 og punkt 8. Fejlanvendelse beskrives sjældent, fordi produktteksterne er skrevet til at sælge. Anvisningen om at slå automatiske sikkerhedsopdateringer fra mangler ofte, selv om funktionen findes. Oplysningerne til integratorer står måske i en udviklerportal, der kræver login, og så er spørgsmålet, om de ledsager produktet.

Et tænkt eksempel. Et softwarehus har en installationsguide som PDF, en hjælpeside på nettet og en side med sikkerhedsoplysninger. Guiden nævner versionen, hjælpesiden forklarer opdateringer, og sikkerhedssiden har kontaktpunktet. Ingen af dem nævner slutdatoen for supporten eller fjernelse af brugerdata. Kortet viser hullerne på en side, og rettelsen er en tekst på den side, der i forvejen har flest af punkterne.

Ti år på nettet

Kravet om ti års tilgængelighed betyder, at oplysningerne for en gammel version skal kunne findes, også når produktsiden for længst handler om en ny. Det taler for et arkiv pr. version med faste adresser. Hvordan arkivet indrettes, er ikke reguleret.

Hvad det kræver, og hvad det koster at lade være

Det kræver, at nogen samler oplysningerne ét sted på papiret, selv om de bliver liggende flere steder i praksis. Produktchefen kender formålet, udviklingen kender opdateringsmekanismen, og supporten kender slutdatoen. Arbejdet er størst første gang og derefter ved hver ny version.

Mangler oplysningerne, kan brugeren ikke bruge produktet sikkert, og myndigheden kan konstatere, at artikel 13, stk. 18, ikke er opfyldt. Huller i bilag II ses af enhver, der køber en licens, også af en myndighed.

Det skal I lade være med

  • At lade chatrobotten være eneste kontaktvej · artikel 13, stk. 17, forbyder at begrænse kontakten til automatiserede værktøjer.
  • At slette gamle versioners oplysninger fra nettet · de skal kunne findes i mindst ti år eller supportperioden.
  • At skjule integratoroplysninger bag et login, uden at overveje det · efter vores læsning af punkt 8 skal brugeren kunne nå dem.

Det skal auditten kunne vise

  • ☐ Et kort over de ni punkter med kilde, adresse og version for hvert.
  • ☐ Et kontaktpunkt med mere end én kommunikationsvej.
  • ☐ Slutdatoen for supporten synlig ved købet.
  • ☐ Anvisninger om at slå automatiske sikkerhedsopdateringer fra.
  • ☐ Et arkiv, der viser oplysningerne for ældre versioner.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Skriv de ni punkter op i et regneark, og udfyld for jeres vigtigste produkt, hvor hver oplysning står i dag.

Læs også: Politik for koordineret offentliggørelse og det centrale kontaktpunkt · Automatiske sikkerhedsopdateringer som standard

→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal jeres software gennemgås?

Skriv kort, hvilket produkt det drejer sig om, og hvad der sætter det i gang. Så vender jeg tilbage. Gennemgangen er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.