Kiberdrošības noturības akts (CRA) 2026–2027: ko jau zinām, kā vēl trūkst un kā praktiski sagatavot produktu — pirms parādās harmonizētie standarti

Ko mēs šodien zinām droši (un kāpēc tas nav “2027. gada jautājums”)

Cyber Resilience Act var izskatīties kā vēl viens “Briseles” dokuments, ko varēs atlikt uz vēlāku laiku. Tā ir dabiska reakcija, īpaši, ja uzņēmums dzīvo projektu ritmā: prototips, ieviešana, sērijveida ražošana, serviss. Regulējums bieži ienāk kā “noslēdzošā prasība” — kaut kas, ko pievieno pašās beigās. CRA šo loģiku maina, jo tas neattiecas tikai uz to, kas produktā ir redzams pārdošanas dienā. Tas attiecas uz to, vai ražotājs spēj laika gaitā uzturēt produkta drošību un pierādīt, ka tas ir darīts apzināti, nevis nejauši.

Svarīgākais fakts ir vienkāršs, taču ar stratēģiskām sekām: CRA ir produktu regulējums, kas balstīts ES tirgus mehānikā (tostarp CE marķējumā). Eiropas Komisija tieši norāda, ka produktiem jābūt marķētiem ar CE zīmi kā atbilstības CRA signālu, un izpilde ir tirgus uzraudzības iestāžu ziņā. Tātad tas nav “IT standarts”, ko var uztvert kā iekšēju uzlabošanas programmu. Tā ir sistēma, kas ietekmē iespēju produktu pārdot.

Datumi, kas sakārto domāšanu

Pašā regulas (ES) 2024/2847 tekstā ir redzama pakāpeniska piemērošana. CRA piemēro no 11. decembra 2027, taču ar skaidriem izņēmumiem. 14. pants (ziņošana) ir piemērojams no 11. septembra 2026, bet nodaļa par atbilstības novērtēšanas iestāžu notifikāciju (Chapter IV) — no 11. jūnija 2026. Tie ir trīs datumi, kurus ir vērts uztvert kā “atskaites punktus”, jo tie atbilst trim atšķirīgiem gatavības veidiem: operatīvajai, institucionālajai un produktu gatavībai.

Komisija to pasaka vēl vienkāršāk: CRA stājās spēkā 10. decembrī 2024, būtiskie pienākumi — no 11. decembra 2027, bet ziņošana — no 11. septembra 2026. Ja uzņēmumā kāds saka “mums ir laiks līdz 2027. gadam”, visbiežāk ar to domā projektēšanas prasības un atbilstības novērtēšanu. Taču ziņošana ir agrāk un attiecas uz notikumiem, kas negaida grafiku.

Ziņošana: pienākums, kas piespiež izveidot procesu (nevis dokumentu)

Ziņošanas prasība ir labs lakmusa papīrs, jo parāda, kā CRA saprot “produkta kiberdrošību”. Tā nav nodomu deklarācija vai “politika”. Tas ir process, kam jāstrādā stresa situācijā: kad parādās aktīvi izmantota ievainojamība vai nopietns incidents.

Komisija to apraksta nepārprotami: ražotājam jāziņo par aktīvi izmantotām ievainojamībām un severe incidents, kas ietekmē produkta drošību. Nepieciešams “early warning” 24 stundu laikā no brīža, kad par to uzzināts, pilns paziņojums 72 stundu laikā, bet noslēguma ziņojums: līdz 14 dienām pēc tam, kad aktīvi izmantotām ievainojamībām ir pieejams novēršanas līdzeklis, un viena mēneša laikā — severe incidents gadījumā.

Praksē tas nozīmē, ka organizācijai vajag ko vairāk par kontrolsarakstu. Vajag mehānismu, kas atbild uz trim jautājumiem: kā mēs uzzināsim, ka problēma pastāv; kurš kvalificē, vai tas jau ir “aktīvi izmantots” vai “severe”; un kā mēs organizēsim informācijas apriti un labojumu termiņā, kas neatstāj vietu improvizācijai.

Ja apmācībās parādās haoss, tas bieži ir tāpēc, ka CRA trāpa spraugā starp IT un produktu. IT skatījumā “incidents” mēdz būt notikums infrastruktūrā. Ražotājam “incidents” ir notikums, kas skar produktu pie klienta — konkrētu versiju, konfigurāciju, ieviešanas veidu. CRA piespiež šīs pasaules savienot vienā atbildībā.

