Akt o kibernetičkoj otpornosti (CRA) 2026.–2027.: što već znamo, što još nedostaje i kako se realno pripremiti za proizvod — prije nego što se pojave usklađene norme

Što danas sigurno znamo (i zašto to nije „tema za 2027.”)

Cyber Resilience Act može izgledati kao još jedan dokument „iz Bruxellesa” koji se može ostaviti za kasnije. To je prirodna reakcija, osobito ako tvrtka radi u ritmu projekata: prototip, uvođenje, serijska proizvodnja, servis. Propisi često dolaze kao „završni zahtjev” — nešto što se zatvara na samom kraju. CRA mijenja tu logiku jer se ne odnosi samo na ono što je vidljivo u proizvodu na dan prodaje. Odnosi se na to može li proizvođač održavati sigurnost proizvoda tijekom vremena i dokazati da je to učinio svjesno, a ne slučajno.

Najvažnija činjenica je jednostavna, ali ima strateške posljedice: CRA je propis o proizvodu, utemeljen u mehanici tržišta EU (uključujući oznaku CE). Europska komisija izričito navodi da proizvodi trebaju nositi oznaku CE kao signal usklađenosti s CRA-om, a provedba je u nadležnosti tijela za nadzor tržišta. To, dakle, nije „IT standard” koji se može tretirati kao interni program poboljšanja. To je okvir koji utječe na mogućnost prodaje.

Datumi koji pomažu posložiti razmišljanje

U samom tekstu Uredbe (EU) 2024/2847 vidi se postupna primjena. CRA se primjenjuje od 11. prosinca 2027., ali uz jasne iznimke. Članak 14. (izvješćivanje) primjenjuje se od 11. rujna 2026., a poglavlje o notifikaciji tijela za ocjenjivanje sukladnosti (Chapter IV) od 11. lipnja 2026.. To su tri datuma koje vrijedi promatrati kao „prekretnice”, jer odgovaraju trima različitim vrstama spremnosti: operativnoj, institucionalnoj i proizvodnoj.

Komisija to komunicira još jednostavnije: CRA je stupio na snagu 10. prosinca 2024., ključne obveze od 11. prosinca 2027., a izvješćivanje od 11. rujna 2026. Ako netko u tvrtki kaže „imamo vremena do 2027.”, najčešće misli na projektne zahtjeve i ocjenjivanje sukladnosti. No izvješćivanje je ranije i odnosi se na događaje koji ne čekaju raspored.

Izvješćivanje: obveza koja nameće proces (a ne dokument)

Zahtjev za izvješćivanjem dobar je lakmus-papir jer pokazuje kako CRA razumije „kibernetičku sigurnost proizvoda”. To nije izjava namjere niti „politika”. To je proces koji mora funkcionirati u stresnoj situaciji: kada se pojavi ranjivost koja se aktivno iskorištava ili ozbiljan incident.

Komisija to opisuje nedvosmisleno: proizvođač mora prijavljivati ranjivosti koje se aktivno iskorištavaju te ozbiljne incidente koji utječu na sigurnost proizvoda. Potreban je „early warning” u roku od 24 sata od saznanja, potpuno izvješće u roku od 72 sata, a završno izvješće: do 14 dana nakon dostupnosti mjere otklanjanja za ranjivosti koje se aktivno iskorištavaju te u roku od mjesec dana za ozbiljne incidente.

U praksi to znači da organizaciji treba nešto više od kontrolne liste. Treba joj mehanizam koji odgovara na tri pitanja: kako ćemo saznati da problem postoji; tko kvalificira je li to već „aktivno iskorištavano” ili „ozbiljno”; i kako ćemo organizirati komunikaciju i ispravak u vremenu koje ne ostavlja prostor za improvizaciju.

Ako se na edukacijama pojavi kaos, često je to zato što CRA pogađa prazninu između IT-a i proizvoda. Za IT „incident” može biti događaj u infrastrukturi. Za proizvođača „incident” je događaj koji pogađa proizvod kod kupca, verziju, konfiguraciju, način uvođenja. CRA prisiljava povezivanje tih svjetova u jednu odgovornost.

