Cyber Resilience Act (CRA) 2026–2027: kaj že vemo, česa še ni in kako se izdelek realno pripraviti – še preden bodo objavljeni harmonizirani standardi

Kaj danes zagotovo vemo (in zakaj to ni »tema za 2027«)

Cyber Resilience Act je lahko videti kot še en dokument »iz Bruslja«, ki ga bo mogoče preložiti na pozneje. To je naravna reakcija, posebej če podjetje deluje v ritmu projektov: prototip, uvedba, serijska proizvodnja, servis. Predpisi pogosto pridejo kot »končna zahteva« — nekaj, kar se uredi tik pred ciljem. CRA to logiko spremeni, ker se ne nanaša zgolj na to, kar je na izdelku vidno na dan prodaje. Nanaša se na to, ali proizvajalec zna ohranjati varnost izdelka skozi čas in dokazati, da je to naredil zavestno, ne po naključju.

Najpomembnejše dejstvo je preprosto, vendar ima strateške posledice: CRA je produktna ureditev, umeščena v mehaniko trga EU (vključno z označevanjem CE). Evropska komisija izrecno navaja, da morajo izdelki nositi oznako CE kot signal skladnosti s CRA, nadzor nad izvajanjem pa je v pristojnosti organov za nadzor trga. To torej ni »IT-standard«, ki bi ga lahko obravnavali kot interni program izboljšav. Gre za okvir, ki vpliva na možnost prodaje.

Datumi, ki pomagajo razjasniti sliko

V samem besedilu Uredbe (EU) 2024/2847 je razvidna postopna uporaba. CRA se uporablja od 11. decembra 2027, vendar z jasnimi izjemami. Člen 14 (poročanje) se uporablja od 11. septembra 2026, poglavje o priglasitvi organov za ugotavljanje skladnosti (poglavje IV) pa od 11. junija 2026. To so trije datumi, ki jih je smiselno obravnavati kot »mejnike«, ker ustrezajo trem različnim vrstam pripravljenosti: operativni, institucionalni in produktni.

Komisija to sporoča še bolj preprosto: CRA je začel veljati 10. decembra 2024, ključne obveznosti od 11. decembra 2027, poročanje pa od 11. septembra 2026. Če nekdo v podjetju reče »čas imamo do 2027«, ima najpogosteje v mislih projektne zahteve in ugotavljanje skladnosti. Poročanje pa je prej in se nanaša na dogodke, ki ne čakajo na terminski plan.

Poročanje: obveznost, ki zahteva proces (ne dokument)

Zahteva po poročanju je dober lakmusov papir, ker pokaže, kako CRA razume »kibernetsko varnost izdelka«. To ni izjava o nameri niti »politika«. To je proces, ki mora delovati v stresni situaciji: ko se pojavi ranljivost, ki se aktivno izkorišča, ali resen incident.

Komisija to opiše nedvoumno: proizvajalec mora prijavljati ranljivosti, ki se aktivno izkoriščajo, ter hude incidente, ki vplivajo na varnost izdelka. Zahtevano je »zgodnje opozorilo« v 24 urah od trenutka, ko za to izve, popolna prijava v 72 urah, končno poročilo pa: do 14 dni po razpoložljivosti popravnega ukrepa za ranljivosti, ki se aktivno izkoriščajo, ter v enem mesecu za hude incidente.

V praksi to pomeni, da organizacija potrebuje več kot kontrolni seznam. Potrebuje mehanizem, ki odgovori na tri vprašanja: kako bomo izvedeli, da problem obstaja; kdo bo presodil, ali gre že za »aktivno izkoriščano« ali »hudo«; in kako bomo organizirali obveščanje ter popravek v času, ki ne dopušča improvizacije.

Če se na usposabljanjih pojavi zmeda, je to pogosto zato, ker CRA zadene vrzel med IT in izdelkom. Za IT je »incident« lahko dogodek v infrastrukturi. Za proizvajalca je »incident« dogodek, ki zadeva izdelek pri stranki, različico, konfiguracijo, način uvedbe. CRA zahteva, da se ta svetova povežeta v eno odgovornost.

