CRA ukratko: Kibernetička sigurnost postaje zahtjev za proizvod

CRA čini kibernetičku sigurnost sastavnim dijelom proizvoda. Svaka osoba koja stavlja 'proizvod s digitalnim elementima' na tržište EU mora ga projektirati i razviti na siguran način, osigurati ažuriranja sigurnosti tijekom cijelog očekivanog vijeka trajanja, upravljati ranjivostima te procijeniti i dokumentirati sukladnost sa strogim zahtjevima CRA za kibernetičku sigurnost (ili da ih procijene), te staviti oznaku CE na proizvod. CRA se time oslanja na poznate alate zakonodavstva EU o proizvodima i proširuje ih tako da obuhvaćaju kibernetičku sigurnost.

Ovo obuhvaća i hardver i softver u jednakoj mjeri, od usmjerivača i industrijskih upravljačkih sustava do desktop aplikacija, mobilnih aplikacija i unaprijed instaliranog firmvera. Ključni čimbenik je definicija iz članka 3. stavka 1. CRA – proizvod čija je namjena ili razumno predvidiva uporaba uključivanje izravne ili neizravne podatkovne veze s uređajem ili mrežom (Smjernica, str. 8, odlomak 17. i nadalje). Glavni teret pada na proizvođače. Uvoznici i distributeri imaju vlastite, postupno razrađene obveze provjere.

Zanimljivo je da se CRA ne odnosi isključivo na fizičke proizvode. Svako tko razvija softver i komercijalno ga nudi unutar EU također se smatra proizvođačem prema CRA – čak i ako u svom portfelju nema nijedan uređaj.

Obveze stupaju na snagu postupno. CRA je stupio na snagu 10. prosinca 2024.; tijela za ocjenjivanje sukladnosti mogu se imenovati od 11. lipnja 2026.; obveze izvještavanja počinju 11. rujna 2026.; a Uredba će se u potpunosti primjenjivati od 11. prosinca 2027.

Okvir sankcija je (kao što neće iznenaditi nikoga tko posljednjih godina nije potpuno ignorirao zakonodavstvo o digitalnim pravima) ponovno znatan: U slučaju kršenja temeljnih zahtjeva za kibernetičku sigurnost predviđene su novčane kazne do 15 milijuna eura ili 2,5 posto globalnog godišnjeg prometa (članak 64. CRA).

CRA kao gradivni blok europskog digitalnog prava

EU regulira kibernetičku sigurnost na više razina. CRA je dio šireg cilja jačanja otpornosti poduzeća i potrošača u EU te njihove zaštite od kibernetičkih napada. Regulatorni okvir može se ugrubo opisati na sljedeći način:

Osim CRA-e, prvo treba spomenuti Direktivu NIS 2. Provedena u Austriji putem NISG-a 2026, ovaj režim primjenjuje se na organizacije u određenim kritičnim sektorima. Svaka organizacija koja posluje u obuhvaćenom sektoru mora provesti specifične mjere upravljanja rizicima i prijaviti incidente. CRA i NISG 2026 mogu se lako primjenjivati paralelno: industrijsko poduzeće može biti i organizacija obuhvaćena NISG-om 2026 i proizvođač prema CRA, s dva odvojena kanala za izvještavanje i dva odvojena lanca dokumentacije.

Osim toga, postoje i drugi moduli koji se mogu odnositi na iste proizvode:

• GDPR o obradi osobnih podataka;
• Uredba o umjetnoj inteligenciji, prema kojoj se zahtjevi za kibernetičku sigurnost za AI sustave visokog rizika smatraju ispunjenima, podložno određenim uvjetima, kroz usklađenost s CRA-om (članak 12. CRA-a);
• nova Direktiva o odgovornosti za proizvode, koja izričito obuhvaća softver kao proizvod i bavi se neosiguravanjem sigurnosnih ažuriranja; i
• sektorski specifični režimi kao što je DORA u financijskom sektoru.