Što obuhvaća CRA: proizvod kao odnos s mrežom, a ne „uređaj na stolu”

U praksi smo se kroz procjene rizika strojeva učili da rizik nije svojstvo samog stroja — nastaje u odnosu čovjek–stroj. U CRA-u postoji sličan pomak perspektive: sigurnost ne postoji „u uređaju”, nego u odnosu proizvoda s digitalnim okruženjem, načinom uporabe i sposobnošću proizvođača da reagira.

Komisija, sažimajući CRA, skreće pozornost na definiciju „proizvoda s digitalnim elementima” te na to da se obveze izvješćivanja odnose na sve takve proizvode stavljene na raspolaganje na tržištu EU — uključujući i one uvedene prije 11. prosinca 2027. To je ključno pojašnjenje jer uklanja čest mit: „za stare proizvode to nije važno”. Izvješćivanje — jest.

Čega još nema (usklađenih normi) i zašto to ne bi trebalo paralizirati

W raspravama o CRA često se provlači rečenica: „još nema usklađenih normi, pa se ne može ništa napraviti”. Zvuči logično, ali u tome je skrivena zamka. Usklađene norme su alat koji olakšava dokazivanje sukladnosti (pretpostavka sukladnosti), ali nisu jedini put do stvarne sigurnosti proizvoda. I nisu preduvjet da se krene ispravno projektirati.

Komisija temu standarda izravno vodi kroz stranicu „CRA Standardisation” i navodi da je prihvatila standardisation request M/606, koji obuhvaća skup od 41 standarda koji podupiru CRA — i horizontalnih i vertikalnih (proizvodnih). To je važno jer pokazuje da EU razumije tržišni problem: bez standarda će tvrtke graditi sukladnost svaka na svoj način, a nadzor tržišta imat će teži posao.

Horizontalni i vertikalni standardi: što to znači za proizvođača

Pojednostavljeno:

• horizontalni standardi trebali bi opisivati „kako” izgraditi i održavati sigurnost proizvoda neovisno o kategoriji (procesi, metode, pristup temeljen na riziku),
• vertikalni standardi trebali bi precizirati zahtjeve za određene klase proizvoda (tamo gdje su rizici i arhitekture tipični).

Ova podjela ima praktične posljedice. Ako razvijaš industrijski proizvod u kojem je dio okruženja „OT” i životni ciklus je dug, trebat ćeš standarde koji nisu pisani za SaaS aplikaciju. I upravo zato vertikalni standardi imaju smisla: pomažu spustiti se s razine općih načela na to što konkretno kontrolirati u stvarnim arhitekturama.

Raspored rada: standardi će pristizati postupno, ne „u paketu prije 2027.”

Komisija u materijalima o provedbi CRA pokazuje da se CRA uvodi fazno, a standardi bi trebali s vremenom podupirati taj proces. Na razini činjenica koje su danas sigurne: imamo formalno usvojenu uredbu i imamo pokrenut mehanizam standardizacije (M/606).

Za praksu je najvažnije razumjeti jednu rečenicu: čak i kada organizacije za normizaciju izrade standard, „pretpostavka sukladnosti” u pravnom smislu nastaje tek kada se upućivanje na normu objavi kao usklađena norma u Službenom listu EU. To je mehanizam zajednički unijskom pristupu usklađivanju: standardi su most između prava i inženjerske prakse, ali taj most EU mora formalno „priznati”.

Iz perspektive proizvođača to znači da će 2026.–2027. biti razdoblje u kojem će dio tvrtki djelovati na temelju vlastitih metoda dokazivanja sukladnosti (risk-based + dokazi), a dio će se već mapirati na standarde koji se budu pojavljivali. I to je normalno.

„Nema normi” ne znači „nema obveze” — znači veću važnost dokaza

