Kibernetinio atsparumo aktas (CRA) 2026–2027: ką jau žinome, ko dar trūksta ir kaip realiai parengti produktą – dar prieš pasirodant darniesiems standartams

Ką šiandien tikrai žinome (ir kodėl tai nėra „2027 m. tema“)

Cyber Resilience Act gali atrodyti kaip dar vienas „iš Briuselio“ dokumentas, kurį bus galima atidėti vėlesniam laikui. Tai natūrali reakcija, ypač jei įmonė gyvena projektų ritmu: prototipas, diegimas, serijinė gamyba, servisas. Reglamentai dažnai ateina kaip „galutinis reikalavimas“ – tai, ką užbaigiama finišo tiesiojoje. CRA keičia šią logiką, nes jis susijęs ne vien su tuo, kas matoma produkte pardavimo dieną. Jis susijęs su tuo, ar gamintojas geba užtikrinti produkto saugumą laikui bėgant ir įrodyti, kad tai padarė sąmoningai, o ne atsitiktinai.

Svarbiausias faktas paprastas, bet turintis strateginių pasekmių: CRA yra produktų reglamentas, įtvirtintas ES rinkos veikimo mechanikoje (įskaitant CE ženklinimą). Europos Komisija aiškiai nurodo, kad produktai turi turėti CE ženklą kaip atitikties CRA signalą, o vykdymo užtikrinimas tenka rinkos priežiūros institucijoms. Taigi tai nėra „IT standartas“, kurį galima traktuoti kaip vidinę tobulinimo programą. Tai sistema, kuri daro įtaką galimybei parduoti.

Datos, kurios padeda susidėlioti mąstymą

Pačiame Reglamento (ES) 2024/2847 tekste matyti laipsniškas taikymas. CRA taikomas nuo 2027 m. gruodžio 11 d., tačiau su aiškiomis išimtimis. 14 straipsnis (ataskaitų teikimas) taikomas nuo 2026 m. rugsėjo 11 d., o skyrius apie atitikties vertinimo įstaigų notifikavimą (Chapter IV) – nuo 2026 m. birželio 11 d.. Tai trys datos, kurias verta laikyti „kelrodžiais“, nes jos atitinka tris skirtingus pasirengimo tipus: operacinį, institucinį ir produktinį.

Komisija tai komunikuoja dar paprasčiau: CRA įsigaliojo 2024 m. gruodžio 10 d., esminės pareigos – nuo 2027 m. gruodžio 11 d., o ataskaitų teikimas – nuo 2026 m. rugsėjo 11 d. Jei kas nors įmonėje sako „turime laiko iki 2027-ųjų“, dažniausiai turi omenyje projektavimo reikalavimus ir atitikties vertinimą. Tačiau ataskaitų teikimas prasideda anksčiau ir susijęs su įvykiais, kurie nelaukia grafiko.

Ataskaitų teikimas: pareiga, kuri priverčia turėti procesą (o ne dokumentą)

Ataskaitų teikimo reikalavimas yra geras lakmuso popierėlis, nes parodo, kaip CRA supranta „produkto kibernetinį saugumą“. Tai nėra ketinimų deklaracija ar „politika“. Tai procesas, kuris turi suveikti stresinėje situacijoje: kai atsiranda aktyviai išnaudojama pažeidžiamumo spraga arba rimtas incidentas.

Komisija tai apibrėžia vienareikšmiškai: gamintojas turi pranešti apie aktyviai išnaudojamas pažeidžiamumo spragas ir severe incidents, darančius įtaką produkto saugumui. Reikalaujamas „early warning“ per 24 valandas nuo sužinojimo, pilnas pranešimas per 72 valandas, o galutinė ataskaita: per 14 dienų nuo tada, kai tampa prieinama taisymo priemonė aktyviai išnaudojamoms pažeidžiamumo spragoms, ir per mėnesį – severe incidents atveju.

Praktiškai tai reiškia, kad organizacijai reikia daugiau nei kontrolinio sąrašo. Reikia mechanizmo, kuris atsako į tris klausimus: iš kur sužinosime, kad problema egzistuoja; kas kvalifikuoja, ar tai jau „aktyviai išnaudojama“ arba „severe“; ir kaip suorganizuosime informacijos perdavimą bei pataisą per laiką, kuris nepalieka vietos improvizacijai.