Unutar ovog okvira CRA premostuje jaz na razini proizvoda: osigurava da proizvodi i usluge koje organizacije kupuju i koriste zadovoljavaju minimalne sigurnosne standarde, čime kibernetička sigurnost postaje ključni čimbenik pri nabavi i predmet ugovornog dogovora.

Nove smjernice CRA-a: neobvezujuće, ali autoritativne

Rad je objavljen 27. srpnja 2026. kao Prilog komunikaciji C(2026) 5252 Objavljeno. Obuhvaća oko 80 stranica i oslanja se na brojne praktične primjere, slučajeve upotrebe i dijagrame toka. U usporedbi s konzultacijskim nacrtom iz ranog ožujka 2026., konačna verzija je detaljnija i u nekoliko je aspekata primjetno proporcionalnija. Objavljene smjernice nisu pravno obvezujuće; samo Sud Europske unije (ECJ) može dati obvezujuće tumačenje CRA-e. Ipak, u praksi ostaje najvažnija referentna točka, budući da će je tijela za nadzor tržišta i notificirana tijela koristiti kao vodič. Osim toga, Europska komisija održava kontinuirano ažuriranu Dokument s najčešćim pitanjima o provedbi CRA Spremno.

Saželi smo točke relevantne za poduzeća i u svakom slučaju iznijeli praktične implikacije.

1. Softver, web-aplikacije i web-stranice

Kada softver, kao samostalni proizvod, spada u opseg CRA? Smjernice se usredotočuju na mjesto izvršavanja. Softver koji je dostupan korisnicima i koji se lokalno izvršava na njihovim sustavima predstavlja "proizvod s digitalnim elementima" u smislu članka 3. stavka 1. CRA. Ovo se odnosi na preuzimanja i instalirane klijente, kao i na proširenja preglednika i aplikacije razvijene korištenjem web tehnologija, ali koje se izvršavaju lokalno (Smjernice, str. 8, odlomak 20).

Softver koji se u potpunosti pokreće na daljinu i kojem se pristupa isključivo putem preglednika sam po sebi ne predstavlja takav proizvod. Isto se odnosi i na web-stranice koje pružaju isključivo informacije (Smjernica, str. 8., odlomak 21., s pozivom na uvodne izjave 11. i 12. CRA). Takav softver obuhvaćen je samo ako je potreban kao "rješenje za daljinsku obradu podataka" ("RDPS"; usp. članak 3. stavak 2. CRA i odmah u nastavku) za funkciju drugog proizvoda.

Europska komisija definira opseg još detaljnije. Definicija obuhvaća one module koji su odgovorni za funkcionalnost proizvoda, uključujući sučelja koja koriste. Downstream back-end sustavi s kojima proizvod ne komunicira izravno ne smatraju se RDPS-ovima (Smjernice, str. 63 i nadalje). To je od značajne praktične važnosti za pružatelje SaaS usluga. Tko god isključivo koristi rješenje temeljeno na pregledniku, samim tim ne postaje proizvođač u smislu CRA. Međutim, tko god osim toga isporučuje paket za instalaciju, dodatak (plug-in), agenta ili desktop aplikaciju, postaje proizvođač – točnije, u pogledu te komponente.

Jednako je relevantna izjava u smjernicama o stavljanju softvera na tržište. Identične kopije iste verzije smatraju se stavljenima na tržište čim se ta verzija prvi put ponudi na prodaju ili uporabu unutar Unije. Varijante koje se razlikuju po komponentama, konfiguraciji ili omogućenim funkcionalnostima, s druge strane, predstavljaju zasebne proizvode sa svojim rokom (Smjernice, str. 7, odjeljak 14). To izravno utječe na upravljanje verzijama i izdanjima.

2. Daljinska obrada podataka: Gdje je granica?

