EU:n kyberkestävyyssäädös (CRA): raportointivelvoite alkoi 11.9.2026 – mitä ohjelmistoyrityksen pitää tehdä

EU:n kyberkestävyyssäädös (Cyber Resilience Act, CRA) on asetus, joka tuo pakolliset tietoturvavaatimukset kaikille digitaalisia elementtejä sisältäville tuotteille: ohjelmistoille, sovelluksille ja verkkoon kytketyille laitteille. Asetus tuli voimaan 10.12.2024, ja sen ensimmäinen käytännön velvoite alkoi 11.9.2026: valmistajien on nyt ilmoitettava aktiivisesti hyödynnetyistä haavoittuvuuksista ja vakavista tietoturvapoikkeamista. Pääosa vaatimuksista tulee sovellettavaksi 11.12.2027. Ohjelmistoja kehittävälle ja myyvälle yritykselle tämä tarkoittaa, että tietoturva on nyt myös lakisääteinen liiketoimintakysymys.

Keskeiset päivämäärät

  • 10.12.2024 – CRA tuli voimaan.
  • 11.6.2026 – vaatimustenmukaisuuden arviointilaitosten ilmoittamista koskevat säännökset alkoivat soveltua.
  • 11.9.2026 – valmistajien raportointivelvoite (artikla 14) alkoi. Samana päivänä otettiin käyttöön ENISAn ylläpitämä yhteinen raportointialusta (Single Reporting Platform, SRP).
  • 11.12.2027 – asetus soveltuu kokonaisuudessaan, mukaan lukien tuotteiden olennaiset kyberturvallisuusvaatimukset ja avoimen lähdekoodin ylläpitäjien (open-source software stewards) raportointivelvoitteet.

Mitä pitää raportoida ja missä ajassa?

Valmistajan on ilmoitettava kahdesta tapahtumatyypistä:

  1. Aktiivisesti hyödynnetyt haavoittuvuudet – haavoittuvuudet, joista on luotettavaa näyttöä, että pahantahtoinen toimija on käyttänyt niitä hyväksi.
  2. Vakavat tietoturvapoikkeamat – tapahtumat, joilla on vakava vaikutus tuotteen tietoturvaan, esimerkiksi sen saatavuuteen, aitouteen, eheyteen tai luottamuksellisuuteen.

Määräajat ovat tiukat:

  • 24 tunnin kuluessa tietoon tulosta: ennakkovaroitus.
  • 72 tunnin kuluessa: varsinainen ilmoitus.
  • Loppuraportti: haavoittuvuuksista viimeistään 14 päivää sen jälkeen, kun korjaava tai lieventävä toimenpide on saatavilla; vakavista poikkeamista kuukauden kuluessa 72 tunnin ilmoituksesta.

Ilmoitukset tehdään keskitetysti SRP-alustan kautta. Ne ohjautuvat sen jäsenvaltion CSIRT-yksikölle, jossa valmistajalla on päätoimipaikka (Suomessa Kyberturvallisuuskeskus), ja samanaikaisesti ENISAlle. Tärkeä yksityiskohta: raportointivelvoite koskee kaikkia EU:n markkinoilla saatavilla olevia tuotteita, myös niitä, jotka on saatettu markkinoille jo ennen vuotta 2027.

Mitä tämä tarkoittaa ohjelmistoyritykselle käytännössä?