Jei mokymuose atsiranda chaosas, dažnai todėl, kad CRA pataiko į spragą tarp IT ir produkto. IT požiūriu „incidentas“ neretai yra įvykis infrastruktūroje. Gamintojui „incidentas“ yra įvykis, paliečiantis produktą pas klientą: versiją, konfigūraciją, diegimo būdą. CRA verčia sujungti šiuos pasaulius į vieną atsakomybę.

Ką apima CRA: produktas kaip ryšys su tinklu, o ne „įrenginys ant stalo“

Praktikoje, mokantis mašinų rizikos vertinimo, supratome, kad rizika nėra pačios mašinos savybė – ji atsiranda žmogaus ir mašinos sąveikoje. CRA atveju perspektyva pasislenka panašiai: saugumas neegzistuoja „įrenginyje“, jis egzistuoja produkto santykyje su skaitmenine aplinka, naudojimo būdu ir gamintojo gebėjimu reaguoti.

Komisija, apibendrindama CRA, atkreipia dėmesį į „produktų su skaitmeniniais elementais“ apibrėžtį ir į tai, kad ataskaitų teikimo pareigos taikomos visiems tokiems produktams, pateiktiems ES rinkai, – taip pat ir tiems, kurie buvo pateikti iki 2027 m. gruodžio 11 d. Tai esminis patikslinimas, nes paneigia dažną mitą: „seniems produktams tai neaktualu“. Ataskaitų teikimas – aktualus.

Ko dar nėra (suderintųjų standartų) ir kodėl tai neturėtų paralyžiuoti

W diskusijose apie CRA dažnai kartojama frazė: „dar nėra suderintųjų standartų, vadinasi, nieko negalima daryti“. Skamba logiškai, tačiau čia slypi spąstai. Suderintieji standartai yra priemonė, palengvinanti atitikties įrodymą (atitikties prezumpcija), bet tai nėra vienintelis kelias sukurti realų gaminio saugumą. Ir tai nėra sąlyga, kad būtų galima pradėti projektuoti teisingai.

Komisija standartų temą tiesiogiai koordinuoja per puslapį „CRA Standardisation“ ir informuoja, kad priėmė standartizacijos užklausą M/606, apimančią 41 standartų rinkinį, palaikantį CRA — tiek horizontaliųjų, tiek vertikaliųjų (gaminio). Tai svarbu, nes parodo, kad ES supranta rinkos problemą: be standartų įmonės atitiktį kurs kiekviena savaip, o rinkos priežiūrai bus sunkiau.

Horizontalieji ir vertikalieji standartai: ką tai reiškia gamintojui

Supaprastintai:

• horizontalieji standartai turi aprašyti „kaip“ kurti ir palaikyti gaminio saugumą nepriklausomai nuo kategorijos (procesai, metodai, rizika grindžiamas požiūris),
• vertikalieji standartai turi patikslinti reikalavimus konkrečioms gaminių klasėms (ten, kur rizikos ir architektūros yra tipinės).

Šis skirtumas turi praktinių pasekmių. Jei kuri pramoninį gaminį, kuriame dalis aplinkos yra „OT“, o gyvavimo ciklas ilgas, tau reikės standartų, kurie nėra rašomi SaaS programai. Būtent todėl vertikalieji standartai yra reikšmingi: jie padeda nuo bendrųjų principų nusileisti iki to, ką kontroliuoti realiose architektūrose.

Darbų grafikas: standartai atsiras etapais, o ne „vienu paketu iki 2027“

Komisija CRA įgyvendinimo medžiagoje rodo, kad CRA diegiamas etapais, o standartai turi laike palaikyti šį procesą. Faktų lygmeniu, kas šiandien yra tikra: turime formaliai priimtą reglamentą ir turime paleistą standartizacijos mechanizmą (M/606).

Praktikai svarbiausia suprasti vieną sakinį: net kai standartą parengia standartizacijos organizacijos, „atitikties prezumpcija“ teisine prasme atsiranda tik tada, kai nuoroda į standartą paskelbiama kaip suderintasis standartas ES oficialiajame leidinyje. Tai bendra ES harmonizavimo požiūrio mechanika: standartai yra tiltas tarp teisės ir inžinerinės praktikos, tačiau šį tiltą ES turi formaliai „pripažinti“.

Gamintojo požiūriu tai reiškia, kad 2026–2027 m. bus laikotarpis, kai dalis įmonių veiks remdamosi savo atitikties įrodymo metodais (risk – based + įrodymai), o dalis jau siesis su atsirandančiais standartais. Ir tai yra normalu.

„Nėra standartų“ nereiškia „nėra pareigos“ — tai reiškia didesnę įrodymų svarbą