Ovdje se pojavljuje važna posljedica: ako nema normi koje daju najjednostavniji put dokazivanja sukladnosti, raste važnost onoga što je u revizorskoj praksi uvijek presudno: dosljedan trag odlučivanja.

Koje smo rizike procijenili? Koje smo scenarije uzeli kao realne? Kako smo odabrali zaštitne mjere? Kako upravljamo ranjivostima? Koliko dugo podržavamo proizvod? Kako informiramo kupca? CRA ne zahtijeva da proizvođač „pogađa buduće EN norme”. Zahtijeva da proizvođač može pokazati da njegove odluke nisu bile slučajne, nego utemeljene na riziku i stanju tehnike.

Kako se stvarno pripremiti za CRA (roadmapa za proizvođača i integratora)

Najveća vrijednost CRA je u tome što nameće zrelost: kibernetička sigurnost prestaje biti dodatak proizvodu i postaje njegovo svojstvo. Samo, zrelost ne nastaje iz deklaracija. Nastaje iz procesa koji je dovoljno precizan da funkcionira u praksi i dovoljno jednostavan da ga inženjering ne počne zaobilaziti.

U procjeni rizika strojeva najbolje projektne odluke pojavljuju se kada prestanemo pitati „koje opasnosti stroj ima”, a počnemo pitati „u kojim zadacima i stanjima je čovjek izložen”. Kod CRA analogno: prestajemo pitati „koje ranjivosti proizvod ima”, a počinjemo pitati „u kojim uvjetima proizvod postaje izložen i što proizvođač tada može učiniti”. Taj pomak uvodi red u posao.

Korak 1: Definiraj proizvod kao sustav (a ne kao uređaj)

Kreni od definiranja što je u tvom slučaju „proizvod s digitalnim elementima”. Ne samo hardver i firmver, nego i ono što se često preskače jer ne stane u kutiju: komponente, biblioteke, mehanizmi ažuriranja, usluge bez kojih proizvod ne ispunjava funkciju. U CRA je to važno jer se odgovornost proizvođača odnosi na ono što izlazi na tržište kao proizvod — a ne samo na ono što je izradio odjel mehanike.

To je i prvi trenutak u kojem integratori trebaju biti iskreni prema sebi: ako integriraš komponente i konfiguriraš ih na način koji u očima kupca stvara „konačni proizvod”, onda nisi samo „izvođač implementacije”. Su-kreator si rizika i su-kreator odgovornosti.

Korak 2: Napravi CRA procjenu rizika tako da bude alat za odlučivanje

Ne radi se o „matrici” na slajdovima. Radi se o procjeni rizika koja vodi do projektnih odluka i koja se može ponavljati na isti način.

U praksi dobar pristup CRA-u počinje jednostavnim pitanjem: koji su realni scenariji zlouporabe u okruženju korisnika, a ne samo u laboratoriju? Tko ima servisni pristup? Kako izgleda mreža? Koliko često ažuriramo? Koje su posljedice zastoja? U industriji su ta pitanja neugodnija nego u IT-u, jer odgovori često glase: „ne možemo ažurirati svaki tjedan” ili „nemamo telemetriju”. I upravo zato ih treba postaviti. CRA je zakonska obveza, ali njegove posljedice su projektne.

Korak 3: Izgradi “vulnerability handling” kao proizvodni proces, a ne kao kriznu reakciju

Zahtjevi izvještavanja koje je opisala Komisija (24h/72h/14 dana/mjesec) nemilosrdni su prema organizaciji koja nema proces. Ako želiš biti spreman za 11. rujna 2026., moraš “vulnerability handling” tretirati kao dio životnog ciklusa proizvoda, a ne kao „zadatak security tima”.

To znači:

• jedan kanal za zaprimanje prijava (CVD policy + kontakt),
• trijaža koja ima vlasnika i kriterije,
• mehanizam za izradu i isporuku security updates,
• model komunikacije prema korisnicima koji nije improvizacija,
• spremnost za izvještavanje (tko prijavljuje, s kojim podacima, koliko brzo).