CRA ne obuhvaća samo sam uređaj, već i daljinsku obradu bez koje ne bi mogao obavljati svoju funkciju. Oblak iza pametnog termostata dio je proizvoda, a ne samo zasebna usluga. U tu svrhu vodič koristi tri kumulativna pitanja za procjenu i nadopunjuje ih dijagramom toka te primjerima upotrebe koji se protežu od aplikacija za mobilno bankarstvo do industrijskih robota (vodič, str. 63 i nadalje; za primjere upotrebe, str. 70 i nadalje).

Pitanja za ispit su sljedeća:

1. Prerađuju li se podaci na daljinu?
2. Bi li njegov nedostatak spriječio proizvod da obavlja jednu od svojih funkcija?
3. Je li softver razvio proizvođač ili pod nadzorom proizvođača?

Čisti SaaS, IaaS ili PaaS usluge koje pružaju treće strane, a koje proizvođač samo koristi, prema smjernicama se u načelu ne smatraju vlastitim RDPS (rješenjima za daljinsku obradu podataka) proizvođača. Međutim, one se moraju uzeti u obzir kao vanjske ovisnosti pri procjeni rizika kibernetičke sigurnosti prema članku 13. stavku 2. CRA-e i podliježu dužnosti pažnje propisanoj člankom 13. stavkom 5. CRA-e (Smjernice, str. 68 i nadalje). Za proizvođače to znači pregled ugovora i odnosa, uključujući one s takvim uslugama, unutar lanca opskrbe.

3. Rezervni dijelovi: funkcionalna analiza, rigoroznija kontekstualna verifikacija

CRA se također bavi pitanjem rezervnih dijelova. Svaki sastavni dio koji sadrži digitalne elemente i koji se pojedinačno stavlja na tržište, u načelu je proizvod sam po sebi u smislu CRA, sa svojom procjenom rizika, svojom ocjenom sukladnosti i vlastitim CE označavanjem. To bi bilo nepraktično za popravke. Članak 2. stavak 6. CRA stoga oslobađa rezervne dijelove koji zamjenjuju identične komponente i proizvedeni su prema istim specifikacijama (vidi također uvodnu izjavu 29. CRA). U praksi opseg ovog izuzeća određuje može li se rezervni dio isporučiti bez daljnjih formalnosti ili predstavlja zaseban slučaj prema CRA.

Smjernice tumače izuzeće za rezervne dijelove fleksibilno i time, načelno, na način koji se lako može provjeriti. 'Identično' ne znači nužno fizički ili tehnički isto u svakom pogledu. Odlučujuća su funkcionalna uloga i značajke relevantne za kibernetičku sigurnost (Smjernice, str. 32, odlomak 99). Manja odstupanja stoga su bezopasna sve dok ne mijenjaju profil kibernetičke sigurnosti komponente. S druge strane, razlike u algoritmima, komunikacijskim protokolima, kriptografskim mehanizmima ili kontrolama pristupa govore protiv zajedničkog identiteta (Smjernice, str. 32, fusnota 100). U takvim slučajevima novi zamjenski dio mora se smatrati zasebnim proizvodom koji sadrži digitalne elemente.

Kontekst je također ključan čimbenik. Dio se mora isporučiti posebno za popravak ili produljenje vijeka trajanja identificiranog proizvoda ili obitelji proizvoda; sama tehnička kompatibilnost nije dovoljna. Svrha popravka mora biti očita iz okolnosti isporuke – na primjer, iz narudžbe, ponude ili kanala poslije prodaje – a potporne dokaze potrebno je čuvati radi potreba nadzora tržišta (Smjernice, str. 31. i dalje, odlomak 97). Čak i cjelovit proizvod koji je integriran u veći sustav, kao što je programabilni logički kontroler u automatizacijskom sustavu, može podlijegati iznimci (Smjernice, str. 33, odlomak 102).

4. Besplatan i otvoreni softver (FOSS)

