Cyber Resilience Act (CRA) 2026–2027: mitä jo tiedämme, mitä vielä puuttuu ja miten valmistella tuote käytännössä – ennen kuin yhdenmukaistetut standardit julkaistaan

Mitä tiedämme varmasti jo nyt (ja miksi tämä ei ole ”vuoden 2027 asia”)

Cyber Resilience Act voi näyttää yhdeltä ”Brysselistä tulevalta” asiakirjalta lisää, jonka voisi siirtää myöhemmäksi. Se on luonnollinen reaktio, etenkin jos yrityksen arki kulkee projektien rytmissä: prototyyppi, käyttöönotto, sarjatuotanto, huolto. Sääntely tulee usein ”loppuvaiheen vaatimuksena” — asiana, joka viimeistellään maaliin tullessa. CRA muuttaa tämän logiikan, koska se ei koske vain sitä, mitä tuotteessa näkyy myyntipäivänä. Se koskee sitä, pystyykö valmistaja ylläpitämään tuotteen turvallisuuden ajan kuluessa ja osoittamaan, että tämä on tehty tietoisesti eikä sattumalta.

Tärkein tosiasia on yksinkertainen, mutta sillä on strategisia seurauksia: CRA on tuotetta koskeva säädös, joka on kiinnitetty EU-markkinan toimintalogiikkaan (mukaan lukien CE-merkintä). Euroopan komissio toteaa suoraan, että tuotteissa tulee olla CE-merkintä CRA:n mukaisuuden signaalina, ja valvonta kuuluu markkinavalvontaviranomaisille. Kyse ei siis ole ”IT-standardista”, jota voisi käsitellä sisäisenä kehitysohjelmana. Tämä on kehys, joka vaikuttaa siihen, voiko tuotetta myydä.

Päivämäärät, jotka selkeyttävät ajattelua

Itse asetuksen (EU) 2024/2847 tekstissä näkyy vaiheittainen soveltaminen. CRA:ta sovelletaan 11. joulukuuta 2027 alkaen, mutta selvin poikkeuksin. Artikla 14 (raportointi) tulee sovellettavaksi 11. syyskuuta 2026 alkaen, ja vaatimustenmukaisuuden arviointilaitosten ilmoittamista koskeva luku (Chapter IV) 11. kesäkuuta 2026 alkaen. Nämä ovat kolme päivämäärää, joita kannattaa käsitellä ”välitavoitteina”, koska ne vastaavat kolmea erilaista valmiutta: operatiivista, institutionaalista ja tuotevalmiutta.

Komissio viestii tämän vielä yksinkertaisemmin: CRA tuli voimaan 10. joulukuuta 2024, keskeiset velvoitteet alkavat 11. joulukuuta 2027 ja raportointi 11. syyskuuta 2026. Jos yrityksessä joku sanoo ”meillä on aikaa vuoteen 2027”, hän tarkoittaa useimmiten suunnitteluvaatimuksia ja vaatimustenmukaisuuden arviointia. Raportointi alkaa kuitenkin aiemmin ja koskee tapahtumia, jotka eivät odota aikataulua.

Raportointi: velvoite, joka pakottaa prosessiin (ei asiakirjaan)

Raportointivaatimus on hyvä lakmustesti, koska se näyttää, miten CRA ymmärtää ”tuotteen kyberturvallisuuden”. Kyse ei ole aikomuksen julistuksesta eikä ”politiikasta”. Kyse on prosessista, jonka on toimittava paineen alla: kun ilmenee aktiivisesti hyödynnetty haavoittuvuus tai vakava poikkeama.

Komissio kuvaa tämän yksiselitteisesti: valmistajan on ilmoitettava aktiivisesti hyödynnetyistä haavoittuvuuksista sekä vakavista poikkeamista, jotka vaikuttavat tuotteen turvallisuuteen. Edellytetään ”early warning” 24 tunnin kuluessa tiedon saamisesta, täydellinen ilmoitus 72 tunnin kuluessa sekä loppuraportti: 14 päivän kuluessa siitä, kun aktiivisesti hyödynnettyihin haavoittuvuuksiin on saatavilla korjaava toimenpide, ja kuukauden kuluessa vakavien poikkeamien tapauksissa.