Čia atsiranda svarbi pasekmė: jei nėra standartų, suteikiančių paprasčiausią atitikties įrodymo kelią, didėja to, kas audito praktikoje visada lemia, reikšmė: nuoseklus sprendimų pėdsakas.

Kokias rizikas įvertinome? Kokius scenarijus laikėme realistiškais? Kaip parinkome apsaugos priemones? Kaip valdome pažeidžiamumus? Kiek laiko palaikome gaminį? Kaip informuojame klientą? CRA nereikalauja, kad gamintojas „spėliotų būsimas EN normas“. Reikalaujama, kad gamintojas gebėtų parodyti, jog jo sprendimai nebuvo atsitiktiniai, o pagrįsti rizika ir state of the art.

Kaip realiai parengti gaminį CRA (kelrodis gamintojui ir integratoriui)

Didžiausia CRA vertė yra ta, kad jis verčia bręsti: kibernetinis saugumas nustoja būti gaminio priedu ir tampa jo savybe. Tačiau branda neatsiranda iš deklaracijų. Ji gimsta iš proceso, kuris yra pakankamai tikslus, kad veiktų praktikoje, ir pakankamai paprastas, kad inžinerija nepradėtų jo apeidinėti.

Mašinų rizikos vertinime geriausi projektavimo sprendimai atsiranda tada, kai nustojame klausti „kokius pavojus turi mašina“, o pradedame klausti „kokiose užduotyse ir būsenose žmogus patiria poveikį“. CRA atveju analogiškai: nustojame klausti „kokius pažeidžiamumus turi gaminys“, o pradedame klausti „kokiomis sąlygomis gaminys tampa pažeidžiamas ir ką gamintojas tuomet gali padaryti“. Toks poslinkis sutvarko darbą.

1 žingsnis: apibrėžk gaminį kaip sistemą (o ne kaip įrenginį)

Pradėk nuo to, kad apibrėžtum, kas tavo atveju yra „gaminys su skaitmeniniais elementais“. Ne tik aparatinė įranga ir programinė aparatinė įranga (firmware), bet ir tai, kas dažnai praleidžiama, nes netelpa į dėžę: komponentai, bibliotekos, atnaujinimo mechanizmai, paslaugos, be kurių gaminys neatlieka funkcijos. CRA tai svarbu, nes gamintojo atsakomybė apima tai, kas patenka į rinką kaip gaminys — o ne vien tai, ką pagamino mechanikos skyrius.

Tai taip pat pirmas momentas, kai integratoriai turėtų būti sąžiningi patys sau: jei integruoji komponentus ir juos sukonfigūruoji taip, kad kliento akimis susidaro „galutinis gaminys“, tu nesi tik „diegėjas“. Tu esi rizikos bendraautoris ir atsakomybės bendraautoris.

2 žingsnis: atlik CRA rizikos vertinimą taip, kad jis būtų sprendimų priemonė

Ne kalbama apie „matricą“ skaidrėse. Kalbama apie rizikos vertinimą, kuris virsta projektavimo sprendimais ir yra pakartojamas.

Praktikoje geras požiūris į CRA prasideda nuo paprasto klausimo: kokie yra realūs piktnaudžiavimo scenarijai kliento aplinkoje, o ne tik laboratorijoje? Kas turi prieigą prie serviso? Kaip atrodo tinklas? Kaip dažnai atnaujiname? Kokios yra prastovos pasekmės? Pramonėje šie klausimai yra nepatogesni nei IT, nes atsakymai dažnai skamba taip: „negalime atnaujinti kas savaitę“ arba „neturime telemetrijos“. Ir būtent todėl juos reikia užduoti. CRA yra teisės aktas, tačiau jo pasekmės yra projektavimo lygmens.

Krok 3: Sukurk „vulnerability handling“ kaip gamybinį procesą, o ne kaip krizės reakciją

Komisijos aprašyti pranešimų teikimo reikalavimai (24h/72h/14 dienų/mėnuo) yra negailestingi organizacijai, kuri neturi proceso. Jei nori būti pasirengęs 11 rugsėjo 2026, turi „vulnerability handling“ traktuoti kaip produkto gyvavimo ciklo dalį, o ne kaip „security komandos užduotį“.

Tai reiškia:

• vienas kanalas pranešimams priimti (CVD policy + kontaktas),
• triage, kuris turi atsakingą asmenį ir kriterijus,
• security updates kūrimo ir pristatymo mechanizmas,
• komunikacijos su klientais modelis, kuris nėra improvizacija,
• pasirengimas teikti pranešimus (kas praneša, su kokiais duomenimis, kaip greitai).

Visa tai skamba kaip „organizacinis“ darbas. Praktikoje tai yra produkto darbas, nes jis susijęs su versijomis, suderinamumu, atnaujinimų architektūra ir palaikymo strategija.

Krok 4: Pasirink support period kaip verslo sprendimą, o ne minimalų reikalavimą

Jei tavo produktai pramonėje gyvuoja 10–15 metų, support period yra strateginis. CRA reikalauja, kad palaikymas nebūtų pažadas be realaus pagrindo. Tai reiškia, kad support period turi kilti iš analizės: kiek laiko produktas bus naudojamas, kaip atrodo komponentų tiekimo grandinė, kiek laiko galėsi teikti pataisas. Praktikoje support period pradeda „tempti“ visą ekosistemą: sutartis su tiekėjais, build environment prieinamumą, toolchainų palaikymą ir net sprendimus, ar produktas turės nuotolines funkcijas, ar bus izoliuotas.

Jei support period laikysi formalumu, vėliausiai 2027 pateksi į konfliktą: klientas tikisi palaikymo, o tu jau nebeturi nei resursų, nei priklausomybių, kad jį suteiktum. CRA šios problemos nesukuria — CRA ją tik atskleidžia.

Krok 5: Sutvarkyk tiekimo grandinę: pokalbis su tiekėjais yra atitikties dalis

CRA nėra jokios „magijos“, kuri padarytų išorinius komponentus saugius. Jei tavo įrenginys remiasi bibliotekomis, ryšio moduliais, operacine sistema, SDK ar aparatinės įrangos komponentais, tavo rizika tiesiogiai priklauso nuo tiekėjo praktikų kokybės.

Todėl jau dabar verta pradėti pokalbį apie dalykus, kurie skamba ne kaip marketingas, o kaip inžinerija:

• ar tiekėjas geba apie pažeidžiamumus informuoti nuspėjamai,
• koks jo reakcijos laikas,
• ar jis turi pataisų publikavimo procesą,
• ar jis geba palaikyti komponentą laikotarpį, kuris dera su tavo support period.

Čia CRA iš tikrųjų paliečia verslą: tiekėjas, kuris nemoka tvarkyti pažeidžiamumų, nėra „pigesnis“. Jis yra reguliacinė rizika.

Krok 6: Kurk dokumentaciją kaip nuoseklų pėdsaką: teisė → rizika → sprendimas → įrodymas

Atitikties audituose visada laimi nuoseklumas. Jei iš rizikos vertinimo matyti, kad tam tikra sąsaja yra kritinė, o dokumentacijoje neaprašyta, kaip ją apsaugai; jei deklaruoji, kad atnaujinimai yra saugūs, bet negali parodyti, kaip užtikrini paketų vientisumą; jei sakai, kad turi pažeidžiamumų tvarkymo procesą, bet negali parodyti, kaip atlieki pranešimų triage — tai nėra „popierių trūkumas“. Tai yra įrodymo, kad procesas veikia, trūkumas.

CRA kontekste, kai nėra suderintųjų standartų, šis pėdsakas yra ypač svarbus. Nes jis bus pagrindas pokalbiui su rinkos priežiūros institucija, enterprise klientu, o kai kuriose produktų kategorijose — ir su atitikties vertinimo įstaiga. Ir, kas ne mažiau svarbu, jis bus vidinio stabilumo pagrindas. Komanda žino, kodėl kažką darome, o ne tik „kad privalome“.

Pabaiga: CRA kaip naujas projektavimo reikalavimas, o ne „compliance projektas“

Jei turėčiau palikti vieną mintį, kuri sujungia visas tris dalis: CRA nėra problema, kurią sprendi pabaigoje. Tai rėmai, keičiantys mąstymą apie produktą. Kaip ISO 12100 moko, kad rizika atsiranda žmogaus ir mašinos santykyje, taip CRA moko, kad kibernetinis saugumas atsiranda produkto–aplinkos–gamintojo gyvavimo ciklo santykyje.

Suderintieji standartai ateis ir supaprastins kai kuriuos kelius. Tačiau jų nebuvimas nėra priežastis sustingti. Tai priežastis susitelkti į tai, ką CRA vertina visada: į sprendimus, įrodymus ir gebėjimą veikti realybėje — ne prezentacijoje.