Softver otvorenog koda predstavlja CRA-u temeljni problem. Uredba povezuje svoje obveze s stavljanjem na tržište u okviru komercijalne djelatnosti. Međutim, velik dio softvera otvorenog koda stvara se bez ikakve prodajne transakcije; on se objavljuje, a ne prodaje. Stoga se smjernica bavi tim pitanjem u tri koraka i posvećuje mu jedan od svojih najdužih odjeljaka, koji obuhvaća oko 14 stranica (Smjernica, str. 16 i nadalje).

Prvi korak odnosi se na definiciju. Prema članku 3. stavku 48. Zakona o slobodnom pristupu informacijama (CRA), samo se softver koji kumulativno ispunjava dva uvjeta smatra FOSS-om: licenciran je pod slobodnom i otvorenom licencom koja dodjeljuje sva prava pristupa, uporabe, izmjene i redistribucije te je njegov izvorni kod javno dostupan. Ako je izvorni kod dostupan samo plaćajućim korisnicima ili ograničenoj skupini, to ne predstavlja FOSS u smislu CRA, unatoč tome što ima besplatnu licencu (Smjernice, str. 17, odlomak 44 i nadalje).

Drugi korak je razjasniti tko je odgovoran za softver. To se odnosi na osobu koja ga objavljuje i donosi odluke o njegovom razvoju, izdavanjima i distribuciji; u praksi je to stoga 'održavatelj' (za definiciju ovog pojma: Smjernice, str. 18, odlomak 49). Svaka osoba koja samo doprinosi kodom ostaje suradnik i nije podložna nikakvim CRA obvezama – čak i ako ima prava commitiranja. Tehničke ovlasti same po sebi ne utvrđuju odgovornost (Smjernice, str. 18, odlomak 49, i Objašnjavajući memorandum 18 CRA).

Treći korak je komercijalna aktivnost. Svako tko naplaćuje cijenu za sam softver – na primjer, za unaprijed kompajlirane binarne datoteke – stavlja ga na tržište i smatra se proizvođačem (Smjernica, stranica 18, stavak 51). Isto se odnosi i na slučajeve kada se drugi proizvodi ili usluge monetiziraju putem slobodnog softvera, na primjer putem oglašavanja, provizija ili pretplata, ili kada je korištenje povezano s obradom osobnih podataka u svrhe koje nisu poboljšanje sigurnosti, kompatibilnost ili interoperabilnost (Smjernice, stranica 19, stavak 54).

• Plaćena podrška i savjetodavne usluge vezane uz besplatno dostupan softver same po sebi ne čine ga komercijalnim. Odlučujući čimbenik je je li pristup softveru ili njegovo održavanje uvjetovan plaćanjem (Smjernica, str. 20, stavak 55. i nadalje). U slučaju donacija, Smjernice idu dalje od onoga što je navedeno u Objašnjenju 15 CRA-e: sama postojanost poveznice za donacije ne predstavlja namjeru ostvarivanja dobiti, čak i ako prihodi premaše troškove dizajna, razvoja i pružanja. FOSS koji se financira isključivo donacijama stoga se općenito ne stavlja na tržište (Smjernice, str. 21, odjeljak 61).
• Situacija je drugačija ako su preuzimanja, trenutačne verzije ili sigurnosne nadogradnje u praksi dostupne samo donatorima. U tom slučaju donacija funkcionira kao cijena (Smjernica, str. 21 i nadalje, odlomak 62, uključujući primjere 21 i 22). Međutim, izvor financiranja ne mijenja klasifikaciju: sponzorstva, bespovratna sredstva ili plaćeni razvojni rad ne pretvaraju slobodno dostupni FOSS u tržišni proizvod (Smjernice, str. 22, odlomak 63 i nadalje). Niti dobrotvorne organizacije, čiji se viškovi koriste isključivo u dobrotvorne svrhe, ne stavljaju na tržište FOSS koji objavljuju (Smjernice, str. 22, odjeljak 66).

