Den 11. september 2026 begynder en af de tidligste operationelle forpligtelser i Cyber Resilience Act (CRA) for producenter af produkter med digitale elementer: Aktivt udnyttede sårbarheder og alvorlige sikkerhedshændelser skal anmeldes via den nye centrale anmeldelsesplatform. Det er mere end en ny compliancefrist. Inden for få timer skal produktidentitet, berørte markeder, teknisk vurdering og foranstaltninger samles.
Et digitalt produktpas eller en QR-forbundet produktside kan hjælpe med entydigt at identificere en enhed og senere informere brugere om en opdatering. Det er dog hverken den lovpligtige anmeldelsesvej eller det rigtige opbevaringssted for fortrolige exploitdetaljer. Producenter bør derfor allerede nu adskille tre dataspor: myndighedsanmeldelsen, den offentlige produktinformation og den interne opdateringshistorik.
Den nye anledning: Retningslinjer fra den 27. og 31. juli
Europa-Kommissionen offentliggjorde sin første omfattende CRA-retningslinje den 27. juli 2026. Den omhandler blandt andet anmeldelsespligt, risikovurdering, supportperioder og væsentlige ændringer. Retningslinjen er ikke bindende, men konkretiserer med 67 eksempler, hvordan virksomheder kan anvende forordningen i praksis.
Fire dage senere, den 31. juli, opdaterede ENISA sine oplysninger om Single Reporting Platform. Her findes nu den planlagte proces, de forventede inputfelter og oplysninger om registrering. Platformen skal være klar til drift senest den 11. september 2026; funktions- og sikkerhedstest er ifølge Kommissionen allerede i gang.
Den tidsmæssige forskydning er vigtig: CRA's vigtigste forpligtelser gælder som udgangspunkt fra den 11. december 2027. Artikel 14 om anmeldelsespligt gælder dog allerede fra den 11. september 2026. Det bekræftes både af forordningens artikel 71 (EU) 2024/2847 og af Kommissionens oversigt over CRA-anmeldelsesproceduren, opdateret den 31. juli.
Tre datarum i stedet for ét overfyldt produktpas
CRA-anmeldelsen og en offentlig produktside har forskellige formål. Hvis begge dele modelleres i ét datasæt, risikerer man enten for få oplysninger til hændelsesteamet eller for mange følsomme detaljer på det offentlige web.
1. Fortrolig anmeldelse til SRP, CSIRT og ENISA
Single Reporting Platform er den lovpligtige indgangskanal. Der skal anmeldes to hændelsestyper: en aktivt udnyttet sårbarhed, hvor der foreligger pålidelige tegn på uautoriseret udnyttelse, og en alvorlig hændelse, der påvirker tilgængeligheden, autenticiteten, integriteten eller fortroligheden af data eller funktioner.
Anmeldelsen indeholder ikke kun en produktbetegnelse. ENISA angiver blandt andet berørte medlemsstater, en indledende vurdering, allerede iværksatte modforanstaltninger, mulige brugertiltag og oplysningernes følsomhed som felter. Senere trin kan indeholde alvorlighedsgrad, påvirkning, oplysninger om angriberen og tekniske detaljer om sikkerhedsopdateringen. Sådanne oplysninger hører ikke automatisk hjemme på en frit tilgængelig DPP-side.
2. Offentlig produkt- og sikkerhedsinformation
Det offentlige dataspor besvarer andre spørgsmål: Hvilket produkt og hvilken version har jeg? Understøttes den stadig? Findes der en sikkerhedsopdatering? Hvad skal jeg konkret gøre som bruger? Til det formål kan en stabil produktside bag en QR-kode eller et andet databærerformat være hensigtsmæssig.
Den offentlige side bør kun vise godkendte oplysninger: berørte model- og versionsområder, tilgængelig sikker version, installationsvejledning, supportkontakt og offentliggørelsestidspunkt. Exploitdetaljer, interne detektionsregler, uoprettede angrebsveje eller personoplysninger om hændelsen forbliver i den beskyttede proces. Beslutningen om en offentlig advarsel træffes ikke af QR-koden: Efter artikel 17 i CRA kan det koordinerende CSIRT informere offentligheden eller anmode producenten om at gøre det, hvis det er nødvendigt for at forebygge eller begrænse hændelsen.
3. Intern opdaterings- og dokumentationshistorik
Det tredje spor er den sporbare arbejdssag. Den forbinder produkt-id, hardware- og softwareversion, softwarestykliste, tidspunktet for, hvornår man blev bekendt med forholdet, triagebeslutninger, anmeldelsestrin, godkendelse af patch og offentlig meddelelse. Denne historik skal versionsstyre ændringer i stedet for stiltiende at overskrive tidligere vurderinger.
For en DPP-drift er denne forskel central: Den offentlige visning viser den aktuelle godkendte tilstand; den interne historik dokumenterer, hvordan den er opstået. Hvis man allerede vedligeholder produktdata hændelsesbaseret, kan man anvende samme princip som ved DPP-opdateringer og webhooks: En hændelse udløser efterfølgende processer, men hver modtager får kun de felter, der er beregnet til vedkommendes rolle.
CRA-uret starter, når man får kendskab
Artikel 14 arbejder med trinvise frister. Ved en aktivt udnyttet sårbarhed kræves der uden unødig forsinkelse og senest 24 timer efter, at man er blevet bekendt med den, en tidlig advarsel. Inden for 72 timer følger den mere detaljerede sårbarhedsanmeldelse. Den afsluttende rapport skal foreligge senest 14 dage efter, at en afhjælpende eller begrænsende foranstaltning er tilgængelig.
Ved en alvorlig sikkerhedshændelse gælder ligeledes 24 timer for den tidlige advarsel og 72 timer for hændelsesanmeldelsen. Den afsluttende rapport følger inden for en måned efter 72-timersanmeldelsen. Fristerne løber altså ikke fra offentliggørelsen af en CVE og heller ikke fra den næste planlagte release, men fra det tidspunkt, hvor producenten anses for at være blevet informeret.
I praksis anbefales en klar proces:
- Registrer modtagelsen fra support, overvågning, forskning eller forsyningskæden med tidsstempel.
- Knyt produkt og version til et stabilt internt produkt-id.
- Vurder udnyttelse eller hændelsens alvorlighedsgrad i det ansvarlige team.
- Opret 24-timersdatasættet ud fra de bekræftede minimumsoplysninger, og indsend det via SRP.
- Supplér de tekniske oplysninger frem til 72-timersstadiet uden at miste det oprindelige grundlag.
- Godkend patch, brugertiltag og offentlig information separat.
- Knyt den afsluttende rapport sammen med den interne historik.
Denne kæde bør gennemspilles som en øvelse inden september. ENISA gør opmærksom på, at organisationer kan automatisere deres interne processer og databaser, men at platformen ved lanceringen ikke vil tilbyde en API. Derfor er en eksport- og fireøjneproces mere realistisk end en uprøvet direkte integration.
Ét fælles produkt-id, men adskilte adgangsrettigheder
Adskillelse betyder ikke, at man skal vedligeholde tre uforbundne kopier. Den bedre tilgang er en fælles, uforanderlig produktreference med rollebaserede visninger.
Som minimum bør følgende koblinger foreligge:
- internt produkt-id samt model-, batch- eller serienummerreference;
- hardware-, firmware- og softwareversion;
- medlemsstater, hvor den berørte variant er blevet leveret;
- status for sikkerhedsvurderingen og tidspunktet for, hvornår man blev bekendt med forholdet;
- referencer til 24- og 72-timersanmeldelsen samt den afsluttende rapport;
- godkendt brugertiltag og sikker målversion;
- offentliggørelsesstatus for den offentlige produktside.
Autorisation bør tænkes på feltniveau. Hændelsesteamet og de CRA-ansvarlige har brug for den komplette sag. Support og salg har brug for en godkendt handlingsanvisning. Brugere ser kun den offentlige meddelelse. En QR-kode bør derfor ideelt set kun transportere en stabil produktadresse; platformen bagved afgør ud fra status og rolle, hvilke oplysninger der leveres.
Hvad producenter bør teste inden september
En meningsfuld testsag kræver ikke en ægte sårbarhed. Vælg et forbundet produkt, en berørt firmwareversion og tre medlemsstater. Simulér, at man bliver bekendt med forholdet på en arbejdsdag, og kontrollér:
- Kan teamet inden for 24 timer bekræfte produktdækningen og minimumsoplysningerne?
- Er det tydeligt, hvem der skal have adgang til SRP som repræsentant via EU Login?
- Kan 72-timersoplysninger suppleres uden at offentliggøre fortrolige detaljer?
- Fører patchgodkendelsen til kontrolleret brugerinformationsom alle nødvendige sprog?
- Forbliver den offentlige URL stabil, når version og foranstaltninger ændres?
- Kan det dokumenteres, hvem der godkendte hvilken status og hvornår?
Til det sidste punkt hjælper en konsekvent, versionsstyret datavedligeholdelse. qr3-indlægget om løbende DPP-opdatering viser grundideen: Identiteten forbliver stabil, mens faglige data løbende opdateres under kontrol. I CRA-processen kommer et strengere lag af fortrolighed og godkendelse oveni.
Konklusion: Produktpasset er en distributionskanal, ikke et anmeldelsessted
De nye retningslinjer gør septemberfristen operationelt håndgribelig. Producenter behøver ikke indbygge en fortrolig sårbarhedsdatabase i deres digitale produktpas. De har snarere brug for en robust overgang mellem tre klart adskilte områder: myndighedsanmeldelse, intern dokumentation og godkendt brugerinformations.
Ét fælles produkt-id holder områderne sammen. Roller, godkendelser og versionsstyring forhindrer, at fortrolige detaljer slipper ud, eller at brugere for sent får kendskab til en tilgængelig foranstaltning. QR-koden forbliver nyttig, men bevidst uspektakulær: Den fører permanent til den rigtige produktkontekst. Den egentlige CRA-compliance skabes i processerne bagved.