Ko aptver CRA: produkts kā attiecības ar tīklu, nevis “ierīce uz galda”

Praksē, apgūstot mašīnu riska novērtēšanu, mēs mācījāmies, ka risks nav pašas mašīnas īpašība — tas rodas attiecībās cilvēks–mašīna. CRA ir līdzīga perspektīvas maiņa: drošība neeksistē “ierīcē”, bet gan produkta attiecībās ar digitālo vidi, lietošanas veidu un ražotāja spēju reaģēt.

Komisija, apkopojot CRA, pievērš uzmanību “produktu ar digitāliem elementiem” definīcijai un tam, ka ziņošanas pienākumi attiecas uz visiem šādiem produktiem, kas darīti pieejami ES tirgū — arī tiem, kas laisti tirgū pirms 11. decembra 2027. Tas ir būtisks precizējums, jo tas kliedē izplatītu mītu: “vecajiem produktiem tas nav svarīgi”. Ziņošana — ir.

Cik vēl nav (harmonizēto standartu) un kāpēc tam nevajadzētu paralizēt

W sarunās par CRA bieži izskan frāze: “vēl nav harmonizēto standartu, tātad neko nevar darīt”. Tas skan loģiski, taču te slēpjas lamatas. Harmonizētie standarti ir instruments, kas atvieglo atbilstības pierādīšanu (atbilstības prezumpcija), taču tie nav vienīgais ceļš, kā panākt reālu produkta drošumu. Un tie nav priekšnoteikums, lai sāktu projektēt pareizi.

Komisija standartu tēmu tieši virza lapā “CRA Standardisation” un informē, ka ir pieņēmusi standardisation request M/606, kas aptver kopumu ar 41 standartu, kas atbalsta CRA — gan horizontālos, gan vertikālos (produktu). Tas ir būtiski, jo parāda, ka ES saprot tirgus problēmu: bez standartiem uzņēmumi atbilstību veidos katrs pēc sava, un tirgus uzraudzībai būs grūtāk.

Horizontālie un vertikālie standarti: ko tas nozīmē ražotājam

Vienkāršoti:

• horizontālajiem standartiem jāapraksta “kā” veidot un uzturēt produkta drošumu neatkarīgi no kategorijas (procesi, metodes, uz risku balstīta pieeja),
• vertikālajiem standartiem jāprecizē prasības konkrētām produktu klasēm (tur, kur riski un arhitektūras ir tipiskas).

Šim iedalījumam ir praktiskas sekas. Ja veido industriālu produktu, kur daļa vides ir “OT” un dzīves cikls ir ilgs, tev būs vajadzīgi standarti, kas nav rakstīti SaaS lietotnei. Tieši tāpēc vertikālajiem standartiem ir nozīme: tie palīdz no vispārīgu principu līmeņa nonākt līdz tam, ko kontrolēt reālās arhitektūrās.

Darbu grafiks: standarti parādīsies pa posmiem, nevis “vienā paketē pirms 2027”

Komisija CRA ieviešanas materiālos rāda, ka CRA tiek ieviests pakāpeniski, un standartiem šis process laika gaitā ir jāatbalsta. Faktos, kas šodien ir droši: mums ir formāli pieņemta regula un ir iedarbināts standartizācijas mehānisms (M/606).

Praksei vissvarīgākais ir saprast vienu teikumu: pat tad, ja standartu izstrādās standartizācijas organizācijas, “atbilstības prezumpcija” juridiskā nozīmē parādās tikai tad, kad atsauce uz standartu tiek publicēta kā harmonizēts standarts ES Oficiālajā Vēstnesī. Tā ir mehānika, kas kopīga ES harmonizācijas pieejai: standarti ir tilts starp tiesībām un inženierpraksi, taču šim tiltam ES ir formāli jāpiešķir “atzīšana”.

No ražotāja skatpunkta tas nozīmē, ka 2026.–2027. gads būs periods, kurā daļa uzņēmumu darbosies, balstoties uz savām atbilstības pierādīšanas metodēm (uz risku balstīti + pierādījumi), bet daļa jau kartēsies pret parādīties sākušajiem standartiem. Un tas ir normāli.

“Standartu trūkums” nenozīmē “pienākuma trūkumu” — tas nozīmē lielāku pierādījumu svaru