Zanimljiv je tretman dvaju modela. Community Edition ostaje samostalni, nekomercijalni proizvod, čak i ako isti pružatelj iznad istog koda izgradi plaćeno izdanje ili ga integrira u veći proizvod. Procjena se provodi za svaki proizvod pojedinačno, a ne na temelju poslovnog modela u cjelini (Smjernice, str. 19, st. 52). Međutim, ako je pružatelj pravna osoba, podliježe obvezama održavatelja softvera otvorenog koda za besplatnu verziju (Smjernice, stranica 19, fusnota 53).

Za projekte koji se ne stavljaju na tržište, CRA priznaje zasebnu ulogu s umanjenim obvezama. "Staratelj softvera otvorenog koda" (članak 3. stavak 14. CRA) je pravna osoba koja pruža dugoročnu podršku za FOSS bez komercijalizacije, na primjer putem hostinga, upravljanja ili vlastitih razvojnih resursa. Podliježe samo obvezama utvrđenima u članku 24. CRA, a opseg obveza izvještavanja ovisi, prema članku 24. stavku 3. CRA, o prirodi pružene podrške. Oni koji pružaju isključivo netehničku podršku, kao što su brendiranje, pravila upravljanja ili rad s zajednicom, ne podliježu nikakvoj obvezi izvještavanja. Oni koji osiguravaju IT infrastrukturu projekta moraju prijaviti ozbiljne incidente koji utječu na tu infrastrukturu u skladu s člankom 14. stavkom 3. CRA-e. Samo oni koji doprinose vlastitim razvojnim resursima – na primjer, upravljanjem izdanjima ili obradom izvješća o ranjivostima – također su obvezni prijaviti aktivno iskorištavane ranjivosti u skladu s člankom 14. stavkom 1. Zakona o otvorenom kodnom programu (CRA) (Smjernice, str. 25. i dalje, odredbe 79. i dalje). Tipičan primjer je zaklada koja stoji iza velikog projekta.

Za tvrtke koje samo koriste komponente otvorenog koda, situacija ostaje jednostavna. Tko god integrira FOSS u vlastiti proizvod, time ne postaje proizvođač te komponente. Međutim, oni ostaju odgovorni za vlastiti proizvod, obvezni su postupati s dužnom pažnjom u skladu s člankom 13. stavkom 5. Zakona o računalnom zlouporabi (CRA) i moraju prijaviti ranjivosti u integriranim komponentama te vratiti sigurnosne zakrpe projektu (članak 13. stavak 6. Zakona o računalnoj zlouporabi; Smjernica, str. 26, odlomak 86. i nadalje).

5. Ažuriranja i značajne promjene

Softver se neprestano razvija. CRA stoga mora utvrditi u kojem trenutku ažuriranje zakonski predstavlja novi proizvod. Za to se koristi pojam "značajna promjena" kako je definirano u članku 3. stavku 30. CRA, tj. promjena učinjena nakon stavljanja uređaja na tržište koja ili utječe na sukladnost sa suštinskim zahtjevima navedenima u Prilogu I., dijelu I., ili mijenja namjenu za koju je uređaj ocijenjen.

Opseg promjena određuje potreban trud, vremenski okvir i mogućnost isporuke proizvoda. Proizvod koji je bitno izmijenjen smatra se da je prvi put stavljen na tržište, što zahtijeva novu ocjenu sukladnosti, ažuriranu tehničku dokumentaciju i novu izjavu o sukladnosti. Svaka osoba koja značajno izmijeni i stavi na raspolaganje proizvod treće strane postaje proizvođač (članci 21. i 22. Zakona o sigurnosti proizvoda), a svaka osoba koja značajno izmijeni proizvod stavljen na tržište prije 11. prosinca 2027. nakon tog datuma također (članak 69. stavak 2. Zakona o održivosti; Smjernice, stranica 30, fusnota 91).