Kaj zajema CRA: izdelek kot odnos z omrežjem, ne »naprava na mizi«

V praksi smo se pri ocenjevanju tveganja strojev učili, da tveganje ni lastnost samega stroja — nastane v odnosu človek–stroj. Pri CRA gre za podoben premik perspektive: varnost ne obstaja »v napravi«, temveč v odnosu izdelka do digitalnega okolja, načina uporabe in sposobnosti proizvajalca, da se odzove.

Komisija pri povzetku CRA opozori na definicijo »izdelkov z digitalnimi elementi« in na to, da obveznosti poročanja veljajo za vse takšne izdelke, dane na trg EU — tudi za tiste, ki so bili dani na trg pred 11. decembrom 2027. To je ključno pojasnilo, ker odpravi pogost mit: »za stare izdelke to ne velja«. Poročanje — velja.

Česa še ni (harmoniziranih standardov) in zakaj nas to ne bi smelo ohromiti

V razpravah o CRA se pogosto pojavi stavek: »še ni harmoniziranih standardov, zato se ne da nič narediti«. Zveni logično, vendar se v tem skriva past. Harmonizirani standardi so orodje, ki olajša dokazovanje skladnosti (domneva skladnosti), niso pa edina pot do dejanske varnosti izdelka. In niso pogoj, da lahko začneš pravilno načrtovati.

Komisija temo standardov neposredno vodi prek strani »CRA Standardisation« in navaja, da je sprejela standardisation request M/606, ki zajema nabor 41 standardov za podporo CRA — tako horizontalnih kot vertikalnih (produktnih). To je pomembno, ker kaže, da EU razume tržni problem: brez standardov bodo podjetja skladnost gradila vsako po svoje, nadzor trga pa bo imel težje delo.

Horizontalni in vertikalni standardi: kaj to pomeni za proizvajalca

Poenostavljeno:

• horizontalni standardi naj bi opisovali »kako« graditi in vzdrževati varnost izdelka ne glede na kategorijo (procesi, metode, pristop na podlagi tveganja),
• vertikalni standardi naj bi natančneje opredelili zahteve za posamezne razrede izdelkov (tam, kjer so tveganja in arhitekture tipični).

To razlikovanje ima praktične posledice. Če razvijaš industrijski izdelek, kjer je del okolja »OT« in je življenjski cikel dolg, boš potreboval standarde, ki niso pisani za aplikacijo SaaS. Prav zato so vertikalni standardi pomembni: pomagajo preiti z ravni splošnih načel na to, kaj je treba nadzorovati v dejanskih arhitekturah.

Časovnica: standardi bodo prihajali postopno, ne »v paketu pred 2027«

Komisija v gradivih o implementaciji CRA prikazuje, da se CRA uvaja postopno, standardi pa naj ta proces skozi čas podpirajo. Na ravni dejstev, ki so danes gotova: imamo formalno sprejeto uredbo in imamo zagnan mehanizem standardizacije (M/606).

Za prakso je ključno razumeti en stavek: tudi ko standard pripravijo organizacije za standardizacijo, se »domneva skladnosti« v pravnem smislu pojavi šele, ko je sklic na standard objavljen kot harmonizirani standard v Uradnem listu EU. To je mehanizem, ki je skupen pristopu EU k harmonizaciji: standardi so most med pravom in inženirsko prakso, vendar mora EU ta most formalno »priznati«.

Z vidika proizvajalca to pomeni, da bosta leti 2026–2027 obdobje, ko bo del podjetij deloval na podlagi lastnih metod dokazovanja skladnosti (na tveganju temelječe + dokazila), del pa se bo že mapiral na nastajajoče standarde. In to je normalno.

»Ni standardov« ne pomeni »ni obveznosti« — pomeni večjo težo dokazil

Tu se pokaže pomembna posledica: če ni standardov, ki ponujajo najpreprostejšo pot dokazovanja skladnosti, naraste pomen tistega, kar je v revizijski praksi vedno odločilno: skladen sled odločitev.

