Akt EU-a o kibernetičkoj otpornosti postaje stvarnost: što IoT timovi moraju pripremiti do 2027.
Dana 11. lipnja 2026. u Europskoj uniji dogodilo se nešto tiho, ali vrlo važno za tvrtke koje razvijaju povezane uređaje. Države članice morale su imenovati svoja prijavna tijela. Ta tijela imaju ulogu u potvrđivanju tko smije ocjenjivati povezane proizvode prema Aktu o kibernetičkoj otpornosti, odnosno Cyber Resilience Actu (CRA).
Nije bilo velikih konferencija za medije ni dramatičnih naslovnica. No to je prvi važan korak u regulatornom nizu koji će promijeniti način na koji tvrtke projektiraju, isporučuju i održavaju povezanu opremu te ugrađenu programsku opremu namijenjenu tržištu EU-a.
Ako vaša proizvodna strategija uključuje uređaje s mikročipovima, senzorima ili mehanizmom za ažuriranje ugrađene programske opreme, CRA već ulazi u područje koje trebate ozbiljno pratiti. To se može odnositi na industrijske kontrolere, telematiku za vozne parkove, pametnu opremu za maloprodaju, nosive uređaje, povezane komponente i druge digitalne proizvode koji se stavljaju na tržište Europske unije. Sjedište tvrtke ili država proizvodnje nisu presudni. Ključno je to da se proizvod stavlja na tržište EU-a. To proizlazi iz pregleda Europske komisije o Cyber Resilience Actu.
Istodobno, za određene kategorije proizvoda, uključujući medicinske proizvode, vozila, zrakoplovnu opremu i dio pomorske opreme, mogu vrijediti posebna sektorska pravila. Zbog toga je za takve proizvode važno zasebno provjeriti koje se obveze doista primjenjuju.
Rokovi dolaze postupno, ali to nije razlog za odgađanje pripreme
CRA se ne počinje primjenjivati u cijelosti odjednom. Upravo zato mnogi proizvodni timovi podcjenjuju hitnost pripreme: ne postoji jedan jedini datum koji stvara osjećaj neposrednog pritiska.
U stvarnosti, vremenski okvir treba promatrati kroz tri ključne faze.
Do 11. lipnja 2026. države članice EU-a morale su pripremiti infrastrukturu za ocjenjivanje sukladnosti. Datum 11. rujna 2026. svaki tim koji radi s ugrađenim sustavima trebao bi posebno označiti u kalendaru. Od tog datuma proizvođači moraju prijaviti aktivno iskorištavane ranjivosti u roku od 24 sata nakon što za njih saznaju. Obavijest se šalje ENISA-i i nadležnom nacionalnom CSIRT-u. Potpuna obavijest slijedi u roku od 72 sata, a završno izvješće u roku od 14 dana. O početku tog “24-satnog sata” za ranjivosti pisao je i TechTimes.
Dana 11. prosinca 2027. počinje puna primjena ključnih zahtjeva uredbe u području kibernetičke sigurnosti. Za neusklađenost su predviđene kazne do 15 milijuna eura ili do 2,5% ukupnog svjetskog godišnjeg prometa tvrtke.
Osamnaest mjeseci može zvučati kao dovoljno vremena. No kada se taj rok usporedi sa stvarnim ciklusom razvoja ugrađenih proizvoda, postaje jasno da prostor za pripremu nije toliko velik.
Zašto većina IoT timova i timova za ugrađene sustave nije spremna
U organizacijama koje razvijaju povezane proizvode stalno se ponavljaju četiri problema. Nijedan od njih ne može se riješiti preko noći.
Sve počinje s dokumentacijom. Ugrađeni sustavi tijekom godina nakupljaju vanjske biblioteke, komponente operacijskih sustava stvarnog vremena, razvojne pakete dobavljača i interne module. Većina timova može reći što se nalazi u trenutačnoj verziji ugrađene programske opreme. No znatno manje timova može brzo izraditi potpun, verzioniran popis programskih sastavnica za sve proizvode koji su i dalje u uporabi kod korisnika. Upravo je takva vidljivost potrebna kada počne teći rok od 24 sata za prijavu ranjivosti. O tome se govori i u ArmorCodeovu vodiču kroz zahtjeve CRA-a.
Drugi je problem ažuriranje. Proizvod usklađen s CRA-om treba siguran i provjeren mehanizam za daljinsko ažuriranje tijekom cijelog razdoblja podrške. Značajan dio opreme koja je već u uporabi projektiran je u vrijeme kada redovita ažuriranja ugrađene programske opreme nisu bila obvezan scenarij. Inženjeri su često polazili od pretpostavke da će se programska oprema uređaja nakon isporuke mijenjati rijetko ili se uopće neće mijenjati. Dodavanje sigurnog daljinskog ažuriranja proizvodu koji za to nije bio izvorno projektiran ozbiljan je inženjerski zahvat, a ne mala dorada na kraju razvoja.
Treći problem je odgovor na incidente. Upravo ga timovi često najviše podcjenjuju. Prijaviti ranjivost ENISA-i u roku od 24 sata moguće je samo ako već postoje tri stvari: nadzor koji može otkriti iskorištavanje ranjivosti, jasan put eskalacije koji ne ovisi o tome hoće li se jedan određeni inženjer javiti na telefon i unaprijed pripremljeni predlošci obavijesti. Mnogi timovi za ugrađene sustave nikada nisu proveli takvu provjeru u praksi jer ih do sada ništa na to nije izravno obvezivalo.
Četvrti problem nalazi se izvan same inženjerske domene. Većina ugrađenih proizvoda ovisi o komponentama dobavljača: skupovima čipova, modulima, operacijskim sustavima stvarnog vremena, vanjskim bibliotekama i razvojnim alatima. Tvrtke često od tih dobavljača nikada nisu tražile potvrdu o sigurnosti, obvezu isporuke sigurnosnih ispravaka ili čak pouzdan kontakt za prijavu ranjivosti. CRA u praksi čini integratora odgovornim za sigurnosno stanje svega što ulazi u popis sastavnica proizvoda, uključujući dijelove za koje njegov tim nije napisao ni jedan redak koda. Zato se ugovori s dobavljačima i kriteriji nabave moraju ažurirati usporedno s tehničkim radom. Mnogi proizvodni timovi taj razgovor s dobavljačima opreme još nisu ni započeli.
Problem proizvoda koji su već u uporabi
Nove proizvodne linije mogu se od početka projektirati s CRA-om na umu. Složenije je pitanje što učiniti s proizvodima koji su već prodani i rade kod korisnika.
Riječ je o industrijskim kontrolerima, uređajima za praćenje voznih parkova i povezanoj opremi koja se prodavala tijekom posljednjih pet do deset godina. Značajan dio tih proizvoda još je pod jamstvom ili i dalje donosi prihod kroz servisne ugovore. No mnogi od njih nemaju siguran mehanizam za daljinsko ažuriranje, a kamoli ažuriranje s digitalnim potpisom. U takvoj situaciji “samo poslati sigurnosni ispravak” nije stvarna opcija bez promjene arhitekture opreme ili ugrađene programske opreme.
Za proizvode s dugim životnim ciklusom to postaje strateška odluka. Industrijska, zrakoplovna i pomorska oprema često radi deset godina ili dulje. Tim može doraditi postojeću generaciju proizvoda i dodati siguran mehanizam ažuriranja. Može odrediti datum završetka podrške i jasno ga komunicirati korisnicima. Ili može privremeno upravljati rizikom kroz kompenzacijske mjere: segmentaciju mreže, upravljani nadzor i strožu kontrolu pristupa. Time se dobiva vrijeme do sljedeće hardverske revizije.
Nijedna od tih opcija nije besplatna. Ispravan izbor ovisi o broju uređaja u uporabi, preostalom vijeku njihova rada i vremenu koje ostaje do prosinca 2027. Najbolje prolaze timovi koji već sada uspoređuju postojeću bazu instaliranih proizvoda sa zahtjevima CRA-a. Još uvijek ima vremena za promišljen izbor strategije, umjesto reakcije u zadnji trenutak.
Površina usklađenosti raste zajedno s brojem uređaja
CRA dolazi u nezgodnom trenutku za mnoge tvrtke. Poslovni internet stvari izlazi iz faze pilot-projekata i prelazi prema onome što analitičari nazivaju autonomnim povezanim operacijama. To znači više uređaja, više autonomije i više podataka koji se prenose između strojeva uz manju uključenost čovjeka. O tom prijelazu govori izvješće IoT Analytics State of Enterprise IoT 2026.
Svaki novi uređaj u floti znači još jedan unos u popis programskih sastavnica. To je još jedna krajnja točka kojoj treba put za ažuriranje. I još jedan element koji se mora uzeti u obzir kada počne teći rok od 24 sata za prijavu ranjivosti.
Rast proizvoda i dug usklađenosti gomilaju se istodobno. Upravo zato CRA ne treba shvatiti kao vježbu u izradi dokumentacije koju se može prepustiti pravnom odjelu u četvrtom tromjesečju 2027. To je pitanje arhitekture, procesa i odgovornosti za cijeli životni ciklus proizvoda.
Što “siguran dizajn” znači u praksi
Za proizvodne i inženjerske voditelje priprema za CRA nije kozmetička dorada, nego stvaran arhitekturni posao.
Treba početi od sigurnog pokretanja i digitalno potpisane ugrađene programske opreme. Uređaj smije pokretati samo onaj kod koji je prošao kriptografsku provjeru. Potrebni su i šifriranje te provjera vjerodostojnosti komunikacije između uređaja i poslužiteljskih usluga. Zaštita mora vrijediti ne samo dok se podaci pohranjuju, nego i dok se prenose između uređaja, poslužitelja i drugih dijelova sustava.
Timu je potreban ažuran popis programskih sastavnica koji se može izvesti i koji se automatski obnavlja tijekom izgradnje proizvoda. To je znatno pouzdanije od dokumenta koji inženjer ručno sastavlja tek onda kada ga zatraži revizor.
Potreban je i provjeren mehanizam daljinskog ažuriranja koji omogućuje isporuku sigurnosnih ispravaka na već instaliranu opremu. Takav mehanizam omogućuje isporuku ispravaka na daljinu: bez odlaska stručnjaka do korisnika, ručnog spajanja uređaja ili dodatnih radnji s korisničke strane.
Na kraju, potreban je postupak odgovora na incidente koji nije samo napisan, nego i uvježban. Tim mora znati tko donosi odluke, tko priprema obavijesti, tko komunicira s nadležnim tijelima, tko je odgovoran za tehnički ispravak i kako sve to izgleda u prva 24 sata. U suprotnom će odbrojavanje početi tako da netko prvi put otvara tekst uredbe.
Ništa od toga nije egzotično. To je disciplina koju treba primijeniti ranije u životnom ciklusu proizvoda nego što to obično dopuštaju standardni planovi razvoja ugrađenih sustava.
Realističan plan pripreme za sljedećih 18 mjeseci
Timovi koji CRA promatraju kao jedan rok u 2027. obično odgađaju teške odluke do posljednjeg tromjesečja. Upravo tada su inženjerski timovi najopterećeniji, a pogreške najskuplje.
Praktičniji pristup treba započeti već u drugoj polovici 2026. procjenom odstupanja. To znači usporediti svaku liniju povezanih proizvoda s osnovnim zahtjevima CRA-a. Zatim treba utvrditi koji podaci o programskim sastavnicama već postoje, a koje treba rekonstruirati. Nakon toga potrebno je procijeniti koji se proizvodi u uporabi realno mogu doraditi za sigurno daljinsko ažuriranje, a za koje treba odrediti datum završetka podrške ili drugi način upravljanja rizikom.
Rezultati takve procjene trebaju izravno utjecati na arhitekturne odluke prije nego što hardverska revizija za 2027. bude konačno zaključana. Dodavanje sigurnog pokretanja ili digitalno potpisane ugrađene programske opreme u već zamrznut dizajn znatno je skuplje nego ugraditi te zahtjeve na početku.
Procese nadzora i odgovora na incidente moguće je razvijati i uvježbavati usporedno, znatno prije početka obveznog prijavljivanja u rujnu 2026. Tako prva stvarna prijava ranjivosti neće ujedno biti i prvi put da tim prolazi kroz taj postupak.
Nema potrebe čekati konačni rok za početak pripreme. Sljedećih 18 mjeseci treba promatrati kao radni prostor za arhitekturne odluke, tehničke promjene i pripremu procesa.
Kako tome pristupa Allmatics
Ovo je upravo ona vrsta zadataka na kojima Allmatics radi u okviru razvoja ugrađenih IoT rješenja i tehnološkog savjetovanja. Pomažemo u procjeni odstupanja u odnosu na ključne zahtjeve CRA-a, doradi sigurnosne arhitekture već isporučenih proizvoda, projektiranju procesa daljinskog ažuriranja te izgradnji alata za vođenje popisa programskih sastavnica i nadzor.
Takvi alati pretvaraju rok od 24 sata za prijavu ranjivosti u izvediv proces, a ne u teorijsku obvezu na papiru.
Radili smo s povezanim sustavima u zrakoplovstvu, logistici i pomorskoj industriji. Obrazac je svugdje isti: što ranije sigurnost postane punopravni zahtjev arhitekture, a ne stavka na kontrolnom popisu prije objave proizvoda, to je usklađenost kasnije jeftinija.
Ako vaša proizvodna strategija uključuje povezanu opremu koja ulazi ili planira ući na tržište EU-a do prosinca 2027., vrijedi djelovati unaprijed. Najbolji trenutak za procjenu proizvodne ideje s obzirom na CRA jest prije nego što sljedeća hardverska revizija bude konačno definirana. Ne onda kada regulatorna tijela već počnu postavljati pitanja.