Kriterij je razina rizika, a ne tehnički opseg. Ažuriranje sigurnosti općenito nije materijalna promjena, čak i ako uvodi duboke promjene u kodu (ErwGr 39 CRA; Smjernice, stranica 36, fusnota 108). Suprotno tome, čak i mala funkcija može biti dovoljna. Smjernice navode kao primjer funkciju "Zapamti me" koja lokalno pohranjuje tokene za prijavu: tehnički neupadljivu, ali koja uvodi nove rizike krađe tokena i preuzimanja sesije te stoga predstavlja bitnu promjenu (Smjernice, str. 35, Primjer 44).

Dokument s uputama postavlja četiri pitanja koja se mogu koristiti za vođenje procjene (Dokument s uputama, stranica 37, stavak 110). Uvodi li ažuriranje nove vektore napada, poput dodatnih sučelja, komunikacijskih kanala ili vanjskih ovisnosti? Omogućuje li nove scenarije napada? Mijenja li vjerojatnost već poznatih scenarija? Ili mijenja njihov utjecaj? Ako je odgovor na sva ta pitanja 'ne' i pretpostavke na kojima se temelji procjena rizika ostaju valjane, općenito nema materijalne promjene.

Jedno pojednostavljenje često se zanemaruje u ovom kontekstu. Funkcije koje je proizvođač već uključio i procijenio u svojoj procjeni rizika mogu se omogućiti u kasnijoj fazi bez da to predstavlja značajnu promjenu (Smjernice, str. 34 i dalje, marginalna bilješka 106, uključujući primjere 42 i 43). Uključivanje planiranih značajki iz razvojne karte u procjenu rizika u ranoj fazi štedi na poslovima usklađivanja kasnije.

Posljedice su proporcionalnije od onih navedenih u nacrtu. Ako izvornik proizvođača izvrši izmjenu, ostaje proizvođačem, ali može nastaviti koristiti postojeća ispitivanja i dokumentaciju za neizmijenjene aspekte te usmjeriti ocjenu sukladnosti na izmijenjene dijelove (Smjernice, str. 40 i dalje). Ako treća strana bitno izmijeni proizvod i stavi ga na raspolaganje, ona je načelno podložna obvezama proizvođača prema članku 22. CRA-e samo za izmijenjeni dio, osim ako izmjena ne utječe na cjelokupnu kibernetičku sigurnost proizvoda (Smjernice, str. 39. i dalje).

Komisija je stoga ublažila tumačenje izneseno u nacrtu, prema kojem bi značajna promjena proizvoda stavljenog na tržište prije datuma stupanja na snagu uvijek zahtijevala da se cijeli proizvod dovede u potpunu sukladnost s CRA. To ne utječe na činjenicu da se značajno izmijenjeni proizvod smatra novim stavljanjem na tržište.

Bez obzira na klasifikaciju, zahtjevi za upravljanje ranjivostima navedeni u Prilogu I, dijelu II CRA ostaju na snazi, a i procjena rizika i tehnička dokumentacija moraju se u svakom trenutku održavati ažurnima (članak 13. stavak 7. i članak 31. stavak 2. CRA-e; Smjernice, stranica 38, fusnota 113).

U svakodnevnoj praksi mogu se razlikovati tri scenarija. Ispravak pogreške ili sigurnosna nadogradnja ne utječe ni na ocjenu sukladnosti ni na razdoblje podrške. Nova značajka koja uključuje nove rizike predstavlja značajnu promjenu, ali pokreće ponovnu procjenu samo za izmijenjene dijelove i ne pokreće automatski ponovno razdoblje podrške. Zamjenski dio bez promjena u njegovim svojstvima relevantnim za kibernetičku sigurnost ostaje izvan opsega CRA prema članku 2. stavku 6. CRA, pod uvjetom da se može provjeriti kontekst popravka.

6. Razdoblje podrške: Ponovna procjena da, novi početak ne