Katera tveganja smo ocenili? Katere scenarije smo sprejeli kot realistične? Kako smo izbrali zaščitne ukrepe? Kako upravljamo ranljivosti? Kako dolgo podpiramo izdelek? Kako obveščamo stranko? CRA ne zahteva, da bi proizvajalec »ugibal prihodnje EN-standarde«. Zahteva, da zna pokazati, da njegove odločitve niso bile naključne, temveč temeljijo na tveganju in na najsodobnejšem stanju tehnike.

Kako se realno pripraviti na CRA (načrt za proizvajalca in integratorja)

Največja vrednost CRA je v tem, da zahteva zrelost: kibernetska varnost preneha biti dodatek k izdelku in postane njegova lastnost. A zrelost ne nastane iz izjav. Nastane iz procesa, ki je dovolj natančen, da deluje v praksi, in dovolj preprost, da ga inženiring ne začne obhajati.

Pri oceni tveganja strojev se najboljše projektne odločitve pojavijo takrat, ko nehamo spraševati »katera nevarnost grozi stroju« in začnemo spraševati »pri katerih nalogah in v katerih stanjih je človek izpostavljen«. Pri CRA je podobno: nehamo spraševati »katere ranljivosti ima izdelek« in začnemo spraševati »v katerih pogojih izdelek postane izpostavljen in kaj lahko proizvajalec takrat naredi«. Ta premik uredi delo.

Korak 1: Opredeli izdelek kot sistem (in ne kot napravo)

Začni z opredelitvijo, kaj je v tvojem primeru »izdelek z digitalnimi elementi«. Ne le strojna oprema in vdelana programska oprema, temveč tudi tisto, kar se pogosto spregleda, ker ne gre v škatlo: komponente, knjižnice, mehanizmi posodabljanja, storitve, brez katerih izdelek ne izpolnjuje svoje funkcije. Pri CRA je to pomembno, ker se odgovornost proizvajalca nanaša na to, kar pride na trg kot izdelek — ne le na to, kar je izdelal oddelek za mehaniko.

To je tudi prvi trenutek, ko bi morali biti integratorji iskreni do sebe: če integriraš komponente in jih konfiguriraš tako, da v očeh stranke nastane »končni izdelek«, potem nisi samo »izvajalec uvedbe«. Si sooblikovalec tveganja in sooblikovalec odgovornosti.

Korak 2: Izvedi oceno tveganja po CRA tako, da bo orodje za odločanje

Ne gre za »matriko« na prosojnicah. Gre za oceno tveganja, ki vodi do projektnih odločitev in jo je mogoče ponavljati na enak način.

V praksi se dober pristop k CRA začne s preprostim vprašanjem: kateri so realni scenariji zlorab v okolju naročnika, ne le v laboratoriju? Kdo ima servisni dostop? Kako je videti omrežje? Kako pogosto posodabljamo? Kakšne so posledice izpada? V industriji so ta vprašanja bolj neprijetna kot v IT, ker odgovori pogosto zvenijo: »ne moremo posodabljati vsak teden« ali »nimamo telemetrije«. In prav zato jih je treba postaviti. CRA je pravna zahteva, vendar so njegove posledice projektne.

Korak 3: Zgradi “vulnerability handling” kot proizvodni proces, ne kot krizno reakcijo

Zahteve poročanja, ki jih je opisala Komisija (24h/72h/14 dni/mesec), so neusmiljene do organizacije, ki nima procesa. Če želiš biti pripravljen na 11. september 2026, moraš “vulnerability handling” obravnavati kot del življenjskega cikla izdelka, ne kot »nalogo varnostne ekipe«.

To pomeni:

• en kanal za sprejem prijav (CVD policy + kontakt),
• trijaža z jasnim lastnikom in merili,
• mehanizem za izdelavo in dostavo varnostnih posodobitev,
• model komunikacije s strankami, ki ni improvizacija,
• pripravljenost na poročanje (kdo poroča, s katerimi podatki, kako hitro).

