Siamo a pochi mesi dalla scadenza più critica dell’agenda compliance europea del 2026. L’11 settembre 2026 entra in vigore l’obbligo di segnalazione delle vulnerabilità secondo il Cyber Resilience Act (CRA), e nella mia esperienza di System Administrator e consulente di sicurezza, ho visto pochi team davvero pronti. Non è una questione teorica: parliamo di penalità fino a 15 milioni di euro o il 2,5% del fatturato globale, e di procedure operative che devono funzionare in tempo reale, con scadenze di 24 e 72 ore dal momento della consapevolezza di una vulnerabilità attivamente sfruttata.
Questo articolo trasforma i requisiti normativi del CRA in una checklist operativa concreta, con procedure step-by-step che ho testato direttamente in ambienti enterprise. Non è teoria: è quello che funziona sul campo per le imprese italiane che vendono o distribuiscono prodotti digitali verso il mercato UE.
Il Perché Settembre 2026 è il Vero Deadline (Non Dicembre 2027)
Il CRA è entrato in vigore a dicembre 2024, con due scadenze critiche: la segnalazione obbligatoria inizia l’11 settembre 2026, e il CRA si applica completamente il 11 dicembre 2027. Molti responsabili compliance hanno calendarizzato il dicembre 2027, ma sbagliano profondamente. La segnalazione delle vulnerabilità parte 15 mesi prima della conformità totale, e gli obblighi di segnalazione si applicano anche ai prodotti legacy già immessi sul mercato UE prima che il CRA si applichi pienamente.
Nel mio lavoro con aziende che producono software, plugin WordPress, device IoT e componenti embedded, ho visto accadere così: un’impresa ha un prodotto lanciato nel 2019, ancora in vendita nel 2026, viene scoperta una vulnerabilità attivamente sfruttata in agosto 2026. Dal momento in cui ne diviene consapevole, parte un timer a 24 ore. Non c’è negoziazione.
La Timeline di Segnalazione: Come Funziona la Disciplina 24/72/14 Giorni
I produttori devono inviare un avviso iniziale entro 24 ore dalla consapevolezza e una notifica completa entro 72 ore. Una relazione finale deve essere presentata non oltre 14 giorni dopo che una misura correttiva è disponibile per le vulnerabilità attivamente sfruttate.
Questa non è una procedura documentale astratta. Ho implementato questa disciplina in ambienti multi-cloud, e la chiave è capire cosa significano esattamente le tre fasi:
Fase 1: Early Warning (24 Ore)
Entro 24 ore dall’avviso, è richiesta una notifica iniziale che comunica il verificarsi di una vulnerabilità attivamente sfruttata o di un incidente grave, incluso se si sospetta sia causato da atti illeciti o malvagi. Non deve essere perfetta. Deve essere: timestamp, ID prodotto, conferma che è attivamente sfruttata, conferma che la vostra organizzazione ne è a conoscenza.
Il mio consiglio: usate un template minimalista nella vostra piattaforma di ticketing, pre-compilate le informazioni di cui avete già il controllo (organizzazione, CSIRTs nazionali a cui rapportarsi, contatti tecnici). Il tempo di ritardo qui viene misurato in ore.
Fase 2: Full Notification (72 Ore)
Entro 72 ore è richiesto un resoconto più completo che includa una valutazione iniziale, gravità e impatto, e dove disponibile le misure correttive o di attenuazione adottate. Qui entrano i dettagli: CVSS score, numero di istanze interessate, utenti potenzialmente impattati, patch status o timeline, workaround temporanei.
Nel mio lavoro recente con una società di hosting, questo step ha richiesto coordinamento tra team di sicurezza, sviluppo e operazioni. Ho automatizzato parte di questo compilando una CVSS template in base al tipo di vulnerabilità, in modo che il team tecnico dovesse solo confermare o correggere il punteggio.
Fase 3: Final Report (14 Giorni o 1 Mese)
Una relazione finale deve essere presentata non oltre 14 giorni dopo una misura correttiva per le vulnerabilità attivamente sfruttate, e entro un mese per gli incidenti gravi. Qui documentate la risoluzione completa: patch applicata, validazione di efficacia, comunicazioni agli utenti, tempo totale da discovery a remediation.
Dove Segnalare: La Piattaforma Unica ENISA
La segnalazione avviene tramite un unico canale: l’Unione Single Reporting Platform di ENISA, indirizzata alla CSIRT nazionale designata del luogo di stabilimento principale. No, non comunicate a 27 stati membri separatamente. Una sola submissione via piattaforma ENISA.
Le CSIRT nazionali italiane ricevono le notifiche e le propagano ad altre autorità se necessario (come ACN, l’Agenzia per la Cybersicurezza Nazionale). Il vostro interlocutore unico è la CSIRT del vostro paese di residenza.
Cosa Significa Essere “Consapevoli” di una Vulnerabilità?
Questo è il punto che genera più confusione. Non significa 24 ore dalla remediation, non significa 24 ore da un’analisi root-cause completa, ma 24 ore dal momento in cui sapete che la vulnerabilità esiste ed è sfruttabile.
Nell’esperienza pratica:
- Un ricercatore invia una segnalazione via il vostro coordinamento vulnerabilità disclosure (CVD) alle 10:00 di lunedì e asserisce che la vulnerabilità è attivamente sfruttata in wild? Inizia qui il timer. Non da quando la validate, non da quando la capite, da quando la ricevete.
- Vedete un alert dalla vostra piattaforma di threat intelligence che una CVE del vostro prodotto è in exploit exploit kit? Timer inizia.
- La CSIRT locale vi contatta per una vulnerabilità zero-day nel vostro software? Timer inizia.
Per questo motivo, qualsiasi processo manuale nel vostro workflow di vulnerability management che non possa completarsi entro quella finestra è un rischio di conformità. Qualsiasi lacuna nella visibilità dei componenti che possa ritardare la consapevolezza di una vulnerabilità appena divulgata è un rischio di conformità. Qualsiasi ambiguità su chi nell’organizzazione sia responsabile di iniziare il processo di notifica è un rischio di conformità.
Checklist Operativa: I 7 Passi Fondamentali per Settembre 2026
Passo 1: Definire il Perimetro dei Prodotti in Scope
Non ogni cosa che producete è soggetta al CRA. La normativa si applica a “prodotti con elementi digitali” – software, device IoT, sistemi embedded, firmware. Nel mio team, abbiamo mappato:
- Software proprietario distribuito via cloud o on-premise: SCOPE
- Plugin WordPress commerciali o freemium: SCOPE
- Componenti embedded in router/switch: SCOPE
- Servizi di consulenza pura: OUT OF SCOPE
- Documentazione tecnica: OUT OF SCOPE
Create un inventario Excel o foglio Google con: ID prodotto, versioni in supporto, data lancio sul mercato UE, classification (critico/importante/altro), proprietario del prodotto, responsabile della sicurezza.
Passo 2: Implementare la Software Bill of Materials (SBOM)
Il clock di segnalazione, gli obblighi di patching e l’audit evidence dipendono tutti da una cosa: sapere esattamente cosa è stato spedito dentro il vostro prodotto. Sbagliare questo punto, e ogni obbligo downstream si rompe.
Nel mio workflow con Plesk e WordPress, genero SBOM utilizzando strumenti como Cyclone DX o SPDX. Per WordPress, ad esempio:
- Versione core di WordPress
- Tutte le dipendenze PHP (tramite Composer)
- Tutti i plugin commerciali + loro versioni
- Librerie JavaScript esterne (npm, yarn)
- Versioni di librerie di sistema (OpenSSL, libcurl, ecc.)
Una SBOM non è un documento statico. Deve essere rigenerata ogni volta che aggiornate un componente, ogni release di prodotto, come parte dell’automazione CI/CD.
Passo 3: Mettere in Piedi un Coordinated Vulnerability Disclosure (CVD) Program
Impostate una politica di divulgazione coordinata e un unico punto di contatto, allineati a ISO/IEC 29147 e ISO/IEC 30111.
Praticamente, questo significa:
- Una pagina security.txt nel vostro sito (/.well-known/security.txt) che pubblica come contattare il vostro team di sicurezza
- Un indirizzo email dedicato tipo security@vostrodominio.com, con risposta garantita entro 24 ore
- Una chiave PGP pubblica per ricevere segnalazioni criptate
- Una politica scritta che specifica: come rapportarsi, tempistiche di risposta, embargo periods, accrediti
Ho usato HackerOne o Bugcrowd per automatizzare questo, ma per PMI una semplice mailbox monitorata con ticketing internal funziona.
Passo 4: Designare il Reporter CRA e l’Escalation Chain
Chi effettivamente presenta la notifica? Chi è il backup se sono in vacanza? Chi ha l’autorità di decidere se un segnale è “attivamente sfruttato”? In molte organizzazioni, la risposta è “lo decidessimo al momento”. Questa è la risposta che produce una deadline mancata.
Nel mio setup interno:
- Primary Reporter: Head of Product Security (o CISO se azienda piccola)
- Backup Reporter: Security Engineering Lead
- Authorized Escalation: CTO può forzare una segnalazione in caso di disagreement
- Channel di comunicazione: Slack dedicated + trigger automatico se la CVE della vostra app appare in public feeds
Documentate questi ruoli per iscritto, allegate le responsabilità, condividete con il team. NON lasciate che sia “everyone’s responsibility” – diventa nessuno’s responsibility.
Passo 5: Automatizzare la Consapevolezza di Vulnerabilità
Incontrare un obbligo di notifica a 24 ore in modo affidabile richiede automazione. Lo scanning point-in-time non è compatibile con requisiti di notifica a 24 ore.
Nel mio ambiente, ho implementato:
- Continuous SBOM scanning: Integrato in CI/CD, esecuzione su ogni commit o merge
- CVE feed parsing: Subscribe a NVD, Vulners, GitHub Security Advisory con automazione che tira nuove CVE ogni ora
- Correlation: Match automatico tra SBOM components e nuove CVE pubblicate
- Alert escalation: Se una CVE del vostro prodotto appare in threat intelligence (Shodan query, honeypot hits, exploit kit listings), alert immediato a Slack/PagerDuty
- Exploit confirmation: Integrate con Censys, Shodan, CISA KEV per verificare se davvero “attivamente sfruttata” prima di escalare al reporter
Strumenti: Black Duck, Snyk, Dependabot (gratuito per GitHub), Trivy, OWASP Dependency-Check sono entry points. Per aziende più grandi, Rapid7 InsightVM o Qualys per continuous assessment.
Passo 6: Templatizzare il Processo di Notifica ENISA
La piattaforma ENISA richiede informazioni specifiche strutturate. Nel mio team, ho pre-compilato un template Markdown che il reporter compila in 5 minuti:
## EARLY WARNING (24 Hours)
- **Product ID:** [Auto-filled from SBOM]
- **Affected Versions:** [Auto-filled]
- **Vulnerability Type:** [XSS / RCE / Auth Bypass / etc]
- **Actively Exploited:** YES (confirm with evidence link)
- **Severity (CVSS):** [Placeholder]
- **Date Discovered:** [Now]
- **Temporary Mitigations:** [List or TBD]
## FULL NOTIFICATION (72 Hours)
- Completa il template con: CVSS dettagliato, affected users count, patch status, user-facing mitigations
## FINAL REPORT (14 Days)
- Root cause, fix deployed, validation results, timeline totale da discovery a patch
Salvo questo come issue template nel vostro sistema di ticketing. Quando il reporter apre un ticket marcato “CRA Vulnerability”, il template pre-popola automaticamente con timeline di scadenza.
Passo 7: Praticare la Procedura con Esercitazioni Tabletop
Non potete farlo bene al primo tentativo sotto stress. Non è un problema di documentazione. È un problema di workflow detection-to-disclosure, e chi ha successo avrà praticato prima di settembre.
Nel mio team, facciamo “incident drills” trimestrali:
- Scenario 1: Ricevete un CVE pubblico della vostra app dal NVD. Quanti minuti per far partire il timer?
- Scenario 2: Un ricercatore scopre RCE nel vostro prodotto, vi contatta tramite security.txt. Timeline di triage fino alla scadenza di 24 ore?
- Scenario 3: Vedete la vostra app in un exploit kit su Shodan. Come confermate che è “attivamente sfruttata”? Chi contattate? Quando comunicate agli utenti?
Documentate i tempi reali. Se il vostro mean time to triage è 6 ore e dovete reportare in 24 ore, vi rimangono 18 ore per raccogliere dettagli. Se è 20 ore, siete a rischio di miss – allora automatizzate di più.
Risk Assessment Framework per Imprese Italiane
Nel contesto italiano, dove molte aziende distribuiscono software verso l’UE ma non sono in UE, vi suggerisco questo framework di risk assessment:
Matrice Risk: Scope x Readiness
- Scope Alto + Readiness Bassa = CRITICAL RISK
Producete software critico (sistema bancario, healthcare, infrastruttura) e non avete SBOM né CVD. Azione immediata richiesta entro agosto 2026. - Scope Alto + Readiness Alta = MONITORED
Avete SBOM, CVD, automazione. Fare test della procedura ogni mese. - Scope Basso + Readiness Bassa = MEDIUM RISK
Plugin o software non-critico senza SBOM. Implementate almeno SBOM + CVD entro luglio 2026. - Scope Basso + Readiness Alta = LOW RISK
Monitorare e mantenere.
Implicazioni NIS2 e Overlapping Compliance
Se una vulnerabilità o incidente coinvolge dati personali, i requisiti GDPR possono richiedere una notifica separata all’autorità competente (solitamente entro 72 ore). Inoltre, i requisiti di notifica del Direttiva NIS2 e le leggi di implementazione dei Member State UE possono applicarsi, creando ulteriori obblighi per early warning e follow-up di incidente alla CSIRT nazionale. È quindi cruciale assicurarsi che i protocolli di incident response siano armonizzati tra CRA, GDPR, NIS2 e altri regimi applicabili.
Nel mio workflow con aziende italiane che hanno utenti UE:
- Se l’incidente riguarda dati: notificate simultaneamente GDPR authority + CRA + CSIRT
- Se colpite un’infrastruttura critica (ospedale, utility, banca): NIS2 obligations si sommano
- Coordinate i template di notifica. Non ripetete 3 volte la stessa cosa a tre regolatori diversi – un’unica notifica strutturata che indirizzate a tutti.
Cosa Succede se Fallite: Penalty e Enforcement
Voglio essere chiaro sul rischio reale. Le severe breaches hanno multa massime fino a 15 milioni di euro o il 2,5% del fatturato globale (quale sia più alto). Non è una minaccia teorica. L’infrastruttura di enforcement ENISA, CSIRTs, e conformity assessment bodies è già operativa e sarà pienamente attiva a settembre.
Inoltre, la scadenza di settembre 2026 non è un target soft. Le autorità di sorveglianza del mercato UE avranno il potere di far rispettare, e l’infrastruttura normativa (ENISA’s Single Reporting Platform, CSIRTs designate, conformity assessment bodies) è stata istituita proprio ora.
FAQ
Se il mio prodotto è venduto solo in Italia e non direttamente in UE, devo comunque rispettare CRA?
Sì. Il CRA si applica a “prodotto with digital elements placed on the EU market”. Se un vostro cliente italiano lo revende in UE, o se è distribuito tramite marketplace europei, è in scope. La giurisdizione è il mercato destinatario, non la vostra residenza. Preparatevi come se il vostro prodotto raggiunge l’UE.
Chi è responsabile se la vulnerabilità è in una libreria open-source che usiamo?
Voi siete comunque responsabili di segnalarla. Il CRA vi obbliga a monitorare, identificare e rapportare vulnerabilità attivamente sfruttate nei vostri prodotti, indipendentemente dall’origine del codice. Se quel componente open-source ha una CVE e il vostro prodotto lo include, dovete reportare quando essa diventa attivamente sfruttata.
Come faccio a sapere se una vulnerabilità è “attivamente sfruttata”?
Cercate evidenza affidabile di attività malevola reale che sfrutta la vulnerabilità: codice di exploit pubblico, campagne di attacco documentate in threat intelligence, honeypot hits, listing in exploit kit. Non basta una CVE pubblica. Serve prova che qualcuno la sta usando in attack reale. CISA KEV (Known Exploited Vulnerabilities) è una buona referenza pubblica.
Se scopro io la vulnerabilità prima che sia pubblica, devo ancora reportare in 24 ore?
Sì, se è attivamente sfruttata. Se la scoprite internamente prima che sia pubblica, dovete determinare velocemente se è già in wild exploitation. Se sì, il clock parte. Se no, potete coordinarvi con la divulgazione ordinaria senza forzare il tempo reale di 24 ore (a meno che diventasse active durante il vostro embargo).
Che cosa accade se sbagliamo la deadline di 24 ore?
Documentate comunque il ritardo, i motivi (es. sistema ENISA temporaneamente giù, impossibilità di contattare il reporter per conferma), e inviate il report il prima possibile con una nota sulla tempistica. ENISA considera “without undue delay” quindi ha una certa flessibilità se l’evento era al di là del vostro controllo. Ma non è scusa. Fate la pratica ora per non doverlo sperare in settembre.
Conclusione: Agite Adesso, Non a Settembre
Il CRA compliance checklist per vulnerabilità disclosure non è una lista di boxes da spuntare il 10 settembre. È un’infrastruttura operativa che dovete costruire, testare e validare adesso. Nei miei ultimi tre mesi di lavoro con imprese italiane nel software e hosting, ho visto chi ha iniziato questo percorso ad aprile-maggio arrivare a settembre con tranquillità operativa. Chi aspetta luglio non dorme a novembre.
La formula è semplice: SBOM + CVD + Automazione + Pratiche Tabletop + Documentazione = Conformità CRA. Niente di questi elementi è opzionale.
Se operate nel mercato digitale europeo, questo non è una compliance task, è una business continuity requirement. Iniziate domani. Contattatemi pure nei commenti se volete condividere la vostra implementazione.
Link interni utili: Se state lavorando su vulnerability disclosure per WordPress, leggete WordPress 7.0 Plugin Vulnerability Disclosure Program Compliance EU. Per compliance governance più ampia, NIS2 Compliance Readiness Luglio 2026 è un reference correlato.