Razdoblje podrške je razdoblje tijekom kojeg morate otklanjati ranjivosti i osigurati sigurnosne zakrpe. Ono se temelji na očekivanom korisnom vijeku trajanja proizvoda i mora biti otkriveno kupcima u trenutku kupnje (članak 13. stavak 8. Zakona o računalnoj zlouporabi; Smjernice, str. 42 i dalje). Stoga je to također pitanje prodaje i obračuna troškova, a ne samo tehničko razmatranje.

Značajna promjena pokreće ponovnu procjenu razdoblja podrške, ali ne dovodi automatski do toga da ono počne ispočetka ili se produži. Odlučujući čimbenik je utječe li promjena na čimbenike koji su izvorno odredili očekivani korisni vijek trajanja. Ako oni ostaju isti, preostalo razdoblje izvorne rokotrajnosti jednostavno se nastavlja računati za modificirani proizvod (Napomena za smjernice, str. 44 i nadalje).

Dvije dodatne pojašnjenja vrijedi napomenuti. Petogodišnji je razdoblje minimum, a ne standard, budući da se, gdje se može očekivati dulji korisni vijek trajanja, razdoblje treba primjereno odrediti. Nadalje, u slučaju iterativno razvijanog softvera, svaka verzija puštena na tržište mora imati vlastito objavljeno razdoblje podrške. Iako članak 13. stavak 10. CRA dopušta otklanjanje ranjivosti samo u trenutačnoj verziji, to je dopušteno samo ako je nadogradnja dostupna besplatno i bez dodatnih troškova. Prema smjernicama, to ne obuhvaća ništa što nadilazi ono što je uobičajeno za ažuriranja softvera, kao što su prisilne kupnje novog hardvera (Smjernice, str. 42. i dalje).

7. Osnovna funkcionalnost i modularni proizvodi

Klasifikacija kao bitan ili kritičan proizvod (članci 7. i 8. u skladu s Prilozima III i IV CRA) temelji se na osnovnoj funkcionalnosti proizvoda u cjelini. Tehnički opisi kategorija mogu se pronaći u Provedbena uredba (EU) 2025/2392. Put prema usklađenosti ovisi o klasifikaciji. Standardni proizvodi mogu se procjenjivati interno; kritični proizvodi klase I mogu se procjenjivati interno samo ako se u potpunosti primjenjuje relevantan harmonizirani standard, zajednička specifikacija ili europski sustav certificiranja kibernetičke sigurnosti. Za proizvode klase II i kritične proizvode mora biti uključeno vanjsko tijelo (Smjernice, str. 47 i nadalje i str. 52 i nadalje).

Dodatne funkcije koje samo nadopunjuju ili proširuju osnovnu funkcionalnost ne mijenjaju klasifikaciju. Ni integracija komponente više klase nema utjecaja na klasifikaciju. Stoga pametni telefon koji sadrži operativni sustav sam po sebi nije operativni sustav. Za potrebe odabira postupka ocjenjivanja sukladnosti proizvodu se dodjeljuje jedna osnovna funkcionalnost, koja mora biti navedena u tehničkoj dokumentaciji. Potrebna je opreznost kod modularnih platformi. Moduli sa vlastitom funkcionalnošću, koji se mogu zasebno kupiti, licencirati ili pretplatiti na njih, neovisni su proizvodi i moraju se zasebno klasificirati (Smjernice, stranice 47. i dalje).

8. Zahtjevi za izvještavanje: spremni li za 11. rujna 2026.?

Od 11. rujna 2026., Obveze izvještavanja u skladu s člankom 14. CRA-e za aktivno iskorištavane ranjivosti i ozbiljne sigurnosne incidente. Izvještaji se podnose jednokratno putem Jedinstvena platforma za izvještavanje ENISA-e. Obavijest se istovremeno šalje relevantnom CSIRT-u – odnosno nadležnom nacionalnom timu za hitne računalne intervencije imenovanom koordinatorom za lokaciju sjedišta – i ENISA-i. Nije potrebno dodatno izvještavanje prema CRA. Obveze izvještavanja prema drugim zakonima, kao što su NISG 2026 ili članak 33. GDPR-a, ostaju nepromijenjene (Smjernice, str. 74 i nadalje).