Vse to zveni kot »organizacijsko« delo. V praksi pa je to produktno delo, ker se nanaša na različice, združljivost, arhitekturo posodabljanja in strategijo podpore.

Korak 4: Izberi obdobje podpore kot poslovno odločitev, ne kot minimalno zahtevo

Če tvoji izdelki v industriji živijo 10–15 let, je obdobje podpore strateška odločitev. CRA zahteva, da podpora ne bo obljuba brez kritja. To pomeni, da mora obdobje podpore izhajati iz analize: kako dolgo bo izdelek v uporabi, kakšna je dobavna veriga komponent, kako dolgo boš sposoben dobavljati popravke. V praksi obdobje podpore začne »vleči« celoten ekosistem: pogodbe z dobavitelji, razpoložljivost okolja za gradnjo, vzdrževanje orodnih verig in celo odločitve o tem, ali ima izdelek oddaljene funkcije ali je izoliran.

Če obdobje podpore obravnavaš kot formalnost, boš najpozneje leta 2027 trčil ob konflikt: stranka pričakuje podporo, ti pa nimaš več virov niti odvisnosti, da bi jo zagotavljal. CRA tega problema ne ustvarja — CRA ga samo razkrije.

Krok 5: Uredi dobavno verigo: pogovor z dobavitelji je del skladnosti

V CRA ni »čarovnije«, ki bi poskrbela, da bodo zunanji komponenti postali varni. Če tvoja naprava temelji na knjižnicah, komunikacijskih modulih, operacijskem sistemu, SDK ali strojnih komponentah, je tvoje tveganje neposredno odvisno od kakovosti praks dobavitelja.

Zato se že zdaj splača uvesti pogovor o stvareh, ki ne zvenijo kot trženje, temveč kot inženirstvo:

• ali dobavitelj zna o ranljivostih obveščati na predvidljiv način,
• kakšen je njegov odzivni čas,
• ali ima postopek objave popravkov,
• ali zna komponento vzdrževati za obdobje, ki je skladno s tvojim obdobjem podpore.

Tu CRA resnično poseže v posel: dobavitelj, ki ne zna obvladovati ranljivosti, ni »cenejši«. Je regulatorno tveganje.

Krok 6: Zgradi dokumentacijo kot skladen sled: pravo → tveganje → odločitev → dokaz

Pri revizijah skladnosti vedno zmaga skladnost in povezanost. Če iz ocene tveganja izhaja, da je določen vmesnik kritičen, dokumentacija pa ne opisuje, kako ga zavaruješ; če trdiš, da so posodobitve varne, pa ne znaš pokazati, kako zagotavljaš integriteto paketov; če praviš, da imaš postopek obravnave ranljivosti, pa ne znaš pokazati, kako izvajaš razvrščanje prijav — to ni »pomanjkanje papirjev«. To je pomanjkanje dokaza, da postopek deluje.

V CRA je ta sled ob odsotnosti harmoniziranih standardov še posebej pomembna. Ker bo prav ona osnova za pogovor z organom nadzora trga, z veliko poslovno stranko in pri nekaterih kategorijah izdelkov tudi z organom za oceno skladnosti. In kar je enako pomembno: to bo osnova notranje stabilnosti. Ekipa ve, zakaj nekaj počnemo, ne le »da moramo«.

Zaključek: CRA kot nova projektna zahteva, ne »projekt skladnosti«

Če bi moral pustiti eno misel, ki poveže vse tri dele: CRA ni problem, ki ga rešuješ na koncu. Je okvir, ki spremeni način razmišljanja o izdelku. Tako kot ISO 12100 uči, da tveganje nastaja v odnosu človek–stroj, tako CRA uči, da kibernetska varnost nastaja v odnosu izdelek–okolje–življenjski cikel proizvajalca.

Harmonizirani standardi bodo prišli in poenostavili nekatere poti. Toda njihova odsotnost ni razlog za mirovanje. Je razlog, da se osredotočiš na to, kar CRA vedno presoja: na odločitve, dokaze in sposobnost delovanja v resničnem svetu — ne v predstavitvi.