rujna 2026. za proizvođače proizvoda s digitalnim elementima počinje jedna od najranijih operativnih obveza Akta o kibernetičkoj otpornosti (CRA): aktivno iskorištavane ranjivosti i ozbiljni sigurnosni incidenti moraju se prijaviti putem nove središnje platforme za prijavljivanje. To je više od novog roka za usklađenost. U roku od nekoliko sati potrebno je objediniti identitet proizvoda, pogođena tržišta, tehničku procjenu i mjere.
Digitalna putovnica proizvoda ili stranica proizvoda povezana QR kodom može pomoći u jednoznačnoj identifikaciji uređaja i naknadnom obavještavanju korisnika o ažuriranju. No ona nije ni zakonski kanal za prijavu ni pravo mjesto za pohranu povjerljivih pojedinosti o iskorištavanju ranjivosti. Stoga bi proizvođači već sada trebali razdvojiti tri podatkovna puta: prijavu tijelima, javne informacije o proizvodu i internu povijest ažuriranja.
Novi povod: smjernice od 27. i 31. srpnja
Europska komisija objavila je 27. srpnja 2026. svoje prve sveobuhvatne smjernice za CRA. One među ostalim obuhvaćaju obveze prijavljivanja, procjenu rizika, razdoblja podrške i bitne izmjene. Smjernice nisu obvezujuće, ali kroz 67 primjera pojašnjavaju kako poduzeća mogu praktično primjenjivati uredbu.
Četiri dana poslije, 31. srpnja, ENISA je ažurirala svoje informacije o Single Reporting Platform. Ondje se sada nalaze planirani postupak, predviđena polja za unos i upute za registraciju. Platforma bi trebala biti operativna do 11. rujna 2026.; prema navodima Komisije, funkcionalna i sigurnosna testiranja već su u tijeku.
Vremensko stupnjevanje je važno: glavne obveze iz CRA-a u načelu se primjenjuju od 11. prosinca 2027. Međutim, članak 14. o obvezama prijavljivanja primjenjuje se već od 11. rujna 2026. To potvrđuju članak 71. Uredbe (EU) 2024/2847 i 31. srpnja ažurirani pregled Komisije o postupku prijavljivanja prema CRA-u.
Tri podatkovna prostora umjesto jedne preopterećene putovnice proizvoda
Prijava prema CRA-u i javna stranica proizvoda imaju različite ciljeve. Tko ih prikazuje u jednom skupu podataka, riskira ili premalo informacija za tim za incidente ili previše osjetljivih pojedinosti na javnom webu.
1. Povjerljiva prijava SRP-u, CSIRT-u i ENISA-i
Single Reporting Platform zakonski je ulazni kanal. Prijaviti se moraju dvije vrste događaja: aktivno iskorištavana ranjivost za koju postoje pouzdane naznake neovlaštenog iskorištavanja te ozbiljan incident koji ugrožava dostupnost, autentičnost, cjelovitost ili povjerljivost podataka ili funkcija.
Prijava ne sadrži samo naziv proizvoda. ENISA među poljima navodi pogođene države članice, početnu procjenu, već poduzete protumjere, moguće mjere za korisnike i osjetljivost informacija. Kasnije faze mogu sadržavati razinu ozbiljnosti, učinke, informacije o napadačima i tehničke pojedinosti o sigurnosnom ažuriranju. Takve informacije ne pripadaju automatski na slobodno dostupnu DPP stranicu.
2. Javne informacije o proizvodu i sigurnosti
Javni podatkovni put odgovara na druga pitanja: Koji proizvod i koju verziju imam? Je li još podržana? Je li dostupno sigurnosno ažuriranje? Što kao korisnik konkretno moram učiniti? Za to može biti korisna stabilna stranica proizvoda iza QR koda ili drugog nosača podataka.
Javna stranica trebala bi prikazivati samo odobrene informacije: pogođene raspone modela i verzija, dostupnu sigurnu verziju, upute za instalaciju, kontakt za podršku i vrijeme objave. Pojedinosti o iskorištavanju ranjivosti, interna pravila otkrivanja, neispravljeni napadački putevi ili osobni podaci o incidentu ostaju u zaštićenom postupku. Odluku o javnom upozorenju ne donosi QR kod: prema članku 17. CRA-a koordinirajući CSIRT može obavijestiti javnost ili zatražiti od proizvođača da to učini ako je to potrebno za prevenciju ili ograničavanje posljedica.
3. Interna povijest ažuriranja i dokaza
Treći put je sljedivi radni dosje. On povezuje ID proizvoda, verziju hardvera i softvera, popis sastavnica softvera, trenutak saznanja, odluke o trijaži, faze prijavljivanja, odobrenje zakrpe i javnu obavijest. Ta povijest mora verzionirati izmjene umjesto da neprimjetno prepisuje starije procjene.
Za rad DPP ovo je razlikovanje ključno: javni prikaz pokazuje trenutačno odobreno stanje, a interna povijest dokazuje kako je ono nastalo. Tko već održava podatke o proizvodu na temelju događaja, može primijeniti isto načelo kao kod ažuriranja DPP i webhookova: događaj pokreće naknadne procese, ali svaki primatelj dobiva samo polja predviđena za njegovu ulogu.
CRA sat počinje sa saznanjem
Članak 14. predviđa stupnjevane rokove. Za aktivno iskorištavanu ranjivost potrebno je, bez neopravdanog odgađanja, a najkasnije u roku od 24 sata od saznanja, poslati rano upozorenje. U roku od 72 sata slijedi detaljnija prijava ranjivosti. Završno izvješće dostupno je najkasnije 14 dana nakon što je korektivna mjera ili mjera ublažavanja spremna.
Za ozbiljan sigurnosni incident također vrijedi rok od 24 sata za rano upozorenje i 72 sata za prijavu incidenta. Završno izvješće slijedi u roku od mjesec dana nakon 72-satne prijave. Rokovi, dakle, ne počinju objavom CVE-a ni sljedećim redovitim izdanjem, nego trenutkom kada se smatra da je proizvođač obaviješten.
Za praksu se preporučuje jasan tijek:
- Evidentirati zaprimanje iz podrške, nadzora, istraživanja ili opskrbnog lanca s vremenskom oznakom.
- Povezati proizvod i verziju sa stabilnim internim ID-om proizvoda.
- Nadležni tim treba procijeniti iskorištavanje odnosno ozbiljnost incidenta.
- Izraditi 24-satni skup podataka na temelju potvrđenih minimalnih podataka i podnijeti ga putem SRP-a.
- Dopuniti tehničke nalaze do 72-satne faze bez gubitka izvornog stanja.
- Zasebno odobriti zakrpu, mjeru za korisnike i javne informacije.
- Povezati završno izvješće s internom poviješću.
Taj bi lanac trebalo uvježbati prije rujna. ENISA ističe da organizacije mogu automatizirati svoje interne postupke i baze podataka, ali platforma pri pokretanju neće nuditi API. Stoga su postupak izvoza i provjera po načelu četiri oka realističniji od neprovjerene izravne integracije.
Zajednički ID proizvoda, ali odvojena prava pristupa
Razdvajanje ne znači održavati tri nepovezane kopije. Bolji je pristup zajednička, nepromjenjiva referenca proizvoda s prikazima ovisnima o ulozi.
Najmanje bi trebala postojati sljedeća povezivanja:
- interni ID proizvoda te poveznica na model, seriju ili serijski broj;
- verzija hardvera, firmvera i softvera;
- države članice u kojima je pogođena izvedba stavljena na raspolaganje;
- status sigurnosne procjene i trenutak saznanja;
- reference na 24-satnu i 72-satnu prijavu te završno izvješće;
- odobrena mjera za korisnike i sigurna ciljna verzija;
- status objave javne stranice proizvoda.
Autorizaciju treba promatrati po poljima. Tim za incidente i osobe odgovorne za CRA trebaju potpuni dosje. Podrška i prodaja trebaju odobrene upute za postupanje. Korisnici vide samo javnu obavijest. QR kod pritom bi idealno trebao sadržavati samo stabilnu adresu proizvoda; platforma iza njega na temelju statusa i uloge odlučuje koje se informacije isporučuju.
Što bi proizvođači trebali testirati do rujna
Smislen testni slučaj ne zahtijeva stvarnu ranjivost. Odaberite povezani proizvod, pogođenu verziju firmvera i tri države članice. Simulirajte saznanje tijekom radnog dana i provjerite:
- Može li tim u roku od 24 sata potvrditi obuhvat proizvoda i minimalne podatke?
- Je li jasno tko bi kao predstavnik trebao pristupiti SRP-u putem EU Logina?
- Mogu li se 72-satne informacije dopuniti bez javnog objavljivanja povjerljivih pojedinosti?
- Dovodi li odobrenje zakrpe do provjerenih informacija za korisnike na svim potrebnim jezicima?
- Ostaje li javni URL stabilan kada se promijene verzija i mjere?
- Može li se pratiti tko je, kada i koje stanje odobrio?
Za posljednju točku pomaže dosljedno, verzionirano održavanje podataka. Prilog qr3-a o kontinuiranom ažuriranju DPP pokazuje osnovnu ideju: identitet ostaje stabilan, dok se stručni podaci kontrolirano nadopunjuju. U procesu CRA-a dodaje se stroži sloj povjerljivosti i odobravanja.
Zaključak: Putovnica proizvoda je distribucijski kanal, a ne mjesto prijave
Nove smjernice čine rujanski rok operativno konkretnim. Proizvođači ne moraju ugrađivati povjerljivu bazu podataka o ranjivostima u svoju digitalnu putovnicu proizvoda. Umjesto toga trebaju pouzdan prijelaz između triju jasno odvojenih područja: prijave tijelima, internih dokaza i odobrenih informacija za korisnike.
Zajednički ID proizvoda povezuje ta područja. Uloge, odobrenja i verzioniranje sprječavaju da povjerljive pojedinosti dospiju van ili da korisnici prekasno saznaju za dostupnu mjeru. QR kod pritom ostaje koristan, ali namjerno nenametljiv: trajno vodi do odgovarajućeg konteksta proizvoda. Stvarna usklađenost s CRA-om nastaje u procesima koji stoje iza toga.