Käytännössä tämä tarkoittaa, että organisaatio tarvitsee enemmän kuin tarkistuslistan. Se tarvitsee mekanismin, joka vastaa kolmeen kysymykseen: mistä saamme tiedon, että ongelma on olemassa; kuka luokittelee, onko kyse jo ”aktiivisesti hyödynnetystä” tai ”vakavasta” tapauksesta; ja miten järjestämme tiedonvälityksen sekä korjauksen aikataulussa, joka ei jätä tilaa improvisaatiolle.

Jos koulutuksissa syntyy sekavuutta, se johtuu usein siitä, että CRA osuu IT:n ja tuotteen väliseen aukkoon. IT:lle ”poikkeama” voi olla infrastruktuurissa tapahtuva tilanne. Valmistajalle ”poikkeama” on tapahtuma, joka koskettaa asiakkaalla olevaa tuotetta, versiota, konfiguraatiota ja käyttöönoton tapaa. CRA pakottaa yhdistämään nämä maailmat yhdeksi vastuuksi.

Mitä CRA kattaa: tuote suhteena verkkoon, ei ”pöydällä olevana laitteena”

Käytännössä koneiden riskinarvioinnissa olemme oppineet, että riski ei ole itse koneen ominaisuus — se syntyy ihminen–kone-suhteessa. CRA:ssa näkökulma siirtyy vastaavasti: turvallisuus ei ole ”laitteessa”, vaan tuotteen suhteessa digitaaliseen ympäristöön, käyttötapaan ja valmistajan kykyyn reagoida.

Komissio, tiivistäessään CRA:ta, kiinnittää huomiota ”tuotteiden, joissa on digitaalisia elementtejä” määritelmään sekä siihen, että raportointivelvoitteet koskevat kaikkia tällaisia EU-markkinoille saatettuja tuotteita — myös niitä, jotka on saatettu markkinoille ennen 11. joulukuuta 2027. Tämä on keskeinen täsmennys, koska se poistaa yleisen myytin: ”vanhojen tuotteiden osalta tällä ei ole merkitystä”. Raportoinnilla — on.

Mitä vielä puuttuu (yhdenmukaistettuja standardeja) ja miksi sen ei pitäisi lamauttaa

W CRA:ta koskevissa keskusteluissa toistuu usein lause: ”ei ole vielä yhdenmukaistettuja standardeja, joten mitään ei voi tehdä”. Se kuulostaa loogiselta, mutta siinä on piilevä ansa. Yhdenmukaistetut standardit ovat työkalu, joka helpottaa vaatimustenmukaisuuden osoittamista (vaatimustenmukaisuuden olettama), mutta ne eivät ole ainoa tapa rakentaa tuotteen todellista turvallisuutta. Eivätkä ne ole edellytys sille, että suunnittelun voi aloittaa oikein.

Komissio ohjaa standardointia suoraan ”CRA Standardisation” -sivun kautta ja kertoo hyväksyneensä standardointipyynnön M/606, joka kattaa 41 standardin kokonaisuuden CRA:n tueksi — sekä horisontaalisia että vertikaalisia (tuotekohtaisia). Tämä on tärkeää, koska se osoittaa, että EU ymmärtää markkinan ongelman: ilman standardeja yritykset rakentavat vaatimustenmukaisuuden kukin omalla tavallaan, ja markkinavalvonnan työ vaikeutuu.

Horisontaaliset ja vertikaaliset standardit: mitä se tarkoittaa valmistajalle

Yksinkertaistettuna:

• horisontaalisten standardien on tarkoitus kuvata ”miten” tuotteen turvallisuus rakennetaan ja ylläpidetään tuoteryhmästä riippumatta (prosessit, menetelmät, riskiperusteinen lähestymistapa),
• vertikaalisten standardien on tarkoitus täsmentää vaatimuksia tietyille tuoteluokille (siellä, missä riskit ja arkkitehtuurit ovat tyypillisiä).

Tällä jaottelulla on käytännön seurauksia. Jos kehität teollisuustuotetta, jossa osa ympäristöstä on ”OT” ja elinkaari on pitkä, tarvitset standardeja, joita ei ole kirjoitettu SaaS-sovellusta silmällä pitäen. Juuri siksi vertikaalisilla standardeilla on merkitystä: ne auttavat siirtymään yleisistä periaatteista siihen, mitä todellisissa arkkitehtuureissa pitää valvoa.

Työn aikataulu: standardit valmistuvat vaiheittain, eivät ”yhtenä pakettina ennen 2027”

Komissio näyttää CRA:n toimeenpanoa koskevissa materiaaleissa, että CRA otetaan käyttöön vaiheittain ja standardien on tarkoitus tukea tätä prosessia ajan myötä. Tämänhetkisten varmojen faktojen tasolla: meillä on virallisesti hyväksytty asetus ja käynnistetty standardointimekanismi (M/606).

Käytännön kannalta tärkeintä on ymmärtää yksi lause: vaikka standardi laadittaisiin standardointiorganisaatioissa, oikeudellisessa mielessä ”vaatimustenmukaisuuden olettama” syntyy vasta, kun viittaus standardiin julkaistaan yhdenmukaistettuna standardina EU:n virallisessa lehdessä. Tämä on EU:n yhdenmukaistamislähestymistavan yhteinen toimintalogiikka: standardit ovat silta lain ja insinöörikäytännön välillä, mutta EU:n on ensin virallisesti ”tunnustettava” tuo silta.

Valmistajan näkökulmasta tämä tarkoittaa, että vuodet 2026–2027 ovat ajanjakso, jolloin osa yrityksistä toimii omien vaatimustenmukaisuuden osoittamismenetelmiensä varassa (riskiperusteisesti + näytöt), ja osa alkaa jo peilata toimintaansa esiin tuleviin standardeihin. Ja se on normaalia.

”Standardien puute” ei tarkoita ”velvoitteen puutetta” — se tarkoittaa näyttöjen suurempaa painoarvoa

Tässä tulee esiin olennainen seuraus: jos standardeja ei ole tarjoamassa helpointa reittiä vaatimustenmukaisuuden osoittamiseen, korostuu se, mikä auditointikäytännössä on aina ratkaisevaa: johdonmukainen päätöksentekojälki.

Mitä riskejä arvioimme? Mitkä skenaariot hyväksyimme realistisiksi? Miten valitsimme suojaustoimenpiteet? Miten hallitsemme haavoittuvuuksia? Kuinka pitkään tuemme tuotetta? Miten tiedotamme asiakkaalle? CRA ei edellytä, että valmistaja ”arvaa tulevat EN-standardit”. Se edellyttää, että valmistaja pystyy osoittamaan, etteivät päätökset olleet sattumanvaraisia, vaan riskiperusteisia ja state of the art -tason mukaisia.

Miten valmistella tuote käytännössä CRA:ta varten (tiekartta valmistajalle ja integraattorille)

CRA:n suurin arvo on siinä, että se pakottaa kypsyyteen: kyberturvallisuus lakkaa olemasta tuotteen lisäosa ja siitä tulee tuotteen ominaisuus. Kypsyys ei kuitenkaan synny julistuksista. Se syntyy prosessista, joka on riittävän täsmällinen toimiakseen käytännössä ja riittävän yksinkertainen, jotta insinöörit eivät ala kiertää sitä.

