CRA ukratko: Kibernetička sigurnost postaje zahtjev za proizvod

CRA čini kibernetičku sigurnost sastavnim dijelom proizvoda. Svako ko stavlja 'proizvod s digitalnim elementima' na tržište EU mora ga projektovati i razviti na siguran način, osigurati ažuriranja sigurnosti tokom cijelog očekivanog vijeka trajanja, provesti upravljanje ranjivostima, procijeniti i dokumentovati usklađenost sa strogim zahtjevima CRA za kibernetičku sigurnost (ili da se ona procijeni) i postaviti CE oznaku na proizvod. CRA se time oslanja na poznate alate zakonodavstva EU o proizvodima i proširuje ih tako da obuhvataju i kibernetičku sigurnost.

Ovo obuhvata i hardver i softver u jednakoj mjeri, od usmjerivača i industrijskih kontrolnih sistema do desktop aplikacija, mobilnih aplikacija i unaprijed instaliranog firmvera. Ključni faktor je definicija u članku 3. stavku 1. CRA – proizvod čija namijenjena svrha ili razumno predvidljiva upotreba uključuje izravnu ili neizravnu podatkovnu vezu s uređajem ili mrežom (Smjernica, str. 8, odjeljak 17 i nadalje). Glavni teret pada na proizvođače. Uvoznici i distributeri imaju vlastite, postupno određene obaveze verifikacije.

Zanimljivo je da se CRA ne odnosi isključivo na fizičke proizvode. Svako ko 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.

Obaveze stupaju na snagu u fazama. CRA je stupio na snagu 10. decembra 2024.; tijela za ocjenu usklađenosti mogu biti imenovana od 11. juna 2026.; obaveze izvještavanja počinju 11. septembra 2026.; i Uredba će se u potpunosti primjenjivati od 11. decembra 2027.

Okvir sankcija je (što neće iznenaditi nikoga ko u posljednjih nekoliko godina nije potpuno ignorisao zakonodavstvo o digitalnim pravima) ponovo značajan: U slučaju kršenja osnovnih zahtjeva za kibernetičku sigurnost predviđene su novčane kazne do 15 miliona eura ili 2,5 posto globalnog godišnjeg prometa (član 64 CRA).

CRA kao gradivni blok digitalnog prava EU

EU regulira kibernetičku sigurnost na više nivoa. CRA je dio šire strategije za jačanje otpornosti preduzeća i potrošača u EU i njihovu zaštitu od kibernetičkih napada. Regulatorni okvir se može ugrubo opisati na sljedeći način:

Pored CRA, prvo treba spomenuti Direktivu NIS 2. Provedena u Austriji putem NISG-a 2026, ovaj režim se primjenjuje na organizacije u određenim kritičnim sektorima. Svako ko posluje u obuhvaćenom sektoru mora provesti specifične mjere upravljanja rizikom i prijaviti incidente. CRA i NISG 2026 se lako mogu primjenjivati paralelno: industrijsko preduzeće može biti i organizacija prema NISG 2026 i proizvođač prema CRA, sa 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 ličnih podataka;
• Propis o vještačkoj inteligenciji, prema kojem se zahtjevi za kibernetičku sigurnost za AI sisteme visokog rizika smatraju ispunjenim putem usklađenosti sa CRA pod određenim uslovima (član 12. CRA);
• nova Direktiva o odgovornosti za proizvode, koja izričito obuhvata softver kao proizvod i bavi se neosiguravanjem sigurnosnih ažuriranja; i
• sektorski specifični režimi kao što je DORA u finansijskom sektoru.

U okviru ovog okvira, CRA premošćuje jaz na nivou proizvoda: osigurava da proizvodi i usluge koje organizacije kupuju i koriste zadovoljavaju minimalne sigurnosne standarde, čime kibernetička sigurnost postaje ključni faktor pri nabavci i predmet ugovornog dogovora.

Nove smjernice CRA: neobavezujuće, ali autoritativne

