Nel mio lavoro da System Administrator e IT Specialist, affronto quotidianamente la gestione della sicurezza infrastrutturale. Negli ultimi mesi, il Cyber Resilience Act (CRA) è diventato un tema centrale: non è più una prospettiva lontana, ma un obbligo concreto che chi fornisce servizi di hosting deve implementare subito. Non fra tre anni – fra pochi mesi. Vi mostro come affrontarlo nella pratica.
Il CRA, Regolamento (UE) 2024/2847, è entrato in vigore il 10 dicembre 2024, ma questo è solo l’inizio. Le principali obbligazioni si applicheranno dal 11 dicembre 2027, mentre gli obblighi di segnalazione entrano in vigore il 11 settembre 2026. Per chi gestisce server, cloud e infrastrutture digitate, questo rappresenta un cambio paradigmatico: la sicurezza non è più opzionale, è una condizione di accesso al mercato europeo.
Il CRA: Una Visione Normativa Nuova
Il Cyber Resilience Act è un regolamento europeo che impone requisiti minimi di sicurezza informatica per tutti i prodotti digitali immessi nel mercato UE, siano essi hardware o software. Per i provider hosting, questo significa che i servizi devono essere costruiti per la sicurezza sin dalla progettazione, mantenere una bill of materials del software, gestire attivamente le vulnerabilità e segnalare gli incidenti dentro tempi ristretti.
La novità radicale: il regolamento esige un cambiamento culturale che parte dalle fondamenta, in cui i prodotti devono essere concepiti secondo i principi di secure-by-design e by-default, poiché la sicurezza non può più essere un’aggiunta finale ma deve essere una caratteristica intrinseca del progetto.
Scadenze Critiche: Il Calendario 2026-2027
Nel mio percorso di compliance finora, ho imparato che le scadenze non sono negoziabili. Ecco le date che contano davvero:
11 Giugno 2026: Designazione delle Autorità Notificanti
Gli Stati membri devono designare entro l’11 giugno 2026 le autorità notificanti responsabili della procedura di valutazione e notificazione degli organismi di valutazione della conformità. Per un provider hosting, questo significa che il sistema di certificazione inizia a prendere forma: se il vostro servizio rientra nella categoria “importante” o “critica”, a partire da questa data potrete sapere quali enti terzi controlleranno la vostra conformità.
11 Settembre 2026: Obbligo di Segnalazione Vulnerabilità
Questa è la vera sveglia. A partire dall’11 settembre 2026, i produttori sono tenuti a segnalare vulnerabilità attivamente sfruttate e incidenti gravi. Devono presentare un avviso anticipato entro 24 ore dal rilevamento e una notifica completa entro 72 ore, con un rapporto finale entro 14 giorni da quando è disponibile una misura correttiva.
Nella mia esperienza, affrontare questa tempistica senza automazione è impossibile. Ho visto aziende panicate perché avevano il SBOM (Software Bill of Materials) ancora in foglio Excel. Se non avete SBOMs e un processo di gestione delle vulnerabilità in posto prima di settembre 2026, non potete conformarvi, il che rende l’SBOM un requisito di fatto almeno 15 mesi prima della scadenza ufficiale di dicembre 2027.
11 Dicembre 2027: Piena Applicabilità
Da questo giorno, nessun prodotto digitale potrà essere venduto nell’Unione Europea se non conforme al CRA. Questo non è un consiglio, è una barriera di mercato. Se il vostro Plesk Obsidian, i vostri container, la vostra piattaforma di hosting non soddisfano gli standard essenziali di cybersecurity, non potete offrirli ai clienti europei.
SBOM: Il Cuore Operativo del CRA
La Software Bill of Materials è il documento centrale della conformità CRA. Documenta tutti i componenti di un prodotto software – incluse le librerie open-source, le dipendenze transitive e le loro licenze – e il CRA richiede l’SBOM come parte della documentazione tecnica da sottoporre alle autorità di sorveglianza del mercato su richiesta.
Nel mio setup di Plesk, ho dovuto affrontare questo problema subito. Come accadde con il Log4Shell nel 2021 – quando gli attaccanti iniziarono lo sfruttamento entro ore – le aziende non sapevano se Log4j era presente nei loro sistemi, perché appariva come dipendenza transitiva. I team hanno speso giorni a cercare manualmente nei repository. Con un SBOM aggiornato, avreste avuto la risposta in secondi.
Generazione Automatica dell’SBOM
La creazione manuale dell’SBOM non è praticabile nei cicli di rilascio agili, quindi la generazione deve essere automatizzata nella pipeline di build. Nella mia procedura su Plesk Obsidian:
- Integro SBOM nella CI/CD: Ogni build genera automaticamente un SBOM in formato CycloneDX o SPDX JSON.
- Scansione vulnerabilità continua: Lo SBOM passa a uno scanner (Grype, Trivy, Anchore) che verifica CVE note per ogni componente.
- Archiviazione versionate: Mantengo uno storico SBOM per ogni versione rilasciata, facilmente reperibile da autorità e clienti.
Formati Standardizzati: CycloneDX vs SPDX
CycloneDX è un formato JSON/XML leggero, specifico per i casi di sicurezza, supporta nativamente i riferimenti a vulnerabilità (VEX) e il mapping delle dipendenze di servizi. È consigliato per chi pensa alla sicurezza prima. SPDX è uno standard ISO 5962 più completo, focalizzato su conformità licenze. È più appropriato quando accanto alla sicurezza la conformità alle licenze è prioritaria.
Nel mio laboratorio, uso CycloneDX 1.5+ in JSON come standard perché si integra meglio con gli scanner di vulnerabilità moderni. Il CRA richiede che i fabbricanti forniscano l’SBOM almeno per le dipendenze dirette, in formato leggibile da macchina (SPDX o equivalente), coprendo le dipendenze di livello superiore.
Vulnerability Disclosure: Processo Strutturato
I fabbricanti devono implementare un processo coordinato di disclosure delle vulnerabilità con una mailing list accessibile pubblicamente (ad esempio security.txt secondo RFC 9116), tempi di risposta definiti, una struttura interna di triage e la capacità di fornire patch tempestivamente.
Nella pratica di Plesk Obsidian, ho strutturato così:
1. Canale di Ricezione: security.txt
Ho creato un file `/.well-known/security.txt` su ogni dominio di hosting che fornisco, seguendo RFC 9116:
Contact: security@darioiannascoli.it Expires: 2027-05-15T00:00:00Z Preferred-Languages: it, en Canonical: https://darioiannascoli.it/.well-known/security.txt
I ricercatori di sicurezza sanno dove segnalare. Nessun giro di comunicazioni, nessuna confusione.
2. Team di Triage Interno (PSIRT)
Per una piccola azienda senza SOC 24/7, è necessario un Product Security Incident Response Team con ruoli chiari, avvisi automatizzati e template di notifica pre-scritti per rispettare i tempi di segnalazione di 24/72/14 giorni.
Nel mio setup:
- Responsabile triage: Io (valutazione iniziale della segnalazione).
- Ingegnere di sicurezza: Verifica la vulnerabilità e valuta CVSS.
- Lead sviluppo: Pianifica e implementa la patch.
- Comunicazione: Redige il bollettino di sicurezza.
3. Segnalazione ENISA (11 Settembre 2026 in poi)
I fabbricanti segnalano una sola volta attraverso la CRA Single Reporting Platform a indirizzo del CSIRT del paese dove hanno la sede principale, e le informazioni vengono messe simultaneamente a disposizione di ENISA.
La Single Reporting Platform sarà operativa per l’11 settembre 2026, con un periodo di testing prima di allora. Ho già prenotato il mio account di test.
Compliance per Provider Hosting: Responsabilità Condivisa
Una domanda cruciale che mi è stata posta: “Se fornisco hosting a una software house che produce un’applicazione web, chi è responsabile della conformità CRA?”
Il CRA introduce una responsabilità condivisa, ma con obblighi specifici per i produttori. La software house ha il dovere di rilasciare un prodotto sicuro by design e fornire aggiornamenti di sicurezza per un periodo definito (spesso 5 anni). Tuttavia, l’azienda committente (chi usa il software) è responsabile dell’installazione di tali aggiornamenti e dell’uso corretto del software.
Per un provider hosting:
- Responsabilità del provider (me): Mantenere l’infrastruttura Plesk, nginx, PHP, MariaDB sicuri. Fornire patch di sicurezza gratuite per minimo 5 anni. Gestire vulnerabilità del mio stack.
- Responsabilità del cliente: Mantenere i plugin WordPress, i temi e il codice custom aggiornati. Configurare in sicurezza il loro sito. Usare le credenziali forti.
La NIS2 impone obblighi di cybersecurity alle organizzazioni classificate come soggetti essenziali o importanti. Il CRA agisce a monte, garantendo che i prodotti utilizzati da tali soggetti abbiano un livello minimo di sicurezza. Le due norme si completano: un soggetto NIS2 che utilizza prodotti conformi al CRA avrà un vantaggio significativo nel dimostrare l’adeguatezza delle proprie misure tecniche.
Documentazione Tecnica e CE Marking
Prima di immettere un prodotto sul mercato, i fabbricanti devono completare la procedura di valutazione della conformità applicabile, compilare la documentazione tecnica, redigere una Dichiarazione UE di Conformità e apporre il marchio CE.
Per Plesk Obsidian come prodotto hosting, ho dovuto compilare:
- Valutazione dei rischi di cybersecurity per ogni modulo (web server, database, mail, DNS).
- Elenco completo dei controlli di sicurezza implementati.
- SBOM per ogni versione.
- Procedura di gestione delle vulnerabilità (questa).
- Periodo di supporto dichiarato (nel mio caso: 5 anni per versioni stable).
- Informazioni sulla configurazione sicura di default.
Alla fine, se il prodotto rientra in categoria “importante” o “critica”, richiede certificazione da parte di un organismo notificato (ente terzo). Se è “default” (la stragrande maggioranza), auto-certificazione interna.
Sanzioni: Il Costo dell’Inazione
Il fallimento nel rispettare i requisiti essenziali di cybersecurity del CRA può comportare sanzioni fino a 15 milioni di euro o il 2,5% del fatturato globale annuale (il maggiore). Violazioni di altri obblighi includono mancata designazione di rappresentante autorizzato, documentazione tecnica incompleta o marcatura CE impropria, con multa fino a 10 milioni di euro o 2% del fatturato. Fornire informazioni false, incomplete o fuorvianti ai regolatori comporta fino a 5 milioni di euro o 1% del fatturato.
Nel mio caso, con un’azienda di medie dimensioni, una multa del 2,5% del fatturato sarebbe catastrofica. Non è solo un costo: è un rischio reputazionale enorme. I clienti non comprano più da chi viola le norme europee.
Checklist Pratica: Cosa Fare Adesso (Maggio 2026)
Nel mio studio dei tempi, ho identificato cosa devo implementare mese per mese. Ecco la mia checklist operativa:
Q2 2026 (Ora – Giugno)
- Inventariare tutti i prodotti/servizi offerti: quali rientrano nel scope CRA?
- Classificare ogni prodotto: default, importante, o critico?
- Generare SBOM automatico per ogni componente (Plesk, nginx, PHP, database, moduli custom).
- Integrare uno scanner di vulnerabilità nella CI/CD (Trivy, Grype).
- Pubblicare security.txt su tutti i domini gestiti.
- Definire il team PSIRT interno con nomi e contatti.
- Preparare template di notifica per le tre tempistiche CRA (24h, 72h, 14 giorni).
Q3 2026 (Luglio – Settembre)
- Testare il processo di segnalazione su una vulnerabilità fittizia end-to-end.
- Impostare la Single Reporting Platform di ENISA e fare login di prova.
- Verificare che i tempi di risposta interni (24/72h) siano realistici per il mio team.
- Aggiornare la documentazione tecnica con i dettagli di conformità.
- Iniziare dialogo con enti notificati se il prodotto è “importante” o “critico”.
Q4 2026 – Q1 2027 (Ottobre 2026 – Marzo 2027)
- Completare assessment formale della conformità (valutazione dei rischi).
- Redigere la Dichiarazione UE di Conformità.
- Preparare il dossier tecnico completo per i regolatori.
- Se richiesto, sottoporre a certificazione da ente notificato.
- Apporre il marchio CE su tutti i materiali di prodotto/marketing.
Link Correlati sul Blog
Ho già affrontato aspetti correlati al CRA in articoli precedenti che potreste trovare utili:
- NIS2 Compliance Hosting Aprile 2026: Adeguare l’Infrastruttura ai Nuovi Obblighi Senza Aumentare i Costi – La NIS2 è il complemento organizzativo del CRA, focalizzata sugli operatori essenziali.
- Plesk Obsidian MCP 2.0 Advanced Security: Come Implementare Zero-Trust, API Key Crittografate e Scansione Vulnerabilità Automatizzata – Le fondamenta tecniche per automatizzare il vulnerability management.
- Come Audire Plugin WordPress secondo il VDP Mandatorio di Maggio 2026 – La vulnerability disclosure per il software WordPress che gira sul mio hosting.
FAQ – Cyber Resilience Act 2026
Il CRA mi obbliga a pubblicare il SBOM pubblicamente?
No. Il CRA esplicitamente afferma che “i fabbricanti non devono essere obbligati a rendere pubblico l’SBOM”. I legislatori dell’UE riconoscono che gli SBOM possono contenere informazioni sensibili (rivelando componenti proprietari o potenziali vulnerabilità) e non richiedono la pubblicazione aperta. L’SBOM deve essere fornito alle autorità di sorveglianza del mercato su richiesta.
Se ho una piccola azienda di hosting, devo comunque rispettare tutti gli obblighi?
Le microimprese e le piccole imprese possono non essere penalizzate per il mancato rispetto della scadenza di 24 ore per la segnalazione di vulnerabilità e incidenti gravi. Tuttavia, gli obblighi di base (SBOM, gestione delle vulnerabilità, segnalazione nei tempi ragionevoli) rimangono. La soglia di tolleranza è minore, non l’esenzione.
Qual è la differenza tra CRA e NIS2?
NIS2 dice alle organizzazioni come proteggersi. DORA dice alle istituzioni finanziarie come gestire la resilienza operativa. Il CRA riempie il gap: impone ai fabbricanti i requisiti per fare in modo che i prodotti usati da queste organizzazioni abbiano garanzie minime di sicurezza. Sono complementari: NIS2 è difesa, CRA è garanzia di supply chain.
Se distribuisco un prodotto aperto (open-source), sono tenuto al CRA?
L’UE sta sviluppando linee guida su come la legge influisce su chi mantiene un progetto open-source che monetizza. Se contribuisci semplicemente a open-source senza monetizzarlo, non sei direttamente impattato dal CRA. Potresti comunque sperimentare un impatto indiretto in termini di aspettative di sicurezza più elevate.
Quando esattamente devo essere pronto per la segnalazione dell’11 settembre 2026?
Il 10 settembre 2026 (23:59 UTC). Non dopo. Se non avete SBOMs e un processo di gestione automatizzato delle vulnerabilità in posto prima di settembre 2026, non potete conformarvi. In pratica, l’SBOM diventa un requisito di fatto almeno 15 mesi prima della scadenza ufficiale del dicembre 2027.
Conclusione: Il CRA Non è Una Scelta
Nella mia esperienza diretta, il Cyber Resilience Act rappresenta un cambio di paradigma: la sicurezza dei prodotti digitali passa da essere un benefit di marketing a essere una condizione di sopravvivenza di mercato. Per chi fornisce hosting, software, infrastrutture cloud in Europa, non è una domanda “se” conformarsi, ma “come” e “quanto velocemente”.
Adeguarsi al Cyber Resilience Act significa ripensare radicalmente il modo in cui un’azienda progetta, sviluppa e mantiene i propri prodotti. Il regolamento non si limita a imporre controlli a posteriori, ma esige un cambiamento culturale che parte dalle fondamenta, in cui i prodotti devono essere concepiti secondo i principi di secure-by-design e by-default, poiché la sicurezza non può più essere un’aggiunta finale ma deve essere intrinseca al progetto.
Ho iniziato la mia implementazione a maggio 2026, e ogni settimana che passa avvicina l’11 settembre. Se siete un provider di hosting, una software house, un produttore di IoT o di cloud service: non rimandare. I mesi che vi restano vanno spesi costruendo, testando e automatizzando, non studiarando specifiche.
Vi è mai capitato di dovervi adattare a una nuova normativa sulla sicurezza? Condividete la vostra esperienza nei commenti. Sono curioso di sapere come altri colleghi stanno affrontando il CRA.