Te parādās būtiska sekas: ja nav standartu, kas dod vienkāršāko atbilstības pierādīšanas ceļu, pieaug tas, kas audita praksē vienmēr ir izšķirošs: konsekventa lēmumu pieņemšanas pēda.

Kādus riskus mēs novērtējām? Kādus scenārijus pieņēmām kā reālistiskus? Kā izvēlējāmies aizsardzības pasākumus? Kā pārvaldām ievainojamības? Cik ilgi atbalstām produktu? Kā informējam klientu? CRA neprasa, lai ražotājs “minētu nākotnes EN standartus”. Tas prasa, lai ražotājs spētu parādīt, ka viņa lēmumi nebija nejauši, bet balstīti uz risku un state of the art.

Kā reāli sagatavot produktu CRA (ceļa karte ražotājam un integratoram)

Lielākā CRA vērtība ir tā, ka tas piespiež briedumu: kiberdrošība pārstāj būt produkta pielikums un kļūst par tā īpašību. Taču briedums nerodas no deklarācijām. Tas rodas no procesa, kas ir pietiekami precīzs, lai strādātu praksē, un pietiekami vienkāršs, lai inženierija nesāktu to apiet.

Mašīnu riska novērtēšanā labākie projektēšanas lēmumi parādās tad, kad pārstājam jautāt “kādi apdraudējumi ir mašīnai”, un sākam jautāt “kādos uzdevumos un stāvokļos cilvēks ir pakļauts riskam”. CRA gadījumā līdzīgi: pārstājam jautāt “kādas ievainojamības ir produktam”, un sākam jautāt “kādos apstākļos produkts kļūst ievainojams un ko ražotājs tad spēj izdarīt”. Šī pārbīde sakārto darbu.

1. solis: definē produktu kā sistēmu (nevis kā ierīci)

Sāc ar definēšanu, kas tavā gadījumā ir “produkts ar digitāliem elementiem”. Ne tikai aparatūra un programmaparatūra, bet arī tas, ko mēdz ignorēt, jo tas neietilpst kastē: komponenti, bibliotēkas, atjaunināšanas mehānismi, pakalpojumi, bez kuriem produkts nepilda funkciju. CRA kontekstā tas ir svarīgi, jo ražotāja atbildība attiecas uz to, kas nonāk tirgū kā produkts — nevis tikai uz to, ko izgatavoja mehānikas nodaļa.

Tas ir arī pirmais brīdis, kad integratoriem jābūt godīgiem pašiem pret sevi: ja tu integrē komponentus un konfigurē tos tā, ka klienta acīs izveido “galaproduktu”, tad tu neesi tikai “ieviesējs”. Tu esi līdzradītājs riskam un līdzradītājs atbildībai.

2. solis: veic CRA riska novērtējumu tā, lai tas būtu lēmumu pieņemšanas instruments

Neruna ir runa par “matricu” slaidos. Runa ir par riska novērtējumu, kas noved pie projektēšanas lēmumiem un ir atkārtojams.

Praksē laba pieeja CRA sākas ar vienkāršu jautājumu: kādi ir reālie ļaunprātīgas izmantošanas scenāriji klienta vidē, nevis tikai laboratorijā? Kam ir servisa piekļuve? Kā izskatās tīkls? Cik bieži mēs atjauninām? Kādas ir dīkstāves sekas? Rūpniecībā šie jautājumi ir neērtāki nekā IT, jo atbildes bieži skan: “mēs nevaram atjaunināt katru nedēļu” vai “mums nav telemetrijas”. Un tieši tāpēc tie ir jāuzdod. CRA ir tiesību akts, taču tā sekas ir projektēšanas līmenī.

Krok 3: Izveido “vulnerability handling” kā ražošanas procesu, nevis kā krīzes reakciju

Komisijas aprakstītās ziņošanas prasības (24h/72h/14 dienas/mēnesis) ir nežēlīgas organizācijai, kurai nav procesa. Ja vēlies būt gatavs 11. septembrim 2026, “vulnerability handling” jāuztver kā produkta dzīves cikla elements, nevis kā “security komandas uzdevums”.

Tas nozīmē:

• viens kanāls ziņojumu pieņemšanai (CVD policy + kontakts),
• triage ar noteiktu atbildīgo un kritērijiem,
• drošības atjauninājumu izveides un piegādes mehānisms,
• klientu komunikācijas modelis, kas nav improvizācija,
• gatavība ziņošanai (kas ziņo, ar kādiem datiem, cik ātri).

