Il 19 ottobre 2026 DigiCert, una delle più grandi autorità di certificazione al mondo, ha confermato un accesso non autorizzato a un sistema aziendale interno che custodiva dati archiviati dei clienti. Il caso è stato reso pubblico nei giorni scorsi e merita attenzione per due motivi: la causa non è un attacco sofisticato ma un errore di configurazione rimasto aperto per mesi, e i dati coinvolti includono, per una minoranza di account, documenti d'identità. Chi in Italia ha acquistato certificati TLS, di firma o di identità organizzativa tramite DigiCert (direttamente o attraverso un rivenditore) dovrebbe leggere con calma i dettagli.

Cosa è successo

Mettendo a confronto la ricostruzione di Cyber Security News e quella di GBHackers, entrambe basate sul rapporto di incidente pubblicato dall'azienda, la sequenza è questa:

  • 4 febbraio 2025: durante una migrazione dell'infrastruttura, un sistema interno viene spostato da un segmento di rete raggiungibile solo via VPN a un'altra availability zone, diventando accessibile da Internet. La modifica non passa da una revisione di sicurezza.
  • Il difetto: il sistema ereditava da una piattaforma di gestione degli account una funzione di auto-registrazione. Chiunque poteva creare un account; questi account non erano soggetti all'autenticazione a più fattori richiesta al personale e non avevano applicazioni assegnate, ma disponevano comunque di permessi di sola lettura sui dati archiviati.
  • 18 giugno 2026: il personale nota account che non appartengono a dipendenti. Una prima valutazione conclude, erroneamente, che senza applicazioni assegnate non possano leggere nulla. Un web application firewall blocca le nuove registrazioni dall'esterno.
  • 21 giugno 2026: una segnalazione del programma di ricerca sulla sicurezza gestito da DigiCert conferma il problema.
  • 27 giugno – 2 luglio 2026: finestra in cui avviene l'accesso non autorizzato ai dati. Il 2 luglio viene rilasciata una correzione ai controlli di autorizzazione.
  • 12 ottobre 2026: DigiCert sospetta per la prima volta che i dati archiviati siano stati letti; i log conservati consentono di ricostruire la finestra temporale. Il 19 ottobre arriva la conferma e il 20 ottobre il rapporto preliminare.

I dati interessati sono nomi, email aziendali, numeri di telefono e indirizzi aziendali per tutti i clienti coinvolti, mentre per una piccola parte degli account compaiono anche passaporti, patenti di guida, bollette o altri documenti con nome e indirizzo. Il numero di persone coinvolte non è stato reso noto: DigiCert sta ancora esaminando i documenti per individuare gli interessati e li avviserà al termine della verifica.

Punto importante per chi teme per la propria PKI: secondo l'azienda i servizi della CA, CertCentral e DigiCert ONE non sono stati compromessi, le credenziali dei clienti e i certificati emessi restano al sicuro e non risultano emissioni, modifiche di validazione o revoche collegate agli account non autorizzati. Di conseguenza non è richiesto sostituire i certificati attivi. Questo punto proviene dalle dichiarazioni del fornitore, non da una verifica indipendente, e va trattato come tale.

Cosa significa per le aziende italiane

Il primo ragionamento riguarda la catena del fornitore. Per un'azienda italiana un incidente di questo tipo non è "un problema americano": se qualcuno in organizzazione ha caricato un passaporto o una visura per la validazione di un certificato EV o di firma, quel documento sta in un archivio di terzi che il reparto IT potrebbe nemmeno ricordare. Il rischio concreto non è la presa di controllo del sito, ma l'uso dei dati per phishing mirato e furto d'identità: un attaccante che conosce nome, ruolo, telefono e indirizzo del referente tecnico di un'azienda, e magari ha una copia del suo documento, può costruire una frode del CEO o un falso rinnovo di certificato molto credibile.

Il secondo ragionamento è sul modo in cui l'incidente è nato. La "protezione" era la rete: finché il sistema stava dietro la VPN, la mancanza di controlli di autorizzazione non si vedeva. Spostarlo ha cancellato l'unica barriera. È un modello che molte PMI e amministrazioni italiane conoscono bene, con gestionali, pannelli interni e vecchi tool che "sono sicuri perché non sono esposti". Ogni migrazione, cloud-lift o cambio di rete dovrebbe prevedere una verifica di che cosa diventa raggiungibile e con quali controlli applicativi. La stessa DigiCert dichiara come lezione che gli strumenti interni richiedono controlli di autorizzazione espliciti, anche quando ci si fida delle restrizioni di rete.

Il terzo punto è il ritardo di rilevazione: tra la prima anomalia (18 giugno) e la conferma dell'accesso ai dati (19 ottobre) passano oltre quattro mesi. L'errore di valutazione iniziale, trattare il caso come un difetto di creazione account e non come potenziale accesso ai dati, è un classico: la classificazione dell'incidente decide quando scattano gli obblighi di notifica.

Contesto normativo

Se i dati coinvolti riguardano persone fisiche nell'Unione, la violazione è una violazione di dati personali ai sensi del GDPR. Per le aziende italiane clienti di DigiCert il tema pratico è questo:

  • Il fornitore agisce, per questi dati, in genere come titolare o responsabile del trattamento; l'obbligo di notifica al Garante entro 72 ore (art. 33 GDPR) decorre dal momento in cui il titolare ne viene a conoscenza. Se siete titolari e ricevete la comunicazione dal fornitore, quell'istante conta per voi.
  • Se l'incidente ha un impatto significativo sui servizi di un soggetto NIS2, vanno considerati i tempi di notifica al CSIRT Italia (preallarme entro 24 ore, notifica entro 72 ore). Una violazione di riservatezza in un fornitore non sempre configura un incidente significativo per voi, ma la valutazione va documentata.
  • NIS2 e, per il settore finanziario, DORA richiedono di governare il rischio di terza parte: registro dei fornitori critici, clausole di notifica degli incidenti e verifica di cosa consegnate a ciascun fornitore.

Non sono un'indicazione legale generale: l'obbligo effettivo dipende dal ruolo (titolare, responsabile) e dai dati realmente coinvolti, da valutare caso per caso con il DPO.

Cosa fare subito

  • Verificate se avete ricevuto la comunicazione di DigiCert (anche nella cartella spam e sulle caselle dei referenti tecnici) e inoltratela a DPO e responsabile della sicurezza.
  • Censite quali documenti e dati avete consegnato a DigiCert o al rivenditore (validazione EV/OV, firma del codice, S/MIME) e a nome di chi.
  • Non sostituite i certificati attivi solo per questo incidente, come indicato dal fornitore, ma monitorate eventuali comunicazioni successive o l'emissione non richiesta di certificati per i vostri domini (Certificate Transparency).
  • Avvisate i referenti coinvolti del rischio di phishing mirato e di tentativi di impersonificazione, anche telefonici, che citano DigiCert o rinnovi certificati.
  • Riguardate l'accesso al portale DigiCert: MFA attiva per tutti gli utenti, account dismessi rimossi, ruoli minimi.
  • Applicate la lezione internamente: elencate i sistemi "protetti solo dalla rete", verificate che abbiano autenticazione e autorizzazione applicative e inserite una revisione di sicurezza obbligatoria nei cambi di rete e nelle migrazioni.
  • Aggiornate il registro dei fornitori annotando la data della comunicazione e la valutazione fatta, utile come evidenza in caso di verifica.