Sve to zvuči kao „organizacijski” posao. U praksi je to posao na proizvodu, jer se tiče verzija, kompatibilnosti, arhitekture ažuriranja i strategije podrške.

Korak 4: Odaberi support period kao poslovnu odluku, a ne kao minimalni zahtjev

Ako tvoji proizvodi u industriji žive 10–15 godina, razdoblje podrške je strateška tema. CRA nameće da podrška ne bude obećanje bez pokrića. To znači da razdoblje podrške treba proizaći iz analize: koliko dugo će se proizvod koristiti, kako izgleda lanac opskrbe komponentama, koliko dugo ćeš moći isporučivati zakrpe. U praksi razdoblje podrške počinje „vući” cijeli ekosustav: ugovore s dobavljačima, dostupnost build environmenta, održavanje toolchainova, pa čak i odluke o tome ima li proizvod udaljene funkcije ili je izoliran.

Ako razdoblje podrške shvatiš kao formalnost, najkasnije 2027. upast ćeš u konflikt: korisnik očekuje podršku, a ti više nemaš ni resurse ni ovisnosti da je isporučiš. CRA ne stvara taj problem — CRA ga samo razotkriva.

Krok 5: Uredi lanac opskrbe: razgovor s dobavljačima je dio usklađenosti

U CRA-u nema „magije” koja će vanjske komponente učiniti sigurnima. Ako se tvoj uređaj oslanja na biblioteke, komunikacijske module, operacijski sustav, SDK ili hardverske komponente, tvoj rizik izravno ovisi o kvaliteti praksi dobavljača.

Zato već sada ima smisla otvoriti razgovor o stvarima koje ne zvuče kao marketing, nego kao inženjerstvo:

• može li dobavljač o ranjivostima informirati na predvidljiv način,
• kakvo mu je vrijeme reakcije,
• ima li proces objave zakrpa,
• može li održavati komponentu tijekom razdoblja koje je usklađeno s tvojim razdobljem podrške.

Ovdje CRA stvarno dotiče poslovanje: dobavljač koji ne zna upravljati ranjivostima nije „jeftiniji”. On je regulatorni rizik.

Krok 6: Izgradi dokumentaciju kao koherentan trag: pravo → rizik → odluka → dokaz

U auditima usklađenosti uvijek pobjeđuje dosljednost. Ako iz procjene rizika proizlazi da je određeno sučelje kritično, a dokumentacija ne opisuje kako ga štitiš; ako tvrdiš da su ažuriranja sigurna, a ne možeš pokazati kako osiguravaš integritet paketa; ako kažeš da imaš proces upravljanja ranjivostima, a ne možeš pokazati kako radiš trijažu prijava — to nije „nedostatak papira”. To je nedostatak dokaza da proces funkcionira.

U CRA-u, uz izostanak usklađenih normi, taj je trag posebno važan. Jer će on biti temelj razgovora s tijelom za nadzor tržišta, enterprise korisnikom, a u nekim kategorijama proizvoda i s tijelom za ocjenu sukladnosti. A jednako važno: on je temelj unutarnje stabilnosti. Tim zna zašto nešto radimo, a ne samo „da moramo”.

Zaključak: CRA kao novi projektni zahtjev, a ne „compliance projekt”

Kad bih trebao ostaviti jednu misao koja povezuje sva tri dijela: CRA nije problem koji se rješava na kraju. To je okvir koji mijenja način razmišljanja o proizvodu. Kao što ISO 12100 uči da rizik nastaje u odnosu čovjek–stroj, tako CRA uči da kibernetička sigurnost nastaje u odnosu proizvod–okruženje–životni ciklus proizvođača.

Usklađene norme će doći i pojednostaviti neke putanje. Ali njihov izostanak nije razlog za mirovanje. To je razlog da se usredotočiš na ono što CRA uvijek procjenjuje: na odluke, dokaze i sposobnost djelovanja u stvarnosti — ne u prezentaciji.