Cyber Resilience Act: Miksi ensimmäinen määräaika osuu jo syyskuuhun 2026

Yksi väärinkäsitys osoittautuu sitkeäksi: että Cyber Resilience Act koskisi valmistajia vasta vuoden 2027 lopusta. Se pitää paikkansa osalle velvoitteista — mutta ei ensimmäiselle, ja se on niistä epämukavin. Se astuu voimaan jo 11. syyskuuta 2026. Tätä kirjoittaessani siihen on alle neljännesvuosi.

En pidä CRA:ta byrokratiana byrokratian vuoksi. Se pakottaa toimialan, joka on vuosikymmeniä kohdellut turvallisuutta vapaaehtoisena lisänä, johonkin, joka on turvallisuuskriittisillä aloilla ollut jo kauan itsestäänselvyys: osoittamaan, mitä tekee. Silti monet aliarvioivat, kuinka aikaisin kello käynnistyy. Siksi tämä artikkeli.

Mitä CRA vaatii — ja mistä alkaen

Cyber Resilience Act (asetus (EU) 2024/2847) on ollut voimassa joulukuusta 2024. Se määrittää, kuinka turvallisia "digitaalisia elementtejä sisältävien tuotteiden" on oltava hyökkäyksiä vastaan — siis kaiken, mikä sisältää ohjelmistoa tai liittyy verkkoon. Älytermostaatista teollisuusohjaimeen. Tärkeitä päivämääriä on kaksi, eikä niitä pidä sekoittaa:

11. syyskuuta 2026 — ilmoitusvelvollisuus. Tästä päivästä alkaen minun on ilmoitettava jokainen aktiivisesti hyödynnetty haavoittuvuus ja jokainen vakava tietoturvapoikkeama 24 tunnin kuluessa asianomaisille tahoille — EU-virasto ENISA:lle ja kansallisille vastetiimeille (CSIRT). Tämä koskee myös tuotteita, jotka ovat olleet markkinoilla jo kauan ja ovat yhä tuessa.

11. joulukuuta 2027 — kaikki muu. Siitä alkaen tuotteen on oltava turvalliseksi suunniteltu pohjalta lähtien, saatava tietoturvapäivityksiä koko elinkaarensa ajan, esitettävä täydellinen ohjelmisto-osaluettelo, läpäistävä vaatimustenmukaisuuden arviointi ja kannettava CE-merkintä.

Kun asettaa molemmat päivämäärät rinnakkain, varsinainen ongelma paljastuu: ilmoittaa voi vain sen, minkä tietää olevan tuotteessaan. Ja se johtaa suoraan aliarvioituun esteeseen.

Miksi ilmoitusvelvollisuus on varsinainen este

Haavoittuvuuden ilmoittaminen 24 tunnissa kuulostaa organisatoriselta pikkuasialta. Se ei ole sitä. Voidakseni ylipäätään arvioida, koskeeko juuri julkitullut puute omaa tuotettani, tarvitsen täydellisen luettelon kaikista sisäänrakennetuista ohjelmistokomponenteista — niin kutsutun SBOM:n (software bill of materials), ohjelmakoodin osaluettelon. Ilman sitä istun jokaisen uuden haavoittuvuusilmoituksen kohdalla pimeässä ja arvailen, onko jokin komponenttini altis.

Toisin sanoen: SBOM:n, joka virallisesti tulee pakolliseksi vasta 2027, tarvitsen käytännössä jo syyskuussa 2026. Se, joka vasta silloin alkaa kartoittaa riippuvuuksiaan, on jo hävinnyt ensimmäisen tositilanteen. Lisäksi tulee pelkkä logistiikka: kuka havaitsee hyödynnetyn puutteen, kuka arvioi sen, kuka ilmoittaa siitä — ja toimiiko tuo ketju myös lauantai-iltana? 24 tuntia on 24 tuntia.

Vikasietoisuus ja hyökkäyksenkesto kasvavat yhteen

Tässä kohtaa se käy ydintyöni kannalta kiinnostavaksi. Olen kehittänyt turvallisuuskriittistä sulautettua ohjelmistoa yli kolme vuosikymmentä, suuren osan siitä ISO 26262:n mukaan — ajoneuvojen toiminnallisen turvallisuuden standardin. Toiminnallinen turvallisuus kysyy: mitä tapahtuu, jos komponentti pettää? CRA asettaa sen viereen toisen kysymyksen: mitä tapahtuu, jos joku hyökkää laitteeseen tahallaan?

Nämä kaksi kysymystä olivat kauan erillisiä maailmoja. Eivät enää. Havainnollinen esimerkki on etäkäsiksipääsy Jeep Cherokeeseen vuonna 2015: kaksi tietoturvatutkijaa otti haltuunsa jarrut ja vaihteiston infotainment-järjestelmän puutteen kautta — etänä, matkapuhelinverkon yli. 1,4 miljoonaa ajoneuvoa jouduttiin kutsumaan takaisin. Jokainen jarrun turvallisuusperustelu oli näin arvoton, sillä jarru ei pettänyt sattumalta vaan hyökkääjän käskystä. Ohjelmiston puutteesta oli tullut turvallisuusongelma sanan varsinaisessa merkityksessä.