Rad je objavljen 27. jula 2026. kao Prilog komunikaciji C(2026) 5252 Objavljeno. Obuhvata oko 80 stranica i oslanja se na brojne praktične primjere, slučajeve upotrebe i dijagrame toka. U usporedbi s konzultacijskim nacrtom od početka marta 2026. godine, konačna verzija je detaljnija i u nekoliko aspekata primjetno proporcionalnija. Objavljene smjernice nisu pravno obavezujuće; samo Sud pravde Evropske unije (ECJ) može dati obavezujuću interpretaciju CRA. Ipak, u praksi je to najvažnija referentna tačka, jer će je nadležni organi za nadzor tržišta i notificirana tijela koristiti kao vodič. Pored toga, Evropska komisija održava kontinuirano ažuriranu Dokument s najčešćim pitanjima o provedbi CRA Spremno.

Saželi smo tačke relevantne za preduzeća i iznijeli praktične implikacije svake od njih.

1. Softver, web aplikacije i web stranice

Kada softver, kao samostalni proizvod, spada u obuhvat CRA? Smjernice se fokusiraju na mjesto izvršavanja. Softver koji je dostupan korisnicima i koji se lokalno izvršava na njihovim sistemima predstavlja "proizvod s digitalnim elementima" u smislu člana 3. stavka 1. CRA. Ovo se odnosi na preuzimanja i instalirane klijente, kao i na ekstenzije preglednika i aplikacije razvijene korištenjem web tehnologija, ali koje se izvršavaju lokalno (Smjernice, stranica 8, stavak 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 važi i za web stranice koje pružaju isključivo informacije (Smjernica, str. 8, odjeljak 21, s pozivom na uvodne izjave 11. i 12. CRA). Takav softver je obuhvaćen samo ako je neophodan kao "rješenje za daljinsku obradu podataka" ("RDPS"; uporedi član 3. stav 2. CRA i odmah u nastavku) za funkciju drugog proizvoda.

Evropska komisija definira opseg još detaljnije. Definicija obuhvata one module koji su odgovorni za funkcionalnost proizvoda, uključujući interfejse koje koriste. Dalje, back-end sistemi s kojima proizvod ne komunicira direktno ne smatraju se RDPS (Smjernice, str. 63 i dalje). Ovo je od značajne praktične važnosti za pružatelje SaaS usluga. Svako ko isključivo koristi rješenje zasnovano na pregledniku, samim tim ne postaje proizvođač u smislu CRA. Međutim, svako ko također isporučuje paket za instalaciju, dodatak (plug-in), agenta ili desktop aplikaciju zaista postaje proizvođač – i to posebno za tu komponentu.

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 upotrebu unutar Unije. Varijante koje se razlikuju po komponentama, konfiguraciji ili omogućenim funkcionalnostima, međutim, smatraju se odvojenim proizvodima sa vlastitim referentnim datumom (Smjernice, stranica 7, stavak 14). To ima direktan utjecaj na upravljanje verzijama i izdanjima.

2. Daljinska obrada podataka: Gdje je granica?

CRA pokriva ne 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, kao i primjerima upotrebe koji se kreću od aplikacija za mobilno bankarstvo do industrijskih robota (vodič, str. 63 i dalje; za primjere upotrebe, str. 70 i dalje).

Pitanja za ispit su sljedeća:

1. Da li se podaci obrađuju na daljinu?
2. Da li bi 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 servisi koje pružaju treće strane, a koje proizvođač samo koristi, prema smjernicama se u principu 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 i podliježu dužnosti pažnje propisanoj u članku 13. stavku 5. CRA (Smjernice, str. 68 i dalje). Za proizvođače, to znači pregled ugovora i odnosa, uključujući one sa takvim uslugama, unutar lanca snabdijevanja.

3. Rezervni dijelovi: funkcionalna analiza, rigoroznija kontekstualna verifikacija

CRA se također bavi pitanjem rezervnih dijelova. Svaka komponenta koja sadrži digitalne elemente i koja se pojedinačno stavlja na tržište, u principu 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(6) CRA stoga izuzima rezervne dijelove koji zamjenjuju identične komponente i koji su proizvedeni prema istim specifikacijama (vidi također uvodna izjava 29 CRA). U praksi, obim ovog izuzeća određuje da li se rezervni dio može isporučiti bez daljnjih formalnosti ili da li predstavlja zaseban slučaj u skladu sa CRA.

Smjernice tumače izuzeće za rezervne dijelove fleksibilno i time, u principu, 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 je funkcionalna uloga i karakteristike relevantne za kibernetičku sigurnost (Smjernice, str. 32, odjeljak 99). Manja odstupanja stoga ostaju 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, odjeljak 100). U takvim slučajevima novi rezervni dio mora se tretirati kao zaseban proizvod koji sadrži digitalne elemente.