Tas viss izklausās pēc “organizatoriska” darba. Praksē tas ir produkta darbs, jo tas skar versijas, saderību, atjauninājumu arhitektūru un atbalsta stratēģiju.

Krok 4: Izvēlies support period kā biznesa lēmumu, nevis minimālo prasību

Ja tavi produkti rūpniecībā kalpo 10–15 gadus, support period ir stratēģisks. CRA piespiež, lai atbalsts nebūtu nepamatīts solījums. Tas nozīmē, ka support period jāizriet no analīzes: cik ilgi produkts tiks lietots, kā izskatās komponentu piegādes ķēde, cik ilgi tu spēsi piegādāt labojumus. Praksē support period sāk “vilkt” līdzi visu ekosistēmu: līgumus ar piegādātājiem, build environment pieejamību, toolchain uzturēšanu un pat lēmumus par to, vai produktam ir attālinātas funkcijas vai tas ir izolēts.

Ja support period uztversi kā formalitāti, vēlākais 2027. gadā nonāksi konfliktā: klients gaida atbalstu, bet tev vairs nav ne resursu, ne atkarību, lai to nodrošinātu. CRA šo problēmu nerada — CRA to tikai atklāj.

Krok 5: Sakārto piegādes ķēdi: saruna ar piegādātājiem ir daļa no atbilstības

CRA nav nekādas “maģijas”, kas padarītu ārējos komponentus drošus. Ja tava ierīce balstās uz bibliotēkām, sakaru moduļiem, operētājsistēmu, SDK vai aparatūras komponentiem, tavs risks ir tieši atkarīgs no piegādātāja prakšu kvalitātes.

Tāpēc jau tagad ir vērts ieviest sarunu par lietām, kas neskan kā mārketings, bet kā inženierija:

• vai piegādātājs spēj informēt par ievainojamībām paredzamā veidā,
• kāds ir tā reakcijas laiks,
• vai tam ir labojumu publicēšanas process,
• vai tas spēj uzturēt komponentu periodā, kas ir saskaņots ar tavu support period.

Šeit CRA patiešām skar biznesu: piegādātājs, kurš nespēj apstrādāt ievainojamības, nav “lētāks”. Tas ir regulatīvais risks.

Krok 6: Izveido dokumentāciju kā vienotu pēdu: tiesības → risks → lēmums → pierādījums

Atbilstības auditos vienmēr uzvar konsekvence. Ja no riska novērtējuma izriet, ka konkrēts interfeiss ir kritisks, bet dokumentācija neapraksta, kā tu to aizsargā; ja deklarē, ka atjauninājumi ir droši, bet nevari parādīt, kā nodrošini pakotņu integritāti; ja saki, ka tev ir ievainojamību apstrādes process, bet nevari parādīt, kā tu veic triage ziņojumiem — tas nav “papīru trūkums”. Tas ir pierādījuma trūkums, ka process darbojas.

CRA ietvarā, ja nav harmonizētu standartu, šī pēda ir īpaši svarīga. Jo tā būs pamats sarunai ar tirgus uzraudzības iestādi, enterprise klientu, bet dažās produktu kategorijās arī ar atbilstības novērtēšanas vienību. Un tikpat svarīgi: tā būs pamats iekšējai stabilitātei. Komanda zina, kāpēc mēs kaut ko darām, nevis tikai “ka mums tas ir jādara”.

Nobeigums: CRA kā jauna projektēšanas prasība, nevis “compliance projekts”

Ja man būtu jāatstāj viena doma, kas savelk kopā visas trīs daļas: CRA nav problēma, ko risināt pašās beigās. Tas ir ietvars, kas maina domāšanu par produktu. Tāpat kā ISO 12100 māca, ka risks rodas cilvēka–mašīnas mijiedarbībā, tā CRA māca, ka kiberdrošība rodas produkta–vides–ražotāja dzīves cikla mijiedarbībā.

Harmonizētie standarti nāks un atvieglos dažus ceļus. Taču to neesamība nav iemesls bezdarbībai. Tas ir iemesls koncentrēties uz to, ko CRA vienmēr vērtē: uz lēmumiem, pierādījumiem un spēju rīkoties realitātē — nevis prezentācijā.