Raportointi vaatii, että yritys ylipäätään huomaa haavoittuvuuden hyödyntämisen ajoissa. 24 tunnin aikaraja ei jätä tilaa improvisoinnille. Siksi kannattaa varmistaa ainakin seuraavat asiat:

  • Tuoteinventaario. Tiedä, mitkä tuotteet ja versiot ovat asiakkailla käytössä EU:n alueella.
  • Ohjelmistokomponenttiluettelo (SBOM). Kun tiedät, mitä kirjastoja ja riippuvuuksia tuotteissasi on, pystyt arvioimaan nopeasti, koskeeko julkistettu haavoittuvuus sinua. CRA edellyttää komponenttien dokumentointia myös osana pääsääntöisiä vaatimuksia.
  • Haavoittuvuuksien käsittelyprosessi. Määrittele, kuka vastaanottaa ilmoitukset, kuka arvioi vakavuuden ja kuka tekee viranomaisilmoituksen. Julkaise selkeä yhteystieto tietoturvailmoituksille, esimerkiksi security.txt-tiedosto verkkosivuille.
  • Päivystys ja tunnukset. SRP-alustalle kirjaudutaan EU Login -tunnuksilla, joten rekisteröidy ja testaa pääsy ennen kuin ensimmäinen kiireellinen tapaus tulee vastaan.
  • Tietoturvapäivitysten jakelu. Korjausten nopea toimittaminen asiakkaille vaikuttaa suoraan loppuraportin aikatauluun.

Valmistaudu jo nyt joulukuuhun 2027

Raportointi on vasta ensimmäinen vaihe. Joulukuusta 2027 alkaen tuotteiden on täytettävä asetuksen olennaiset kyberturvallisuusvaatimukset koko elinkaarensa ajan. Tähän kuuluvat muun muassa turvallinen oletuskonfiguraatio, riskiarvio, tekninen dokumentaatio, haavoittuvuuksien hallinta ja tietoturvapäivitykset tuen ajan. Monelle ohjelmistotalolle tämä tarkoittaa, että kehitysprosesseihin on rakennettava ”secure by design” -ajattelu: uhkamallinnus, koodikatselmoinnit, automaattinen riippuvuuksien skannaus ja testaus.

Avoimen lähdekoodin hyödyntäjälle on hyvä tietää, että valmistaja on vastuussa koko tuotteesta, myös sen sisältämistä avoimen lähdekoodin komponenteista. Avoin lähdekoodi on edelleen erinomainen ja kustannustehokas valinta, mutta riippuvuuksien seuranta ja päivittäminen on nyt entistä tärkeämpää. Kaupallisessa toiminnassa ylläpidettävien avoimen lähdekoodin projektien ylläpitäjille asetus tuo omat, kevyemmät velvoitteensa.

Esimerkki: ensimmäiset 72 tuntia

Kuvitellaan, että asiakas ilmoittaa maanantaiaamuna, että yrityksen verkkosovelluksen vanhaa kirjastoversiota käytetään parhaillaan hyökkäyksissä. Tiimi vahvistaa havainnon tunnissa, ja tietoturvavastaava tekee ennakkovaroituksen SRP-alustalle saman päivän aikana. Seuraavien kahden päivän aikana selvitetään, mitkä versiot ja asiakkaat ovat alttiina, kehitetään korjaus ja laaditaan väliaikaiset suojausohjeet. Varsinainen ilmoitus lähetetään keskiviikkona ennen 72 tunnin rajaa. Kun korjattu versio julkaistaan, loppuraportti tehdään kahden viikon kuluessa. Ilman valmiiksi sovittuja rooleja ja tunnuksia tällainen aikataulu olisi vaikea pitää.

Liiketoimintamahdollisuus, ei vain kustannus

CRA tasoittaa pelikenttää: kaikilta EU-markkinoilla toimivilta valmistajilta vaaditaan samaa perustasoa. Yritys, joka pystyy osoittamaan asiakkailleen hallitun haavoittuvuusprosessin ja ajantasaisen dokumentaation, erottuu edukseen julkisissa hankinnoissa ja yritysasiakkaiden kilpailutuksissa. Kun valmistautuminen aloitetaan nyt, vaatimukset voidaan rakentaa osaksi normaalia kehitystyötä eikä kiireellisenä projektina vuoden 2027 lopussa.

Huom. Artikkeli on yleiskatsaus eikä oikeudellista neuvontaa. Tarkista oman tuotteesi luokitus ja velvoitteet ajantasaisista virallisista lähteistä tai asiantuntijalta.

Lähteet