CRA-ilmoitusvelvollisuudet: tuotepassi, turvallisuusilmoitus ja päivityshistoria selkeästi erilleen

syyskuuta 2026 alkaa digitaalisen elementin sisältävien tuotteiden valmistajille yksi Cyber Resilience Actin (CRA) varhaisimmista operatiivisista velvoitteista: aktiivisesti hyödynnetyistä haavoittuvuuksista ja vakavista turvallisuuspoikkeamista on ilmoitettava uuden keskitetyn ilmoitusalustan kautta. Kyse ei ole vain uudesta vaatimustenmukaisuuden määräajasta. Muutaman tunnin kuluessa on yhdistettävä tuotteen tunnistetiedot, vaikutuksen alaiset markkinat, tekninen arvio ja toimenpiteet.

Digitaalinen tuotepassi tai QR-koodiin yhdistetty tuotesivu voi auttaa yksilöimään laitteen ja ilmoittamaan käyttäjille myöhemmin päivityksestä. Se ei kuitenkaan ole lakisääteinen ilmoituskanava eikä oikea säilytyspaikka luottamuksellisille hyväksikäyttöä koskeville tiedoille. Siksi valmistajien pitäisi erottaa nyt kolme tietopolkua: viranomaisilmoitus, julkinen tuotetieto ja sisäinen päivityshistoria.

Uusi lähtökohta: 27. ja 31. heinäkuuta julkaistut ohjeet

Euroopan komissio julkaisi ensimmäisen kattavan CRA-ohjeensa 27. heinäkuuta 2026. Se käsittelee muun muassa ilmoitusvelvollisuuksia, riskinarviointia, tukijaksoja ja merkittäviä muutoksia. Ohje ei ole sitova, mutta se täsmentää 67 esimerkin avulla, miten yritykset voivat soveltaa asetusta käytännössä.

Neljä päivää myöhemmin, 31. heinäkuuta, ENISA päivitti Single Reporting Platformia koskevat tietonsa. Sivulla esitetään nyt suunniteltu menettely, tarkoitetut syöttökentät ja rekisteröitymistä koskevat ohjeet. Alustan on määrä olla toimintavalmiina 11. syyskuuta 2026 mennessä; komission mukaan toiminnallisuus- ja turvallisuustestit ovat jo käynnissä.

Aikataulutus on tärkeä: CRA:n päävelvoitteita sovelletaan lähtökohtaisesti 11. joulukuuta 2027 alkaen. Ilmoitusvelvollisuuksia koskevaa 14 artiklaa sovelletaan kuitenkin jo 11. syyskuuta 2026 alkaen. Tämän vahvistavat sekä asetuksen (EU) 2024/2847 71 artikla että komission 31. heinäkuuta päivittämä yleiskatsaus CRA-ilmoitusmenettelyyn.

Kolme tietotilaa yhden ylikuormitetun tuotepassin sijaan

CRA-ilmoituksella ja julkisella tuotesivulla on eri tavoitteet. Jos molemmat kuvataan yhdessä tietueessa, vaarana on joko liian vähäinen tieto poikkeamatiimille tai liian monet arkaluonteiset tiedot julkisessa verkossa.

1. Luottamuksellinen ilmoitus SRP:lle, CSIRT:lle ja ENISA:lle

Single Reporting Platform on lakisääteinen ilmoituskanava. Ilmoitettavia tapahtumatyyppejä on kaksi: aktiivisesti hyödynnetty haavoittuvuus, josta on luotettavia viitteitä luvattomasta hyväksikäytöstä, sekä vakava poikkeama, joka heikentää tietojen tai toimintojen saatavuutta, aitoutta, eheyttä tai luottamuksellisuutta.

Ilmoitus ei sisällä vain tuotteen nimeä. ENISA luettelee kentiksi muun muassa vaikutuksen alaiset jäsenvaltiot, alustavan arvion, jo toteutetut vastatoimet, mahdolliset käyttäjätoimet ja tiedon arkaluonteisuuden. Myöhemmät vaiheet voivat sisältää vakavuusasteen, vaikutukset, hyökkääjää koskevat tiedot ja turvallisuuspäivityksen tekniset yksityiskohdat. Tällaiset tiedot eivät automaattisesti kuulu vapaasti saavutettavalle DPP-sivulle.