Kontekst je također ključni faktor. Dio se mora isporučiti posebno za popravak ili za produženje vijeka trajanja identificiranog proizvoda ili porodice proizvoda; tehnička kompatibilnost sama po sebi nije dovoljna. Svrha popravke mora biti očigledna iz okolnosti isporuke – na primjer, iz narudžbe, ponude ili kanala poslije prodaje – a dokaze koji to potvrđuju potrebno je sačuvati u svrhu nadzora tržišta (Smjernice, str. 31 i dalje, st. 97). Čak i kompletan proizvod koji je integriran u veći sistem – kao što je programabilni logički kontroler u sistemu automatizacije – može podlijegati izuzeću (Smjernice, stranica 33, stavak 102).

4. Besplatan i softver otvorenog koda (FOSS)

Softver otvorenog koda predstavlja CRA-u osnovni problem. Uredba povezuje svoje obaveze s stavljanjem na tržište kao dijela komercijalne djelatnosti. Međutim, veliki dio softvera otvorenog koda nastaje bez ikakve prodajne transakcije; on se objavljuje, a ne prodaje. Stoga se uputni dokument bavi tim pitanjem u tri koraka i posvećuje mu jedan od svojih najdužih odjeljaka – oko 14 stranica (Uputni dokument, str. 16 i dalje).

Prvi korak odnosi se na definiciju. Prema članu 3(48) CRA, samo se softver koji kumulativno ispunjava dva uslova smatra FOSS-om: licenciran je pod slobodnom i otvorenom licencom koja daje sva prava pristupa, korištenja, izmjene i redistribucije, i njegov izvorni kod je javno dostupan. Ako je izvorni kod dostupan samo plaćajućim korisnicima ili ograničenoj grupi, to ne predstavlja FOSS u smislu CRA, uprkos tome što ima slobodnu licencu (Smjernice, str. 17, stav 44 i dalje).

Drugi korak je razjasniti ko je odgovoran za softver. To se odnosi na osobu koja ga objavljuje i donosi odluke o njegovom razvoju, izdanjima i distribuciji; u praksi je to stoga 'održavatelj' (za definiciju ovog pojma pogledajte Vodič, stranica 18, stavak 49). Svako ko samo doprinosi kodom ostaje doprinosilac i nije podložan nikakvim obavezama CRA – čak i ako ima prava commitovanja. Tehničke ovlasti same po sebi ne utvrđuju odgovornost (Smjernice, stranica 18, fusnota 49 i Recital 18 CRA).

Treći korak je komercijalna aktivnost. Svako ko naplaćuje cijenu za sam softver – na primjer, za unaprijed kompajlirane binarne datoteke – stavlja ga na tržište i stoga je proizvođač (Smjernica, stranica 18, stav 51). Isto se primjenjuje i kada se drugi proizvodi ili usluge monetiziraju putem slobodnog softvera, na primjer putem oglašavanja, provizija ili pretplata, ili kada je njegova upotreba povezana s obradom ličnih podataka u svrhe koje nisu poboljšanje sigurnosti, kompatibilnost ili interoperabilnost (Smjernice, stranica 19, stavak 54).

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

Tretman dvostrukih modela je zapažen. Community Edition ostaje samostalni, nekomercijalni proizvod, čak i ako isti pružatelj izgradi plaćeno izdanje na istom kodu ili ga uključi u veći proizvod. Procjena se vrši za svaki proizvod pojedinačno, a ne na osnovu poslovnog modela u cjelini (Smjernice, str. 19, st. 52). Međutim, ako je pružatelj pravno lice, podliježe obavezama održavatelja softvera otvorenog koda u pogledu besplatne verzije (Smjernice, stranica 19, stavak 53).