Juuri tässä syntyvät nykyään kalliit aukot: valmistajilla, joilla vikasietoisuus on hallinnassa mutta jotka eivät ole koskaan tarkastelleet hyökkäyspuolta järjestelmällisesti. Se, joka ajattelee ISO 26262:ta ilman rinnalla kulkevaa tietoturvatarkastelua, ei enää sulje argumentointiketjuaan.

Mitä laiteohjelmistossa konkreettisesti muuttuu

CRA sivuutetaan mielellään juristien aiheena. Pidän sitä virheenä. Vaatimusten takana on hyvin konkreettisia tehtäviä laiteohjelmistolle — ohjausohjelmistolle, joka istuu kiinteästi laitteessa. Neljä kohtaa on mielestäni keskeisiä:

Ohjelmiston on oltava laitteessa salattuna. Se, joka voi lukea ohjelmakoodin salaamattomana flashista, on jättänyt oven auki. Nykyaikaiset mikrokontrollerit tarjoavat tähän suojan — turvallisen lukulukituksen, allekirjoitetun käynnistyksen, avaimeen sidotut muistialueet. Ratkaisevaa on hallita ne siististi myös tuotannossa sen sijaan, että avaimet katoaisivat matkalla.

Päivitysten on oltava väärentämisen kestäviä. Laitteen on voitava vastaanottaa tietoturvapäivityksiä koko elinkaarensa ajan — ja niin, ettei kukaan voi ujuttaa sisään vierasta ohjelmistoa. Tuote ilman allekirjoitettua, todennettua päivityspolkua ei yksinkertaisesti ole vuodesta 2027 enää myyntikelpoinen.

Jokaisen komponentin on oltava tunnettu ja valvottu. Jokainen ostettu kirjasto, jokainen reaaliaikakäyttöjärjestelmän rakennuspalikka, jokainen krypto-pino kuuluu osaluetteloon ja sitä on valvottava tunnettujen haavoittuvuuksien varalta. Tähän kuuluu vanhentuneiden komponenttien tunnistaminen, joita alkuperäinen toimittaja ei enää ylläpidä — ennen kuin viranomainen tekee sen.

Siisti koodi maksaa itsensä takaisin. Turvallisuuskriittisissä projekteissa kehitän tiukkojen koodaussääntöjen mukaan, kuten MISRA-C. Monet näistä säännöistä poistavat juuri ne määrittelemättömät käyttäytymiset, joista exploitit myöhemmin rakennetaan. Se, joka työskentelee näin alusta alkaen, on jo hoitanut osan CRA-läksyistä — mutta hänen tulisi myös pystyä osoittamaan se.

Pienikin valmistaja on "valmistaja"

Laajalle levinnyt virhepäätelmä kuuluu: tämä koskee vain suuria konserneja. Väärin. CRA koskee jokaista, joka saattaa digitaalisia elementtejä sisältävän tuotteen EU-markkinoille — keskisuuresta yrityksestä erikoistuneeseen yksittäiskehittäjään. Myös se, joka tuo maahan tai jälleenmyy laitteita, kantaa omat velvollisuutensa. Eivätkä sakot ole mörkö: ne yltävät 15 miljoonaan euroon tai 2,5 prosenttiin maailmanlaajuisesta vuosiliikevaihdosta.

Se, joka tähän asti ajatteli turvallisuuden olevan vaihtoehto "myöhemmille tuoteversioille", ei enää voi valita niin.

Mitä neuvon valmistajille nyt

Tulevat kuukaudet ratkaisevat, kohtaako syyskuu 2026 järjestäytyneen menettelyn vai hätäisen improvisoinnin. Neuvoni on vaatimaton, mutta se toimii: aloita. Kartoitus siitä, mitkä tuotteet ovat asianomaisia ja yhä tuettuja. Ensimmäinen ohjelmisto-osaluettelo tuotetta kohden. Määritelty ilmoitusreitti, joka organisatorisesti todella kantaa 24 tunnin määräajan. Ja rinnalla laiteohjelmiston kovennus — harkittuna arkkitehtuurina, ei jälkikäteen lätkäistynä paikkana.

Rehellinen itsearvio lopuksi: se, joka etsii leimaa siitä, että kaikki on jo kunnossa, on väärässä paikassa luonani. Se, joka haluaa tietää, missä tuotteet syyskuussa 2026 todella ovat ja mitä laiteohjelmistossa on siihen mennessä tehtävä, on oikeassa paikassa.

Yhteenveto

CRA ei ole kaukainen ongelma ylihuomista varten. Ensimmäinen sitova määräaika osuu syyskuuhun 2026, ja se edellyttää, että tiedän jo tänään, mitä tuotteissani on. Se, joka aloittaa ajoissa, jakaa työn ja välttää kalliit hätäratkaisut juuri ennen määräaikaa.

Suurin vipuvarsi on harvoin pelkässä tekniikassa. Se on osaluettelon, ilmoitusprosessin ja laitteen kovennuksen siistissä yhteispelissä — ja siinä, että vikasietoisuus ja hyökkäyksenkesto vihdoin ajatellaan yhtenä yhteisenä kokonaisuutena, ei kahtena erillisenä laatikkona. Juuri se on silta, jolla mieluiten työskentelen.