2. Julkinen tuote- ja turvallisuustieto

Julkinen tietopolku vastaa eri kysymyksiin: Minkä tuotteen ja version omistan? Tuetaanko sitä edelleen? Onko turvallisuuspäivitys saatavilla? Mitä minun käyttäjänä on konkreettisesti tehtävä? Tätä varten QR-koodin tai muun tietovälineen takana oleva pysyvä tuotesivu voi olla järkevä ratkaisu.

Julkisella sivulla pitäisi näyttää vain hyväksytyt tiedot: vaikutuksen alaiset malli- ja versioalueet, saatavilla oleva turvallinen versio, asennusohjeet, tukiyhteystieto ja julkaisuajankohta. Hyväksikäyttöä koskevat yksityiskohdat, sisäiset tunnistussäännöt, paikkaamattomat hyökkäysreitit ja henkilötiedot sisältävät poikkeamatiedot säilyvät suojatussa menettelyssä. Päätöstä julkisesta varoituksesta ei tee QR-koodi: CRA:n 17 artiklan mukaan koordinoiva CSIRT voi tiedottaa yleisölle tai pyytää valmistajaa tekemään niin, jos se on tarpeen ehkäisemiseksi tai rajoittamiseksi.

3. Sisäinen päivitys- ja näyttöhistoria

Kolmas polku on jäljitettävä työasiakirja. Se yhdistää tuotetunnuksen, laitteisto- ja ohjelmistoversion, ohjelmistoluettelon, tiedoksisaannin ajankohdan, triage-päätökset, ilmoitusvaiheet, korjaustiedoston hyväksynnän ja julkisen tiedotteen. Tässä historiassa muutokset on versioitava sen sijaan, että aiemmat arviot korvattaisiin huomaamatta.

DPP-toiminnassa tämä ero on keskeinen: julkinen näkymä näyttää ajantasaisen hyväksytyn tilan, kun taas sisäinen historia osoittaa, miten siihen päädyttiin. Jos tuotetietoja ylläpidetään jo tapahtumapohjaisesti, samaa periaatetta voidaan hyödyntää kuin DPP-päivityksissä ja webhookeissa: tapahtuma käynnistää jatkoprosessit, mutta jokainen vastaanottaja saa vain roolinsa mukaiset kentät.

CRA-kello alkaa tiedonsaannista

14 artiklassa käytetään porrastettuja määräaikoja. Aktiivisesti hyödynnetystä haavoittuvuudesta on annettava ennakkovaroitus ilman aiheetonta viivytystä ja viimeistään 24 tunnin kuluessa tiedonsaannista. Yksityiskohtaisempi haavoittuvuusilmoitus seuraa 72 tunnin kuluessa. Loppuraportin on oltava saatavilla viimeistään 14 päivän kuluttua siitä, kun korjaava tai lieventävä toimenpide on käytettävissä.

Myös vakavasta turvallisuuspoikkeamasta ennakkovaroitus on annettava 24 tunnin kuluessa ja poikkeamailmoitus 72 tunnin kuluessa. Loppuraportti toimitetaan kuukauden kuluessa 72 tunnin ilmoituksesta. Määräajat eivät siis ala CVE:n julkaisemisesta eivätkä seuraavasta säännönmukaisesta julkaisusta, vaan siitä hetkestä, kun valmistajan katsotaan saaneen tiedon.

Käytännössä suositellaan selkeää menettelyä:

Kirjaa tukipalvelusta, valvonnasta, tutkimuksesta tai toimitusketjusta saapunut tieto aikaleimoineen.
Yhdistä tuote ja versio vakaaseen sisäiseen tuotetunnukseen.
Arvioi hyväksikäyttö tai poikkeaman vakavuus vastuullisessa tiimissä.
Muodosta 24 tunnin tietue vahvistetuista vähimmäistiedoista ja toimita se SRP:n kautta.
Täydennä teknisiä havaintoja 72 tunnin vaiheeseen asti menettämättä alkuperäistä tilaa.
Hyväksy korjaustiedosto, käyttäjätoimi ja julkinen tieto erikseen.
Yhdistä loppuraportti ja sisäinen historia toisiinsa.