Za projekte koji se ne stavljaju na tržište, CRA prepoznaje zasebnu ulogu sa smanjenim obavezama. "Staratelj softvera otvorenog koda" (član 3. stavak 14. CRA) je pravno lice koje pruža dugoročnu podršku FOSS-u bez komercijalizacije, na primjer putem hostinga, upravljanja ili vlastitih razvojnih resursa. Podliježe samo obavezama propisanim člankom 24. CRA, a obim obaveza izvještavanja, prema članku 24. stavku 3. CRA, ovisi o prirodi pružene podrške. Oni koji pružaju isključivo netehničku podršku, kao što su brendiranje, pravila upravljanja ili rad sa zajednicom, nisu podložni nikakvoj obavezi izvještavanja. Oni koji pružaju IT infrastrukturu projekta moraju prijaviti ozbiljne incidente koji utječu na tu infrastrukturu u skladu sa članom 14. stav 3. CRA. Samo oni koji doprinose vlastitim razvojnim resursima – na primjer, putem upravljanja izdanjima ili obrade izvještaja o ranjivostima – također su obavezni prijaviti aktivno iskorištene ranjivosti u skladu s članom 14. stavkom 1. CRA (Smjernice, str. 25 i dalje, odjeljak 79 i dalje). Tipičan primjer je fondacija koja stoji iza velikog projekta.

Za kompanije koje samo koriste komponente otvorenog koda, situacija ostaje jednostavna. Svako ko integriše FOSS u svoj proizvod time ne postaje proizvođač te komponente. Međutim, oni ostaju odgovorni za vlastiti proizvod, dužni su postupati s dužnom pažnjom prema članu 13(5) CRA i moraju prijaviti ranjivosti u integriranim komponentama te proslijediti sigurnosne zakrpe projektu (član 13(6) CRA; Smjernice, str. 26, odlomak 86 i sl.).

5. Ažuriranja i značajne promjene

Softver se neprestano razvija. CRA stoga mora utvrditi kada ažuriranje zakonski predstavlja novi proizvod. Za to se koristi pojam "značajna promjena" kako je definisano u članu 3(30) CRA, tj. promjena napravljena nakon stavljanja uređaja na tržište koja ili utiče na usklađenost sa suštinskim zahtjevima navedenim u Prilogu I, dio 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. Svako ko značajno izmijeni i stavi na raspolaganje proizvod treće strane postaje proizvođač (čl. 21 i 22 CRA), kao i svako ko značajno izmijeni proizvod stavljen na tržište prije 11. decembra 2027. nakon tog datuma (Član 69(2) CRA; Smjernice, stranica 30, fusnota 91).

Kriterij je nivo rizika, a ne tehnički obim. Ažuriranje sigurnosti, kao pravilo, ne predstavlja materijalnu promjenu, čak i ako unosi duboke izmjene u kod (ErwGr 39 CRA; Smjernice, str. 36, odjeljak 108). Suprotno tome, može biti dovoljna i mala funkcija. Smjernice navode kao primjer funkciju "Zapamti me" koja lokalno pohranjuje tokene za prijavu: tehnički neznatna, ali predstavlja nove rizike krađe tokena i preuzimanja sesije, te stoga predstavlja materijalnu promjenu (Smjernice, str. 35, Primjer 44).

Dokument sa smjernicama postavlja četiri pitanja koja se mogu koristiti za vođenje procjene (Smjernice, stranica 37, stavak 110). Da li ažuriranje uvodi nove vektore napada, kao što su dodatni interfejsi, komunikacijski kanali ili vanjske zavisnosti? Da li omogućava nove scenarije napada? Da li mijenja vjerovatnoću već poznatih scenarija? Ili mijenja njihov utjecaj? Ako je odgovor 'ne' u svim slučajevima i pretpostavke na kojima se zasniva procjena rizika ostaju važeće, općenito nema materijalne promjene.

