septembril 2026 algab digitaalsete elementidega toodete tootjatele üks Cyber Resilience Acti (CRA) varasemaid praktilisi kohustusi: aktiivselt ära kasutatud haavatavustest ja rasketest turvaintsidentidest tuleb teatada uue keskse teavitusplatvormi kaudu. See on rohkem kui uus vastavustähtpäev. Mõne tunni jooksul tuleb kokku viia toote identiteet, mõjutatud turud, tehniline hinnang ja meetmed.
Digitaalne tootepass või QR-koodiga seotud tooteleht võib aidata seadme üheselt tuvastada ja teavitada kasutajaid hiljem uuendusest. See ei ole aga ei seaduses ette nähtud teavituskanal ega õige koht konfidentsiaalsete ärakasutamise üksikasjade hoidmiseks. Seetõttu peaksid tootjad juba praegu eraldama kolm andmevoogu: ametiasutustele esitatava teate, avaliku tooteteabe ja sisemise uuenduste ajaloo.
Uus ajend: 27. ja 31. juuli suunised
Euroopa Komisjon avaldas 27. juulil 2026 oma esimese põhjaliku CRA suunise. See käsitleb muu hulgas teatamiskohustusi, riskihindamist, tugiperioode ja olulisi muudatusi. Suunis ei ole siduv, kuid täpsustab 67 näite abil, kuidas ettevõtted saavad määrust praktikas kohaldada.
Neli päeva hiljem, 31. juulil, uuendas ENISA oma teavet ühtse teavitusplatvormi kohta. Seal on nüüd kirjeldatud kavandatud menetlust, ettenähtud sisestusvälju ja registreerimisjuhiseid. Platvorm peaks 11. septembriks 2026 töövalmis olema; komisjoni andmetel toimuvad funktsiooni- ja turvatestid juba.
Ajastus on oluline: CRA põhikohustused hakkavad üldjuhul kehtima 11. detsembril 2027. Teatamiskohustusi käsitlev artikkel 14 kehtib aga juba alates 11. septembrist 2026. Seda kinnitavad nii määruse (EL) 2024/2847 artikkel 71 kui ka 31. juulil uuendatud komisjoni ülevaade CRA teavitamismenetlusest.
Kolm andmeruumi ülekoormatud tootepassi asemel
CRA-teatel ja avalikul tootelehel on erinevad eesmärgid. Kui mõlemad esitada ühes andmekogumis, võib tulemuseks olla kas liiga vähe teavet intsidendimeeskonnale või liiga palju tundlikke üksikasju avalikus veebis.
1. Konfidentsiaalne teade SRP-le, CSIRT-ile ja ENISA-le
Ühtne teavitusplatvorm on seadusega ette nähtud sisendkanal. Teatada tuleb kahest sündmusetüübist: aktiivselt ära kasutatud haavatavusest, mille puhul on usaldusväärseid viiteid volitamata ärakasutamisele, ning raskest intsidendist, mis kahjustab andmete või funktsioonide kättesaadavust, autentsust, terviklust või konfidentsiaalsust.
Teade ei sisalda üksnes tootenimetust. ENISA loetleb muu hulgas mõjutatud liikmesriigid, esmase hinnangu, juba rakendatud vastumeetmed, võimalikud kasutajameetmed ja teabe tundlikkuse väljadena. Hilisemad etapid võivad sisaldada raskusastet, mõju, ründaja teavet ja turvauuenduse tehnilisi üksikasju. Selline teave ei kuulu automaatselt vabalt juurdepääsetavale DPP-lehele.
2. Avalik toote- ja turvateave
Avalik andmevoog vastab teistele küsimustele: Milline toode ja versioon mul on? Kas seda veel toetatakse? Kas turvauuendus on saadaval? Mida pean kasutajana konkreetselt tegema? Selleks võib sobida QR-koodi või muu andmekandja taga asuv stabiilne tooteleht.
Avalikul lehel tuleks näidata ainult heakskiidetud teavet: mõjutatud mudeli- ja versioonivahemikud, saadaval olev turvaline versioon, paigaldusjuhised, tugikontakt ja avaldamise aeg. Ärakasutamise üksikasjad, sisemised tuvastusreeglid, paikamata ründeteed või isikuandmeid sisaldavad intsidendiandmed jäävad kaitstud menetlusse. Avaliku hoiatuse otsus ei sõltu QR-koodist: CRA artikli 17 kohaselt võib koordineeriv CSIRT avalikkust teavitada või nõuda seda tootjalt, kui see on ennetuseks või leviku tõkestamiseks vajalik.
3. Sisemine uuenduste ja tõendite ajalugu
Kolmas voog on jälgitav töötoimik. See seob toote ID, riist- ja tarkvaraversiooni, tarkvaraosade loendi, teadasaamise aja, triaažiotsused, teavitusetapid, paiga heakskiidu ja avaliku teate. See ajalugu peab muudatused versioonidena talletama, mitte varasemaid hinnanguid vaikselt üle kirjutama.
DPP-käitamisel on see erinevus keskse tähtsusega: avalik vaade näitab hetkel heakskiidetud olekut; sisemine ajalugu tõendab, kuidas selleni jõuti. Kes haldab tooteandmeid juba sündmuspõhiselt, saab kasutada sama põhimõtet nagu DPP-uuenduste ja veebihaakide puhul: sündmus käivitab järelprotsessid, kuid iga saaja saab üksnes tema rolli jaoks ette nähtud väljad.
CRA kell hakkab käima teadasaamisest
Artikkel 14 näeb ette astmelised tähtajad. Aktiivselt ära kasutatud haavatavuse korral tuleb põhjendamatu viivituseta, hiljemalt 24 tunni jooksul pärast teadasaamist, esitada eelhoiatus. 72 tunni jooksul järgneb üksikasjalikum haavatavusteade. Lõpparuanne peab olema kättesaadav hiljemalt 14 päeva pärast seda, kui parandus- või leevendusmeede on olemas.
Ka raske turvaintsidendi korral kehtib eelhoiatuse esitamiseks 24 tundi ja intsidenditeate esitamiseks 72 tundi. Lõpparuanne tuleb esitada ühe kuu jooksul pärast 72 tunni jooksul esitatud teadet. Tähtajad ei hakka seega kulgema CVE avaldamisest ega järgmisest tavapärasest väljalaskest, vaid hetkest, mil tootjat loetakse teavitatuks.
Praktikas on soovitatav selge menetlus:
- Salvestage tugiteenusest, seirest, uuringutest või tarneahelast saabunud teave koos ajatempliga.
- Siduge toode ja versioon stabiilse sisemise toote ID-ga.
- Hinnake ärakasutamist või intsidendi raskusastet vastutava meeskonna poolt.
- Koostage kinnitatud miinimumandmetest 24 tunni andmekogum ja esitage see SRP kaudu.
- Täiendage tehnilisi teadmisi kuni 72 tunni etapini, kaotamata algset seisu.
- Kinnitage paiga, kasutajameetme ja avaliku teabe avaldamine eraldi.
- Siduge lõpparuanne ja sisemine ajalugu omavahel.
See ahel tuleks enne septembrit harjutusena läbi mängida. ENISA juhib tähelepanu, et organisatsioonid võivad oma sisemisi menetlusi ja andmebaase automatiseerida, kuid platvorm ei paku käivitamisel API-t. Seetõttu on eksportimise ja nelja silma põhimõttel toimuv menetlus realistlikum kui kontrollimata otseintegratsioon.
Ühine toote ID, kuid eraldatud juurdepääsuõigused
Eraldamine ei tähenda kolme omavahel sidumata koopia haldamist. Parem lähenemisviis on ühine muutmatu tootereferents koos rollipõhiste vaadetega.
Vähemalt järgmised seosed peaksid olemas olema:
- sisemine toote ID ning mudeli-, partii- või seerianumber;
- riistvara-, püsivara- ja tarkvaraversioon;
- liikmesriigid, kus mõjutatud teostus kättesaadavaks tehti;
- turvahinnangu olek ja teadasaamise aeg;
- viited 24 ja 72 tunni teadetele ning lõpparuandele;
- heakskiidetud kasutajameede ja turvaline sihtversioon;
- avaliku tootelehe avaldamise olek.
Volitusi tuleks käsitleda väljade kaupa. Intsidendimeeskond ja CRA eest vastutavad isikud vajavad täielikku toimikut. Tugi ja müük vajavad heakskiidetud tegevusjuhist. Kasutajad näevad ainult avalikku teadet. QR-kood peaks ideaalis edastama üksnes stabiilse toot aadressi; selle taga olev platvorm otsustab oleku ja rolli põhjal, milline teave väljastatakse.
Mida peaksid tootjad septembriks testima
Sobiv testjuhtum ei vaja tegelikku haavatavust. Valige võrku ühendatud toode, mõjutatud püsivaraversioon ja kolm liikmesriiki. Simuleerige teadasaamist tööpäeval ja kontrollige järgmist:
- Kas meeskond suudab 24 tunni jooksul kinnitada toote katvuse ja miinimumandmed?
- Kas on selge, kes peaks esindajana EU Logini kaudu SRP-le juurde pääsema?
- Kas 72 tunni teavet saab täiendada nii, et konfidentsiaalsed üksikasjad ei muutuks avalikuks?
- Kas paiga heakskiit viib kontrollitud kasutajateavituseni kõigis nõutavates keeltes?
- Kas avalik URL jääb stabiilseks, kui versioon ja meetmed muutuvad?
- Kas on jälgitav, kes millise seisu ja millal heaks kiitis?
Viimase punkti puhul aitab järjepidev versioonipõhine andmehaldus. qr3-i artikkel pideva DPP-uuendamise kohta näitab põhiideed: identiteet jääb stabiilseks, samal ajal kui erialaseid andmeid täiendatakse kontrollitult. CRA protsessis lisandub sellele rangem konfidentsiaalsuse ja heakskiitmise kiht.
Kokkuvõte: tootepass on jaotur, mitte teavituskoht
Uued suunised muudavad septembrikuu tähtaja praktiliselt hoomatavaks. Tootjad ei pea oma digitaalsetesse tootepassidesse lisama konfidentsiaalset haavatavuste andmebaasi. Nad vajavad hoopis töökindlat ühendust kolme selgelt eraldatud valdkonna vahel: ametiasutustele esitatav teade, sisemised tõendid ja heakskiidetud kasutajateave.
Ühine toote ID hoiab need valdkonnad koos. Rollid, heakskiidud ja versioonihaldus takistavad konfidentsiaalsete üksikasjade jõudmist väljapoole või seda, et kasutajad kuuleksid kättesaadavast meetmest liiga hilja. QR-kood jääb seejuures kasulikuks, kuid teadlikult tagasihoidlikuks: see viib püsivalt õige tootemärksõna juurde. Tegelik CRA nõuetele vastavus tekib selle taga olevates protsessides.