Tämä ketju pitäisi harjoitella ennen syyskuuta. ENISA huomauttaa, että organisaatiot voivat automatisoida sisäiset prosessinsa ja tietokantansa, mutta alusta ei käynnistyessään tarjoa API-rajapintaa. Siksi vienti- ja kaksoistarkastusmenettely on realistisempi kuin tarkistamaton suora integraatio.

Yhteinen tuotetunnus, mutta erilliset käyttöoikeudet

Erottaminen ei tarkoita kolmen toisiinsa liittymättömän kopion ylläpitoa. Parempi lähestymistapa on yhteinen, muuttumaton tuoteviite, josta tarjotaan rooliperusteisia näkymiä.

Vähintään seuraavat yhdistämiset pitäisi olla saatavilla:

sisäinen tuotetunnus sekä malli-, erä- tai sarjanumeroviite;
laitteisto-, laiteohjelmisto- ja ohjelmistoversio;
jäsenvaltiot, joissa vaikutuksen alainen toteutus on asetettu saataville;
turvallisuusarvion tila ja tiedonsaannin ajankohta;
viitteet 24 ja 72 tunnin ilmoituksiin sekä loppuraporttiin;
hyväksytty käyttäjätoimi ja turvallinen kohdeversio;
julkisen tuotesivun julkaisutila.

Valtuutus pitäisi suunnitella kenttäkohtaisesti. Poikkeamatiimi ja CRA-vastaavat tarvitsevat koko asiakirjan. Tuki ja myynti tarvitsevat hyväksytyn toimintaohjeen. Käyttäjät näkevät vain julkisen ilmoituksen. QR-koodi välittää ihanteellisesti vain pysyvän tuoteosoitteen; sen taustalla oleva alusta päättää tilan ja roolin perusteella, mitä tietoa toimitetaan.

Mitä valmistajien pitäisi testata ennen syyskuuta

Hyvä testitapaus ei tarvitse todellista haavoittuvuutta. Valitse verkotettu tuote, vaikutuksen alainen laiteohjelmistoversio ja kolme jäsenvaltiota. Simuloi tiedonsaanti työpäivänä ja tarkista:

Pystyykö tiimi vahvistamaan tuotteen kattavuuden ja vähimmäistiedot 24 tunnin kuluessa?
Onko selvää, kenen edustajan pitäisi käyttää SRP:tä EU Loginilla?
Voidaanko 72 tunnin tiedot lisätä ilman luottamuksellisten tietojen julkaisemista?
Johtaako korjaustiedoston hyväksyntä tarkistettuun käyttäjätietoon kaikilla tarvittavilla kielillä?
Pysyykö julkinen URL-osoite vakaana, kun versio ja toimenpiteet muuttuvat?
Onko jäljitettävissä, kuka hyväksyi minkäkin tilan ja milloin?

Viimeiseen kohtaan auttaa johdonmukainen, versioitu tietojen ylläpito. qr3:n artikkeli jatkuvasta DPP-päivityksestä esittelee perusidean: identiteetti säilyy vakaana, kun taas asiantuntijatietoja päivitetään hallitusti. CRA-prosessissa tähän lisätään tiukempi luottamuksellisuus- ja hyväksyntäkerros.

Yhteenveto: tuotepassi on jakelija, ei ilmoituspaikka

Uudet ohjeet tekevät syyskuun määräajasta käytännössä selkeän. Valmistajien ei tarvitse sisällyttää luottamuksellista haavoittuvuustietokantaa digitaaliseen tuotepassiinsa. Sen sijaan tarvitaan luotettava yhteys kolmen selkeästi erotetun alueen välillä: viranomaisilmoitus, sisäinen näyttö ja hyväksytty käyttäjätieto.

Yhteinen tuotetunnus pitää nämä alueet yhdessä. Roolit, hyväksynnät ja versiointi estävät luottamuksellisten tietojen päätymisen ulos tai sen, että käyttäjät saavat tiedon saatavilla olevasta toimenpiteestä liian myöhään. QR-koodi säilyy hyödyllisenä, mutta tarkoituksellisen vaatimattomana: se johtaa pysyvästi oikeaan tuoteyhteyteen. Var sinainen CRA-vaatimustenmukaisuus syntyy taustalla olevissa prosesseissa.