septembra 2026 se za proizvajalce izdelkov z digitalnimi elementi začne ena prvih operativnih obveznosti akta o kibernetski odpornosti (CRA): o aktivno izkoriščanih ranljivostih in resnih varnostnih incidentih bo treba poročati prek nove centralne platforme za poročanje. To je več kot nov rok za skladnost. V nekaj urah bo treba združiti identiteto izdelka, prizadete trge, tehnično oceno in ukrepe.
Digitalni potni list izdelka ali stran izdelka, povezana s kodo QR, lahko pomaga nedvoumno določiti napravo in uporabnike pozneje obvestiti o posodobitvi. Vendar ni niti zakonsko predpisana pot za poročanje niti pravo mesto za hrambo zaupnih podrobnosti o izkoriščanju ranljivosti. Proizvajalci bi morali zato že zdaj ločiti tri podatkovne poti: poročanje organom, javne informacije o izdelku in interno zgodovino posodobitev.
Novi povod: smernice z dne 27. in 31. julija
Evropska komisija je objavila svoje prve celovite smernice CRA z dne 27. julija 2026. Obravnavajo med drugim obveznosti poročanja, ocenjevanje tveganj, obdobja podpore in bistvene spremembe. Smernice niso zavezujoče, vendar s 67 primeri konkretizirajo, kako lahko podjetja uredbo uporabljajo v praksi.
Štiri dni pozneje, 31. julija, je ENISA posodobila svoje informacije o enotni platformi za poročanje. Na voljo so zdaj načrtovani potek, predvidena vnosna polja in navodila za registracijo. Platforma naj bi bila do 11. septembra 2026 pripravljena za delovanje; po navedbah Komisije funkcionalni in varnostni preizkusi že potekajo.
Časovno zaporedje je pomembno: glavne obveznosti CRA se načeloma uporabljajo od 11. decembra 2027. Člen 14 z obveznostmi poročanja pa se uporablja že od 11. septembra 2026. To potrjujeta tako člen 71 Uredbe (EU) 2024/2847 kot tudi 31. julija posodobljeni pregled postopka poročanja CRA Komisije.
Trije podatkovni prostori namesto preobremenjenega potnega lista izdelka
Poročanje CRA in javna stran izdelka imata različna cilja. Kdor oboje prikaže v enem samem naboru podatkov, tvega bodisi premalo informacij za skupino za obravnavo incidentov bodisi preveč občutljivih podrobnosti na javnem spletu.
1. Zaupno poročanje platformi SRP, skupini CSIRT in ENISA
Enotna platforma za poročanje je zakonsko predpisani vhodni kanal. Poročati je treba o dveh vrstah dogodkov: o aktivno izkoriščani ranljivosti, za katero obstajajo zanesljivi znaki nepooblaščenega izkoriščanja, in o resnem incidentu, ki vpliva na razpoložljivost, pristnost, celovitost ali zaupnost podatkov oziroma funkcij.
Poročilo ne vsebuje le oznake izdelka. ENISA med drugim kot polja navaja prizadete države članice, prvo oceno, že izvedene protiukrepe, morebitne ukrepe uporabnikov in občutljivost informacij. Poznejše stopnje lahko vključujejo stopnjo resnosti, vplive, informacije o napadalcu in tehnične podrobnosti o varnostni posodobitvi. Takšne informacije ne sodijo samodejno na prosto dostopno DPP-stran.
2. Javne informacije o izdelku in varnosti
Javna podatkovna pot odgovarja na druga vprašanja: Kateri izdelek in različico imam? Ali je še podprt? Ali je na voljo varnostna posodobitev? Kaj moram kot uporabnik konkretno storiti? Za to je lahko smiselna stabilna stran izdelka za kodo QR ali drugim nosilcem podatkov.
Javna stran naj prikazuje le odobrene informacije: prizadeta območja modelov in različic, razpoložljivo varno različico, navodila za namestitev, kontakt za podporo in čas objave. Podrobnosti o izkoriščanju, interna pravila zaznavanja, nezakrpanih poteh napada ali osebni podatki o incidentu ostanejo v zaščitenem postopku. Odločitev o javnem opozorilu ni v pristojnosti kode QR: v skladu s členom 17 CRA lahko usklajevalni CSIRT obvesti javnost ali k temu pozove proizvajalca, če je to potrebno za preprečevanje ali omejevanje posledic.
3. Interna zgodovina posodobitev in dokazov
Tretja pot je sledljiv delovni zapis. Povezuje ID izdelka, različico strojne in programske opreme, seznam komponent programske opreme, čas seznanitve, odločitve triaže, stopnje poročanja, odobritev popravka in javno obvestilo. V tej zgodovini je treba spremembe različicno beležiti, namesto da se stare ocene tiho prepišejo.
Za DPP-delovanje je ta razlika ključna: javni prikaz kaže trenutno odobreno stanje, interna zgodovina pa dokazuje, kako je nastalo. Kdor podatke o izdelkih že vodi na podlagi dogodkov, lahko uporabi isto načelo kot pri DPP-posodobitvah in spletnih kavkah: dogodek sproži nadaljnje procese, vendar vsak prejemnik dobi le polja, predvidena za njegovo vlogo.
Ura CRA se začne z vedenjem
Člen 14 določa stopenjske roke. Pri aktivno izkoriščani ranljivosti je treba brez neupravičenega odlašanja, najpozneje v 24 urah po seznanitvi, poslati zgodnje opozorilo. V 72 urah sledi podrobnejše poročilo o ranljivosti. Končno poročilo mora biti na voljo najpozneje 14 dni po tem, ko je na voljo ukrep za odpravo ali zmanjšanje posledic.
Pri resnem varnostnem incidentu prav tako veljata 24 ur za zgodnje opozorilo in 72 ur za poročilo o incidentu. Končno poročilo sledi v enem mesecu po 72-urnem poročilu. Roki torej ne začnejo teči z objavo CVE in ne z naslednjo redno izdajo, temveč od trenutka, ko se šteje, da je bil proizvajalec obveščen.
Za prakso je priporočljiv jasen potek:
- Vhodne informacije iz podpore, spremljanja, raziskav ali dobavne verige evidentirati s časovnim žigom.
- Izdelek in različico povezati s stabilnim internim ID-jem izdelka.
- Pristojna skupina oceni izkoriščanje oziroma resnost incidenta.
- Iz potrjenih minimalnih podatkov ustvariti 24-urni nabor in ga predložiti prek SRP.
- Tehnične ugotovitve dopolniti do 72-urne stopnje, ne da bi izgubili prvotno stanje.
- Ločeno odobriti popravek, ukrep uporabnika in javne informacije.
- Povezati končno poročilo in interno zgodovino.
To zaporedje je treba pred septembrom preizkusiti v vaji. ENISA opozarja, da lahko organizacije avtomatizirajo interne postopke in podatkovne zbirke, vendar platforma ob začetku delovanja ne bo ponujala API-ja. Zato je izvozni postopek z dvema pregledovalcema realnejši od neposredne, nepreverjene integracije.
Skupni ID izdelka, vendar ločene pravice dostopa
Ločevanje ne pomeni vzdrževanja treh nepovezanih kopij. Boljši pristop je skupna, nespremenljiva referenca izdelka z vpogledi, odvisnimi od vloge.
Na voljo bi morale biti vsaj te povezave:
- interni ID izdelka ter povezava z modelom, serijo ali serijsko številko;
- različica strojne programske opreme, vdelane programske opreme in programske opreme;
- države članice, v katerih je bila prizadeta izvedba dana na voljo;
- stanje varnostne ocene in čas seznanitve;
- sklici na 24- in 72-urno poročilo ter končno poročilo;
- odobreni ukrep uporabnika in varna ciljna različica;
- stanje objave javne strani izdelka.
Avtorizacijo je treba obravnavati po posameznih poljih. Skupina za incidente in odgovorni za CRA potrebujejo celoten zapis. Podpora in prodaja potrebujeta odobrena navodila za ukrepanje. Uporabniki vidijo le javno obvestilo. Koda QR pri tem idealno vsebuje le stabilen naslov izdelka; platforma v ozadju glede na stanje in vlogo odloči, katere informacije bo posredovala.
Kaj naj proizvajalci preizkusijo do septembra
Za smiseln testni primer ni potrebna resnična ranljivost. Izberite povezani izdelek, prizadeto različico vdelane programske opreme in tri države članice. Simulirajte seznanitev na delovni dan in preverite:
- Ali lahko skupina v 24 urah potrdi zajetje izdelkov in minimalne podatke?
- Ali je jasno, kdo naj kot predstavnik prek EU Login dostopa do SRP?
- Ali je mogoče dopolniti 72-urne informacije, ne da bi zaupne podrobnosti postale javne?
- Ali odobritev popravka vodi do preverjenih informacij za uporabnike v vseh zahtevanih jezikih?
- Ali javni URL ostane stabilen, ko se spremenijo različica in ukrepi?
- Ali je sledljivo, kdo je katero stanje odobril in kdaj?
Pri zadnji točki pomaga dosledno, različicno vodenje podatkov. Prispevek qr3 o stalnem DPP-posodabljanju prikazuje osnovno idejo: identiteta ostane stabilna, medtem ko se strokovni podatki nadzorovano posodabljajo. V postopku CRA se temu pridruži strožja raven zaupnosti in odobritev.
Sklep: potni list izdelka je razdelilnik, ne mesto za poročanje
Nove smernice naredijo septembrski rok operativno oprijemljiv. Proizvajalcem v digitalni potni list izdelka ni treba vgraditi zaupne zbirke podatkov o ranljivostih. Potrebujejo predvsem zanesljiv prehod med tremi jasno ločenimi področji: poročanjem organom, internimi dokazi in odobrenimi informacijami za uporabnike.
Skupni ID izdelka ta področja povezuje. Vloge, odobritve in različice preprečujejo, da bi zaupne podrobnosti prišle v javnost ali da bi uporabniki prepozno izvedeli za razpoložljiv ukrep. Koda QR pri tem ostaja uporabna, vendar namenoma neopazna: trajno vodi v pravi kontekst izdelka. Dejanska skladnost s CRA nastaja v procesih v ozadju.