Koneiden riskinarvioinnissa parhaat suunnittelupäätökset syntyvät silloin, kun lakkaamme kysymästä ”mitä vaaroja koneessa on” ja alamme kysyä ”missä tehtävissä ja tiloissa ihminen altistuu”. CRA:ssa vastaavasti: lakkaamme kysymästä ”mitä haavoittuvuuksia tuotteessa on” ja alamme kysyä ”missä olosuhteissa tuote altistuu ja mitä valmistaja pystyy silloin tekemään”. Tämä painopisteen siirto jäsentää työn.

Vaihe 1: Määrittele tuote järjestelmänä (ei laitteena)

Aloita määrittelemällä, mikä sinun tapauksessasi on ”tuote, jossa on digitaalisia elementtejä”. Ei pelkästään laitteisto ja laiteohjelmisto, vaan myös se, mikä usein sivuutetaan, koska se ei mahdu laatikkoon: komponentit, kirjastot, päivitysmekanismit, palvelut, ilman joita tuote ei täytä tehtäväänsä. CRA:ssa tämä on tärkeää, koska valmistajan vastuu koskee sitä, mikä saatetaan markkinoille tuotteena — ei vain sitä, mitä mekaniikkasuunnittelu on tuottanut.

Tämä on myös ensimmäinen hetki, jolloin integraattorien kannattaa olla rehellisiä itselleen: jos integroit komponentteja ja konfiguroit ne tavalla, joka muodostaa asiakkaan silmissä ”lopputuotteen”, et ole vain ”käyttöönoton tekijä”. Olet riskin ja vastuun yhteisluoja.

Vaihe 2: Tee CRA-riskinarviointi niin, että se toimii päätöksenteon työkaluna

Ei ole kyse ”matriisista” dioissa. Kyse on riskinarvioinnista, joka johtaa suunnittelupäätöksiin ja on toistettavissa.

Käytännössä hyvä lähestymistapa CRA:han alkaa yksinkertaisesta kysymyksestä: millaisia ovat todelliset väärinkäyttöskenaariot asiakkaan toimintaympäristössä, eivät vain laboratoriossa? Kenellä on huolto-/ylläpitokäyttöoikeudet? Millainen verkko on? Kuinka usein päivitämme? Mitkä ovat seisokin seuraukset? Teollisuudessa nämä kysymykset ovat epämukavampia kuin IT:ssä, koska vastaukset ovat usein: ”emme voi päivittää viikoittain” tai ”meillä ei ole telemetriaa”. Juuri siksi ne on esitettävä. CRA on laki, mutta sen vaikutukset ovat suunnittelullisia.

Vaihe 3: Rakenna ”vulnerability handling” tuotantoprosessiksi, ei kriisireaktioksi

Komission kuvaamat raportointivaatimukset (24h/72h/14 päivää/kuukausi) ovat armottomia organisaatiolle, jolla ei ole prosessia. Jos haluat olla valmis 11. syyskuuta 2026, sinun on kohdeltava ”vulnerability handlingia” osana tuotteen elinkaarta, ei ”security-tiimin tehtävänä”.

Tämä tarkoittaa:

• yksi kanava ilmoitusten vastaanottamiseen (CVD policy + kontakt),
• triage, jolla on omistaja ja kriteerit,
• mekanismi tietoturvapäivitysten rakentamiseen ja toimittamiseen,
• asiakkaille suunnattu viestintämalli, joka ei perustu improvisointiin,
• valmius raportointiin (kuka ilmoittaa, millä tiedoilla, kuinka nopeasti).

Kaikki tämä kuulostaa ”organisatoriselta” työltä. Käytännössä se on tuotetyötä, koska se liittyy versioihin, yhteensopivuuteen, päivitysarkkitehtuuriin ja tukistrategiaan.

Vaihe 4: Valitse support period liiketoimintapäätöksenä, ei minimitason vaatimuksena

Jos tuotteesi elävät teollisuudessa 10–15 vuotta, support period on strateginen. CRA pakottaa siihen, ettei tuki ole katteeton lupaus. Tämä tarkoittaa, että support periodin tulee perustua analyysiin: kuinka pitkään tuotetta käytetään, millainen komponenttien toimitusketju on, ja kuinka pitkään pystyt toimittamaan korjauksia. Käytännössä support period alkaa ”vetää” koko ekosysteemiä: toimittajasopimuksia, build environmentin saatavuutta, toolchainien ylläpitoa ja jopa päätöksiä siitä, onko tuotteessa etätoimintoja vai onko se eristetty.