Raspored je zbijen. Rano upozorenje mora biti izdano u roku od 24 sata od utvrđivanja problema; daljnje informacije moraju uslijediti u roku od 72 sata; konačno izvješće mora biti podneseno najkasnije 14 dana nakon što korektivna mjera postane dostupna u slučaju ranjivosti, a u roku od mjesec dana u slučaju sigurnosnih incidenata (članak 14. stavci 2. do 4. CRA).

Smjernice pojašnjavaju područje primjene u nekoliko aspekata. Obveze također obuhvaćaju proizvode stavljene na tržište prije 11. rujna 2026. i nastavljaju se primjenjivati nakon završetka razdoblja podrške. CRA ne zahtijeva retrospektivno izvještavanje o ranjivostima koje su bile već poznate i iskorištene prije zaključnog datuma; međutim, zahtijeva se izvještavanje ako se ranjivost iskorištava ili postane poznata tek nakon tog datuma (Smjernice, str. 78 i nadalje). U slučaju ranjivosti u komponentama trećih strana, proizvođač krajnjeg proizvoda obvezan ih je prijaviti samo ako se ranjivost aktivno iskorištava u njegovom proizvodu. Obveze u vezi s otklanjanjem ranjivosti i izvješćivanjem nadređenog dobavljača ostaju nepromijenjene (Članak 13. stavak 6. Zakona o sigurnosti računalnih sustava; Smjernice, str. 77). Pružanje informacija korisnicima prema članku 14. stavku 8. Zakona o sigurnosti računalnih sustava mora biti utemeljeno na riziku i proporcionalno. Ne zahtijeva se nefiltrirano objavljivanje tehničkih detalja ako bi to povećalo rizik.

Ovo možete riješiti u samo nekoliko koraka. Postavite EU Login račun za registraciju, Smjernice ENISA-e Prođite kroz postupke registracije i izvještavanja, identificirajte relevantni CSIRT i uspostavite interni proces eskalacije tako da se 24-satni rok ispuni čak i u petak navečer. Tko god pristupi platformi tek kad se incident dogodi, izgubit će upravo one sate koji čine taj rok.

Zaključak i sljedeći koraci

Vodič je više od samog uredničkog ažuriranja. Mnogo je bliže usklađen s realnostima suvremenog razvoja softvera i industrijskih sustava nego nacrt iz proljeća 2026. Nije obvezujući. Tko odstupi od njega, sam po sebi ne djeluje nezakonito, ali snosi teret dokazivanja pred tijelima tržišnog nadzora i obaviještenim tijelima. Proizvođači stoga trebaju redefinirati opseg lokalno izvršenog softvera i web-aplikacija, uvesti dokumentiranu procjenu ekvivalentnosti svojstava relevantnih za kibernetičku sigurnost za rezervne dijelove, odrediti razdoblja podrške za svaku verziju i u pisanom obliku utvrditi postupak za značajne promjene. U suprotnom, opći savjet ostaje isti: pregledajte svoje lance opskrbe i komponente otvorenog koda te uspostavite robusne procese izvještavanja za 11. rujna 2026.

Često postavljana pitanja (FAQs)

Jeste li spremni za CRA?

ATB.LAW vam pomaže u uspostavljanju i održavanju usklađenosti s CRA, pregledava vaše ugovore i djeluje kao vaš partner u svim pitanjima vezanim uz digitalno pravo EU. Molimo kontaktirajte Stefan Knotzer i Roman Taudes u bilo kojem trenutku u office@atb.law ili telefonom na 01 39 12345 za besplatne početne konzultacije.