Jedno pojednostavljenje se često previdi 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, fusnota 106, uključujući primjere 42 i 43). Uključivanje planiranih značajki iz razvojne mape u procjenu rizika u ranoj fazi štedi na poslovima usklađenosti kasnije.

Posljedice su proporcionalnije nego u nacrtu. Ako originalni proizvođač izvrši modifikaciju, on ostaje proizvođač, ali može nastaviti koristiti postojeće testove i dokumentaciju za nemodificirane aspekte i usmjeriti ocjenu sukladnosti na modificirane dijelove (Smjernice, str. 40 i dalje.). Ako treća strana značajno izmijeni proizvod i učini ga dostupnim, obaveze proizvođača prema članu 22. CRA-e uglavnom se odnose samo na izmijenjeni dio, osim ako izmjena ne utječe na cjelokupnu kibernetičku sigurnost proizvoda (Smjernice, str. 39 i dalje).

Komisija je time ublažila tumačenje izneseno u nacrtu, prema kojem bi značajna izmjena proizvoda stavljenog na tržište prije datuma stupanja na snagu uvijek zahtijevala da se cijeli proizvod dovede u potpunu usklađenost s CRA. To ne utječe na činjenicu da se značajno izmijenjeni proizvod smatra novostavljenim 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. (Član 13(7) i član 31(2) CRA; Napomena, stranica 38, fusnota 113).

U svakodnevnoj praksi mogu se razlikovati tri scenarija. Ispravka greške ili sigurnosno ažuriranje 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 samo ponovnu procjenu izmijenjenih dijelova i ne pokreće automatski ponovno razdoblje podrške. Zamjenski dio bez promjena u svojstvima relevantnim za kibernetičku sigurnost ostaje izvan opsega CRA prema članu 2(6) CRA, pod uslovom da se može potvrditi kontekst popravke.

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