Jos käsittelet support periodia pelkkänä muodollisuutena, viimeistään 2027 joudut ristiriitaan: asiakas odottaa tukea, mutta sinulla ei enää ole resursseja tai riippuvuuksia sen toimittamiseen. CRA ei luo tätä ongelmaa — CRA vain paljastaa sen.

Vaihe 5: Järjestä toimitusketju: keskustelu toimittajien kanssa on osa vaatimustenmukaisuutta

CRA:ssa ei ole mitään ”taikatemppua”, joka tekisi ulkoisista komponenteista turvallisia. Jos laitteesi perustuu kirjastoihin, viestintämoduuleihin, käyttöjärjestelmään, SDK:hon tai laitteistokomponentteihin, riskisi riippuu suoraan toimittajan käytäntöjen laadusta.

Siksi jo nyt kannattaa ottaa esiin asiat, jotka eivät kuulosta markkinoinnilta vaan insinöörityöltä:

• pystyykö toimittaja tiedottamaan haavoittuvuuksista ennakoitavalla tavalla,
• mikä on sen reagointiaika,
• onko sillä korjausten julkaisemisprosessi,
• pystyykö se ylläpitämään komponenttia ajanjakson, joka on linjassa sinun support periodisi kanssa.

Tässä kohtaa CRA todella osuu liiketoimintaan: toimittaja, joka ei pysty käsittelemään haavoittuvuuksia, ei ole ”halvempi”. Se on sääntelyriski.

Vaihe 6: Rakenna dokumentaatio yhtenäiseksi jäljeksi: laki → riski → päätös → näyttö

Vaatimustenmukaisuusauditoinneissa voittaa aina johdonmukaisuus. Jos riskinarvioinnista seuraa, että tietty rajapinta on kriittinen, mutta dokumentaatio ei kuvaa, miten suojaat sen; jos ilmoitat, että päivitykset ovat turvallisia, mutta et pysty osoittamaan, miten varmistat pakettien eheyden; jos sanot, että sinulla on haavoittuvuuksien käsittelyprosessi, mutta et pysty näyttämään, miten triage’aat ilmoitukset — kyse ei ole ”paperien puutteesta”. Kyse on siitä, ettei ole näyttöä prosessin toimivuudesta.

CRA:ssa, kun yhdenmukaistettuja standardeja ei ole, tämä jälki on erityisen tärkeä. Se on pohja keskustelulle markkinavalvontaviranomaisen ja enterprise-asiakkaan kanssa, ja joissakin tuoteryhmissä myös vaatimustenmukaisuuden arvioinnin toimijan kanssa. Ja yhtä tärkeää: se on sisäisen vakauden perusta. Tiimi tietää, miksi jotain tehdään, eikä vain sitä, että ”on pakko”.

Lopuksi: CRA uutena suunnitteluvaatimuksena, ei ”compliance-projektina”

Jos jättäisin yhden ajatuksen, joka sitoo nämä kolme osaa yhteen: CRA ei ole ongelma, joka ratkaistaan lopussa. Se on kehys, joka muuttaa tapaa ajatella tuotteesta. Kuten ISO 12100 opettaa, että riski syntyy ihminen–kone-suhteessa, niin CRA opettaa, että kyberturvallisuus syntyy tuote–ympäristö–valmistajan elinkaari -suhteessa.

Yhdenmukaistetut standardit tulevat ja yksinkertaistavat joitakin polkuja. Mutta niiden puute ei ole syy pysähtyä. Se on syy keskittyä siihen, mitä CRA arvioi aina: päätöksiin, näyttöön ja kykyyn toimia todellisuudessa — ei esityksessä.