Molti team considerano il Cyber Resilience Act un problema da risolvere entro il 2027. Non è così. Il CRA non prevede un'unica data di entrata in vigore, bensì una tempistica scaglionata con tre tappe vincolanti tra il 2024 e il 2027, e quella più importante al momento è tra circa cinque settimane. Un'errata tempistica può comportare l'avvio dei lavori di conformità in ritardo o la perdita di mesi per prepararsi alla scadenza sbagliata. Ecco la cronologia completa del Cyber Resilience Act, le disposizioni già in vigore, quelle in arrivo e gli aspetti su cui concentrarsi se si sviluppano o distribuiscono prodotti con elementi digitali nell'UE.
Tempistiche del Cyber Resilience Act
| Data | Pietra miliare | Ciò che effettivamente richiede |
|---|---|---|
| 10 dicembre 2024 | Entra in vigore la legge CRA | Al momento non sussistono obblighi tecnici diretti, ma qualsiasi prodotto progettato da questo momento in poi verrà valutato in base ai requisiti della CRA (Community Reinvestment Act) una volta immesso sul mercato. |
| Dal 2025 a metà 2026 | Atti attuativi e delegati, armonizzati standards (CEN/CENELEC/ETSI) | Specifiche tecniche, SBOM Linee guida sul formato e gestione delle vulnerabilità standardIl regolamento di esecuzione (UE) 2025/2392 è stato adottato dalla Commissione il 28 novembre 2025 e nel dicembre 2025 è stato pubblicato un documento di domande e risposte sull'attuazione del CRA. |
| 11 giugno 2026 | Si applica il quadro di riferimento dell'organismo di valutazione della conformità | Gli Stati membri iniziano a designare e notificare gli organismi che effettueranno le verifiche di terze parti per i prodotti di Classe I e Classe II. |
| Luglio 27 2026 | La Commissione pubblica linee guida pratiche per l'attuazione. | Documento di lavoro per aiutare i produttori di tutte le dimensioni a interpretare i propri obblighi in vista della scadenza di settembre. |
| 11 settembre 2026 | Gli obblighi di segnalazione previsti dall'articolo 14 si applicano | I produttori devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi all'ENISA e al rispettivo CSIRT nazionale, entro 24 ore, 72 ore o 14 giorni. Tale obbligo si applica ai prodotti già presenti sul mercato, non solo a quelli nuovi. |
| 11 dicembre 2027 | Piena applicazione del CRA | I requisiti essenziali di sicurezza informatica, la documentazione tecnica, la valutazione della conformità e la marcatura CE diventano obbligatori per tutti i prodotti rientranti nell'ambito di applicazione immessi sul mercato dell'UE. |
tre di quelle righe sono quelle che effettivamente ti lego: 10 Dicembre 2024 (iscrizione entrata in vigore, rilevanza nella fase di progettazione), 11 Settembre 2026 (segnalazione) obblighi, quello che sta per scadere), and 11 Dicembre 2027 (completo applicazione). Le altre righe esistono per preparare l'infrastruttura per coloro tre.
Perché l'11 settembre 2026 è l' scadenza da costruire prima
Suo è allettante considerare il 2027 come il vero scadenza e il 2026 come riscaldamento. Questo è all'indietro, ed è l'errore che abbiamo ho trascorso un'intera sessione a disfare i bagagli con Jesus Cuadrado (CEO, Xygeni) and Nariman Aga-Tagiyev (Fondatore, SecureHabits) in 24 ore per la segnalazione: come sopravvivere al conto alla rovescia dell'Agenzia delle Entrate canadese.
Articolo 14's L'obbligo di segnalazione è il primo CRA requisito con effettivo operativo denti, e si applica dall'11 settembre 2026 per ogni prodotto incluso nell'ambito sul mercato UE, indipendentemente dal fatto che tu abbia spedito è successo l'ultimo trimestre o cinque anni fa. Non esiste una clausola di nonno per gli anziani prodotti una volta arrivata questa data. nel momento in cui ti rendi conto che un la vulnerabilità nel tuo prodotto è sfruttato attivamente o che tu abbia un grave incidente di sicurezza, l'orologio inizia:
- 24 ore per un inizio avvertimento all'ENISA e al vostro ente nazionale CSIRT
- 72 ore per un pieno notifica
- 14 giorni per la finale rapporto (o un mese per gravi incidenti non legati a un singolo vulnerabilità sfruttata)
Sanzioni per le violazioni più gravi arrivano fino a 15 milioni di euro, pari al 2.5% del fatturato annuo globale., qualunque sia il più alto.
"If quando venite a conoscenza di un exploit attivo, devi agire, anche se si tratta di un prodotto hai spedito dieci anni fa. Non c'è 'è un vecchio prodotto' eccezione in questo legge. " Nariman Aga-Tagiyev, Fondatore, SecureHabits (adattato dalla registrazione per chiarezza)
Come si manifesta concretamente, nella pratica, il "diventare consapevoli".
La parte della cronologia che la maggior parte dei team sottovaluta non è la scadenza in sé, ma la catena di eventi che devono accadere prima ancora che il conto alla rovescia inizi. Una scoperta nel tuo SCA or SAST Lo strumento non costituisce, di per sé, un incidente da segnalare. Il percorso è il seguente:
- Arriva una preoccupazione. Un avviso CVE, una segnalazione di bug bounty, un risultato di un penetration test, un avviso dello scanner, una divulgazione diretta.
- Si procede all'indagine, dando priorità ai casi più gravi. Si trova in ambiente di produzione o solo in fase di test? Esiste una vulnerabilità nota? Il tuo codice raggiunge effettivamente la funzione vulnerabile?
- Confermi (o escludi) lo sfruttamento attivo. Solo dopo aver accertato un effettivo sfruttamento ai danni tuoi o dei tuoi clienti, questo diventa un incidente.
- Il cronometro parte. Dalla conferma, hai 24 ore di tempo per l'allerta precoce.
Passare direttamente da "abbiamo trovato qualcosa" a "lo segnaliamo" significa inondare l'ENISA di rumore. Aspettare troppo a lungo per indagare significa perdere le 24 ore a disposizione per individuare qualcosa che si sarebbe dovuto rilevare nella prima ora.
"Senza gli strumenti adeguati predisposti in anticipo, buona fortuna a capire quali versioni del prodotto sono interessate entro tre o quattro ore." Nariman Aga-Tagiyev, fondatore di SecureHabits (adattato dalla registrazione per chiarezza).
Ciò che deve essere costruito prima di settembre, non durante
Tre fattori determinano se la tua squadra riuscirà effettivamente a rispettare la finestra temporale di 24 ore nel momento cruciale:
- Un'attuale, interrogabile SBOM. Devi sapere in pochi minuti, non in giorni, esattamente quali versioni del prodotto contengono un determinato componente e se è arrivato come dipendenza diretta o transitiva. Generare il tuo primo vero SBOM È dopo che il conto alla rovescia è iniziato che una scadenza di 24 ore si trasforma in una scadenza mancata.
- Un sistema di triage che distingue il rischio reale dal volume dei pazienti. La maggior parte delle organizzazioni porta migliaia di open SCA I risultati vengono rilevati in qualsiasi momento. Il CRA non richiede di chiuderli tutti, ma richiede di agire rapidamente su quelli accessibili nel codice, sfruttabili in ambienti reali e effettivamente in esecuzione in produzione.
- Un percorso di notifica che non si basa sul controllo da parte di qualcuno dashboard. Nel momento stesso in cui una scoperta passa dalla fase di "vulnerabilità" a quella di "sfruttamento attivo", la persona competente deve esserne informata automaticamente.
La sessione illustra questo processo end-to-end su una piattaforma live: configurazione di un prodotto su più repository, confronto SBOMIl rilascio di una versione dopo l'altra, l'imbuto di prioritizzazione che trasforma migliaia di risultati nella manciata di risultati raggiungibili e sfruttabili, e il flusso di lavoro dello stato degli incidenti (aperto → in fase di indagine → confermato → risolto) che produce la traccia di controllo che le autorità di regolamentazione e il tuo team legale richiederanno prima o poi.
Come Xygeni si inserisce nella cronologia del Cyber Resilience Act
Niente di tutto ciò funziona senza sapere, nel momento in cui una vulnerabilità si trasforma in un incidente confermato, se è effettivamente raggiungibile nel tuo codice e se esiste una soluzione che non comprometta nulla a valle. Questo è il livello di Xygeni ASPM la piattaforma si basa su: ingerisce i risultati dal tuo SCA, SAST, segreti e IaC Il sistema analizza le scansioni (anche tramite strumenti di terze parti che già utilizzi), le confronta con il modo in cui la tua applicazione viene effettivamente eseguita e ti indica quali rappresentano un rischio reale e quali invece sono solo rumore di fondo, prima che il tuo team perda ore a effettuare questa analisi manualmente.
"La vulnerabilità risiede in una specifica funzione del componente. Verifichiamo se il codice della tua applicazione raggiunge effettivamente tale funzione. In caso contrario, la vulnerabilità non viene sfruttata e nessuno può utilizzarla per attaccare la tua applicazione. E qualora ti riguardasse, nella maggior parte dei casi possiamo risolverla automaticamente, direttamente dalla piattaforma." Jesus Cuadrado, amministratore delegato di Xygeni
È questo il meccanismo che trasforma "abbiamo migliaia di segnalazioni aperte" in "ne abbiamo sedici rilevanti", ed è la stessa logica di raggiungibilità e risoluzione che deve essere alla base di qualsiasi flusso di lavoro di notifica CRA. I team che desiderano provare questa soluzione prima della scadenza di settembre possono iniziare con il piano Developer gratuito di Xygeni, senza costi, fino a 25 repository, senza bisogno di aspettare che il tempo a disposizione sia già iniziato per verificare la situazione.
La tempistica del Cyber Resilience Act non lascia spazio a una mentalità proiettata al 2027. L'11 settembre 2026 è la scadenza che metterà effettivamente alla prova l'efficacia della vostra risposta agli incidenti, e mancano circa cinque settimane.
FAQ
Quali sono le tempistiche previste dal Cyber Resilience Act?
Il CRA prevede tre tappe fondamentali vincolanti: l'entrata in vigore il 10 dicembre 2024, gli obblighi di segnalazione delle vulnerabilità e degli incidenti previsti dall'articolo 14 a partire dall'11 settembre 2026 e la piena applicazione, inclusa la valutazione della conformità e la marcatura CE, a partire dall'11 dicembre 2027. Una tappa correlata, il quadro normativo per gli organismi di valutazione della conformità, entrerà in vigore a partire dall'11 giugno 2026.
Cosa succederà l'11 settembre 2026?
I produttori di prodotti con elementi digitali venduti nell'UE devono iniziare a segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi all'ENISA e al rispettivo CSIRT nazionale, con un preavviso di 24 ore, una notifica entro 72 ore e una relazione finale entro 14 giorni (o un mese).
L'obbligo di segnalazione si applica anche ai prodotti già presenti sul mercato?
Sì. A differenza dell'applicazione completa da parte dell'Agenzia delle Entrate canadese (CRA) nel 2027, l'obbligo di segnalazione a partire da settembre 2026 si applica a tutti i prodotti rientranti nell'ambito di applicazione già disponibili sul mercato dell'UE, non solo ai nuovi lanci.
Qual è la scadenza definitiva del Cyber Resilience Act?
11 dicembre 2027. A partire da tale data, i requisiti essenziali di sicurezza informatica, la documentazione tecnica, la valutazione della conformità e gli obblighi di marcatura CE dell'Agenzia canadese per la protezione dei consumatori (CRA) si applicano integralmente ai prodotti rientranti nell'ambito di applicazione immessi sul mercato dell'UE.
Qual è la differenza tra le date di giugno 2026 e settembre 2026?
L'11 giugno 2026 entrerà in vigore il quadro giuridico per la notifica e la designazione degli organismi di valutazione della conformità (gli auditor per i prodotti di classe I e II), una pietra miliare operativa per le autorità di regolamentazione e gli organismi notificati. L'11 settembre 2026 entrerà in vigore l'obbligo vincolante di segnalazione per i fabbricanti stessi.
Quali sono le sanzioni previste per chi non rispetta una scadenza dell'Agenzia delle Entrate canadese (CRA)?
Le sanzioni per le violazioni più gravi possono raggiungere i 15 milioni di euro o il 2.5% del fatturato annuo globale, a seconda di quale dei due importi sia maggiore, con scaglioni di sanzioni inferiori per altri tipi di non conformità.
Guarda la sessione completa, “24 ore per la segnalazione: come sopravvivere al conto alla rovescia dell'Agenzia delle Entrate canadese"Con Jesus Cuadrado (Xygeni) e Nariman Aga-Tagiyev (SecureHabits), per una dimostrazione completa in diretta del flusso di lavoro di risposta agli incidenti, in vista della scadenza dell'11 settembre 2026!