Period podrške je razdoblje tokom kojeg morate otkloniti ranjivosti i obezbijediti sigurnosne zakrpe. Temelji se na očekivanom korisnom vijeku trajanja proizvoda i mora biti otkriven kupcima u trenutku kupovine (član 13(8) Zakona o računarskim resursima; 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 perioda podrške, ali ne dovodi automatski do njegovog ponovnog početka ili produženja. Odlučujući faktor je da li promjena utiče na faktore koji su prvobitno odredili očekivani rok trajanja. Ako oni ostanu isti, preostali dio prvobitnog perioda jednostavno se nastavlja računati za modificirani proizvod (Napomena za smjernice, str. 44 i dalje).

Dvije dodatne pojašnjenja vrijedi napomenuti. Petogodišnji period je minimum, a ne standardna vrijednost; gdje se može očekivati duži korisni vijek trajanja, period treba odgovarajuće prilagoditi. Nadalje, u slučaju softvera razvijanog iterativno, svaka verzija puštena na tržište treba imati vlastiti deklarisani period podrške. Iako član 13. stavak 10. CRA dopušta da se ranjivosti otklanjaju samo u tekućoj verziji, to je dozvoljeno samo ako je nadogradnja dostupna besplatno i bez dodatnih troškova. Prema smjernicama, ovo ne uključuje ništa što prelazi uobičajeno za ažuriranja softvera, kao što je obavezna kupovina novog hardvera (Smjernice, str. 42 i dalje).

7. Osnovna funkcionalnost i modularni proizvodi

Klasifikacija kao suštinski ili kritični 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 ka usklađenosti ovisi o klasifikaciji. Standardni proizvodi mogu se ocjenjivati interno; proizvodi kritične klase I mogu se ocjenjivati interno samo ako se u potpunosti primjenjuje relevantni harmonizirani standard, zajednička specifikacija ili europski sustav certifikacije kibernetičke sigurnosti. Za proizvode klase II i kritične proizvode mora biti uključeno vanjsko tijelo (Smjernice, stranice 47 i dalje i stranice 52 i dalje).

Dodatne funkcije koje samo dopunjuju 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 sistem sam po sebi nije operativni sistem. Za potrebe odabira postupka ocjenjivanja usklađenosti, proizvodu se dodjeljuje jedna osnovna funkcionalnost, koja mora biti navedena u tehničkoj dokumentaciji. Potrebna je opreznost u slučaju modularnih platformi. Moduli sa vlastitom funkcionalnošću koji se mogu zasebno kupiti, licencirati ili pretplatiti se na njih predstavljaju samostalne proizvode i moraju se zasebno klasificirati (Smjernice, stranice 47 i dalje).

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

Od 11. septembra 2026. godine, Obaveze izvještavanja u skladu sa članom 14. CRA za aktivno iskorištene ranjivosti i ozbiljne sigurnosne incidente. Izvještaji se podnose jednokratno putem Jedinstvena platforma za izvještavanje ENISA-e. Obavještenje se istovremeno šalje relevantnom CSIRT-u – odnosno nadležnom nacionalnom timu za hitne računalne intervencije imenovanom za koordinatora za lokaciju sjedišta – i ENISA-i. Nije potrebno dodatno izvještavanje prema CRA. Obaveze izvještavanja prema drugim zakonima, kao što su NISG 2026 ili član 33. GDPR-a, ostaju nepromijenjene (Smjernice, str. 74 i dalje).

Vremenski raspored je vrlo kratak. Rano upozorenje mora biti izdano u roku od 24 sata od otkrivanja problema; dodatne informacije moraju biti dostavljene u roku od 72 sata; konačni izvještaj mora biti podnesen najkasnije 14 dana nakon što korektivna mjera postane dostupna u slučaju ranjivosti, a u roku od mjesec dana u slučaju sigurnosnih incidenata (član 14. stavci 2. do 4. CRA).

Smjernice pojašnjavaju područje primjene u nekoliko aspekata. Obaveze također obuhvataju proizvode stavljene na tržište prije 11. septembra 2026. i nastavljaju se primjenjivati nakon završetka perioda podrške. CRA ne zahtijeva retrospektivno izvještavanje o ranjivostima koje su već bile poznate i iskorištavane prije datuma prekida; međutim, zahtijeva se izvještavanje ako se iskorištavanje tek dogodi ili postane poznato nakon tog datuma (Smjernice, str. 78 i dalje). U slučaju ranjivosti u komponentama trećih strana, proizvođač krajnjeg proizvoda je obavezan da ih prijavi samo ako se ranjivost aktivno iskorištava u njegovom proizvodu. Obaveze u vezi s otklanjanjem ranjivosti i izvještavanjem gornjeg dobavljača ostaju nepromijenjene (Član 13(6) CRA; Smjernice, str. 77). Dostavljanje informacija korisnicima prema članu 14(8) CRA mora biti zasnovano na riziku i proporcionalno. Ne zahtijeva se nefiltrirano otkrivanje tehničkih detalja ako bi to povećalo rizik.

Možete ovo riješiti u samo nekoliko koraka. Postavite EU Login račun za registraciju, Smjernice ENISA-e Prođite kroz procedure 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. Svako ko pristupi platformi tek kad se incident dogodi, izgubit će upravo one sate koji čine taj rok.

Zaključak i sljedeći koraci

Dokument sa smjernicama je više od pukog uredničkog ažuriranja. Mnogo je bliže usklađen sa stvarnošću modernog razvoja softvera i industrijskih sistema nego nacrt iz proljeća 2026. godine. Nije obavezujući. Svako ko odstupa od njega ne djeluje po sebi nezakonito, ali snosi teret dokazivanja pred nadležnim tijelima za nadzor tržišta i notificiranim tijelima. Proizvođači stoga trebaju redefinirati obuhvat lokalno izvršenog softvera i web aplikacija, uvesti dokumentiranu procjenu ekvivalencije svojstava relevantnih za kibernetičku sigurnost za rezervne dijelove, specificirati periode 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 snabdijevanja i komponente otvorenog koda i uspostavite robusne procese izvještavanja za 11. septembar 2026. godine.

Č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 za digitalno pravo EU. Molimo kontaktirajte Stefan Knotzer i Roman Taudes u bilo koje vrijeme na office@atb.law ili telefonom na 01 39 12345 za besplatnu početnu konsultaciju.