Den 11 september 2026 börjar en av de tidigaste operativa skyldigheterna enligt Cyber Resilience Act (CRA) att gälla för tillverkare av produkter med digitala element: aktivt utnyttjade sårbarheter och allvarliga säkerhetsincidenter måste rapporteras via den nya centrala anmälningsplattformen. Det är mer än en ny tidsfrist för regelefterlevnad. Inom några timmar måste produktidentitet, berörda marknader, teknisk bedömning och åtgärder sammanföras.
Ett digitalt produktpass eller en QR-kopplad produktsida kan hjälpa till att entydigt identifiera en enhet och senare informera användare om en uppdatering. Det är dock varken den lagstadgade rapporteringsvägen eller rätt lagringsplats för konfidentiella exploateringsdetaljer. Tillverkare bör därför redan nu skilja mellan tre dataflöden: myndighetsanmälan, offentlig produktinformation och intern uppdateringshistorik.
Det nya skälet: riktlinjer från den 27 och 31 juli
Europeiska kommissionen publicerade sina första omfattande CRA-riktlinjer den 27 juli 2026. De behandlar bland annat anmälningskrav, riskbedömning, supportperioder och väsentliga ändringar. Riktlinjerna är inte bindande, men konkretiserar med 67 exempel hur företag kan tillämpa förordningen i praktiken.
Fyra dagar senare, den 31 juli, uppdaterade ENISA sin information om Single Reporting Platform. Där finns nu det planerade förloppet, de avsedda inmatningsfälten och information om registrering. Plattformen ska vara i drift senast den 11 september 2026; enligt kommissionen pågår funktions- och säkerhetstester redan.
Tidsförskjutningen är viktig: CRA:s huvudsakliga skyldigheter gäller i princip från och med den 11 december 2027. Artikel 14 med anmälningskraven gäller dock redan från och med den 11 september 2026. Detta bekräftas både av artikel 71 i förordning (EU) 2024/2847 och av kommissionens översikt över CRA:s rapporteringsförfarande, som uppdaterades den 31 juli.
Tre datautrymmen i stället för ett överbelastat produktpass
CRA-anmälan och en offentlig produktsida har olika syften. Den som avbildar båda i samma dataset riskerar antingen att ge incidentteamet för lite information eller att exponera för många känsliga detaljer på den offentliga webben.
1. Konfidentiell anmälan till SRP, CSIRT och ENISA
Single Reporting Platform är den lagstadgade ingångskanalen. Två typer av händelser måste rapporteras: en aktivt utnyttjad sårbarhet, där det finns tillförlitliga indikationer på obehörigt utnyttjande, och en allvarlig incident som påverkar tillgängligheten, autenticiteten, integriteten eller konfidentialiteten hos data eller funktioner.
Anmälan innehåller inte bara en produktbeteckning. ENISA listar bland annat berörda medlemsstater, en första bedömning, redan vidtagna motåtgärder, möjliga användaråtgärder och informationens känslighet som fält. Senare steg kan innehålla allvarlighetsgrad, konsekvenser, angriparinformation och tekniska detaljer om säkerhetsuppdateringen. Sådan information hör inte automatiskt hemma på en fritt tillgänglig DPP-sida.
2. Offentlig produkt- och säkerhetsinformation
Det offentliga dataflödet besvarar andra frågor: Vilken produkt och version har jag? Stöds den fortfarande? Finns en säkerhetsuppdatering tillgänglig? Vad måste jag konkret göra som användare? För detta kan en stabil produktsida bakom en QR-kod eller annan databärare vara lämplig.
Den offentliga sidan bör endast visa godkänd information: berörda modell- och versionsintervall, tillgänglig säker version, installationsanvisningar, supportkontakt och publiceringstidpunkt. Exploateringsdetaljer, interna detekteringsregler, opatchade angreppsvägar och personuppgifter om incidenter ska stanna i det skyddade förfarandet. Beslutet om en offentlig varning fattas inte av QR-koden: Enligt artikel 17 i CRA kan det samordnande CSIRT informera allmänheten eller uppmana tillverkaren att göra det, om detta krävs för att förebygga eller begränsa konsekvenserna.
3. Intern uppdaterings- och evidenshistorik
Det tredje flödet är den spårbara arbetsakten. Den kopplar samman produkt-ID, hårdvaru- och programvaruversion, programvaruförteckning, tidpunkten då informationen blev känd, triagebeslut, anmälningsnivåer, godkännande av korrigering och offentlig information. Denna historik måste versionshantera ändringar i stället för att tyst skriva över äldre bedömningar.
För en DPP-verksamhet är denna skillnad central: Den offentliga vyn visar det aktuella godkända tillståndet; den interna historiken visar hur det uppstod. Den som redan underhåller produktdata händelsebaserat kan använda samma princip som för DPP-uppdateringar och webhooks: En händelse utlöser efterföljande processer, men varje mottagare får endast de fält som är avsedda för dess roll.
CRA-klockan börjar när informationen blir känd
Artikel 14 arbetar med stegvisa tidsfrister. För en aktivt utnyttjad sårbarhet krävs en tidig varning utan oskäligt dröjsmål, senast inom 24 timmar efter kännedom. Inom 72 timmar följer den mer utförliga sårbarhetsanmälan. Slutrapporten ska finnas tillgänglig senast 14 dagar efter att en korrigerande åtgärd eller begränsningsåtgärd har blivit tillgänglig.
Vid en allvarlig säkerhetsincident gäller också 24 timmar för den tidiga varningen och 72 timmar för incidentanmälan. Slutrapporten följer inom en månad efter 72-timmarsanmälan. Tidsfristerna börjar alltså inte löpa när ett CVE publiceras och inte heller vid nästa ordinarie lansering, utan från den tidpunkt då tillverkaren anses ha fått kännedom.
I praktiken rekommenderas ett tydligt förlopp:
- Registrera inkommande information från support, övervakning, forskning eller leveranskedjan med tidsstämpel.
- Koppla produkten och versionen till ett stabilt internt produkt-ID.
- Bedöm utnyttjandet respektive incidentens allvarlighetsgrad genom det ansvariga teamet.
- Skapa 24-timmarsdatauppsättningen utifrån bekräftade minimikrav och lämna in den via SRP.
- Komplettera tekniska insikter fram till 72-timmarssteget utan att förlora det ursprungliga tillståndet.
- Godkänn patch, användaråtgärd och offentlig information separat.
- Koppla samman slutrapporten och den interna historiken.
Denna kedja bör övas igenom före september. ENISA påpekar att organisationer kan automatisera sina interna processer och databaser, men att plattformen inte kommer att erbjuda något API vid lanseringen. Därför är en export- och fyrögonsprocess mer realistisk än en obekräftad direktintegration.
Ett gemensamt produkt-ID, men separata åtkomsträttigheter
Separation innebär inte att tre oberoende kopior ska underhållas. Ett bättre tillvägagångssätt är en gemensam, oföränderlig produktreferens med rollbaserade vyer.
Minst följande kopplingar bör finnas:
- internt produkt-ID samt koppling till modell, parti eller serienummer;
- hårdvaru-, firmware- och programvaruversion;
- medlemsstater där den berörda versionen har tillhandahållits;
- status för säkerhetsbedömningen och tidpunkten då informationen blev känd;
- referenser till 24- och 72-timmarsanmälan samt slutrapporten;
- godkänd användaråtgärd och säker målversion;
- publiceringsstatus för den offentliga produktsidan.
Behörigheter bör utformas på fältnivå. Incidentteamet och de CRA-ansvariga behöver den fullständiga akten. Support och försäljning behöver en godkänd handlingsanvisning. Användare ser endast den offentliga informationen. En QR-kod bör därmed helst endast innehålla en stabil produktadress; plattformen bakom avgör utifrån status och roll vilken information som levereras.
Vad tillverkare bör testa före september
Ett lämpligt testfall behöver ingen verklig sårbarhet. Välj en uppkopplad produkt, en berörd firmwareversion och tre medlemsstater. Simulera när informationen blir känd under en arbetsdag och kontrollera:
- Kan teamet inom 24 timmar bekräfta produkttäckningen och minimikraven?
- Är det tydligt vem som ska få åtkomst till SRP som ombud via EU Login?
- Går det att komplettera 72-timmarsinformationen utan att offentliggöra konfidentiella detaljer?
- Leder godkännandet av patchen till kontrollerad användarinformation på alla nödvändiga språk?
- Förblir den offentliga URL:en stabil när version och åtgärder ändras?
- Går det att se vem som godkände vilket tillstånd och när?
För den sista punkten är konsekvent, versionshanterad dataförvaltning till hjälp. qr3-artikeln om löpande DPP-uppdatering visar grundidén: Identiteten förblir stabil medan fackuppgifter uppdateras kontrollerat. I CRA-processen tillkommer ett striktare lager för konfidentialitet och godkännande.
Slutsats: Produktpasset är en distributör, inte en anmälningsinstans
De nya riktlinjerna gör septemberdatumet konkret i det operativa arbetet. Tillverkare behöver inte bygga in en konfidentiell sårbarhetsdatabas i sitt digitala produktpass. De behöver i stället en robust övergång mellan tre tydligt åtskilda områden: myndighetsanmälan, intern evidens och godkänd användarinformation.
Ett gemensamt produkt-ID håller samman dessa områden. Roller, godkännanden och versionshantering förhindrar att konfidentiella detaljer når ut eller att användare får kännedom om en tillgänglig åtgärd för sent. QR-koden förblir användbar, men medvetet ospektakulär: Den leder permanent till rätt produktkontext. Den faktiska CRA-efterlevnaden skapas i processerna bakom.
