Il 20 agosto Microsoft ha pubblicato l'advisory per CVE-2026-69836, una vulnerabilità di deserializzazione di dati non attendibili (CWE-502) in Entra ID che consentiva a un attaccante non autenticato di eseguire codice da remoto. Punteggio CVSS 10.0, il massimo possibile. Nessuna autenticazione richiesta, nessuna interazione dell'utente.

Microsoft ha confermato che la falla è stata sfruttata in rete prima della correzione. Ha anche precisato che la mitigazione è già completa sulla propria infrastruttura e che i clienti non devono fare nulla: nessuna patch da installare, nessuna configurazione da cambiare, nessun KB. Testualmente: "lo scopo di questo CVE è fornire ulteriore trasparenza".

È una comunicazione che merita di essere letta due volte, perché il messaggio implicito è che il problema è chiuso. Dal punto di vista di chi difende un'organizzazione, non lo è affatto.

Perché una CVE su cui non si può agire è comunque un problema

Entra ID non è un prodotto qualunque. È il servizio di identità che autentica gli utenti verso Microsoft 365, Azure e migliaia di applicazioni SaaS di terze parti collegate via SSO. Chi esegue codice arbitrario dentro un servizio di identità non ha bisogno di rubare password: si trova a monte del meccanismo che decide chi è chi.

Microsoft ha classificato la falla come cloud service CVE, una categoria introdotta nel 2024 proprio per dare visibilità ai difetti dei servizi gestiti. La logica è ragionevole: se il fornitore corregge sulla propria infrastruttura, non c'è azione lato cliente. Ma la trasparenza dichiarata si ferma prima del punto che conta.

L'advisory, come hanno rilevato più analisti, non dice:

  • chi ha sfruttato la falla e con quali finalità;
  • quando e per quanto tempo gli attacchi sono avvenuti;
  • quanti tenant siano stati toccati, e quali;
  • cosa abbiano fatto gli attaccanti dopo aver ottenuto l'esecuzione di codice;
  • quali indicatori di compromissione un difensore possa cercare nei propri log.

Manca cioè tutto ciò che serve a un responsabile della sicurezza per rispondere alla domanda che gli farà il consiglio di amministrazione lunedì mattina: siamo stati colpiti?

Cosa significa per le aziende italiane

La risposta onesta, oggi, è: non possiamo saperlo, e non dipende da noi. Ed è esattamente questo il punto da portare al tavolo della direzione, non come allarmismo ma come dato di realtà sul modello di rischio che abbiamo adottato.

La maggior parte delle organizzazioni italiane di media dimensione ha spostato l'identità su Entra ID negli ultimi cinque anni. È stata, nella quasi totalità dei casi, la scelta giusta: l'MFA gestita, il conditional access e la dismissione dei domini Active Directory on-premise hanno alzato il livello di sicurezza medio molto più di qualunque altro investimento. Non c'è motivo di rimettere in discussione quella decisione sulla base di una singola CVE.

Ma la scelta ha una conseguenza strutturale che va guardata in faccia: la superficie di attacco più critica dell'azienda è ora gestita da un terzo, e la visibilità su quella superficie è quella che il terzo decide di concedere. Non è un difetto di Microsoft in particolare — vale identicamente per Google Workspace, Okta o qualunque IdP gestito. È il prezzo del modello.

Da consulente, la lezione operativa che traggo è duplice.

Primo: la due diligence sul fornitore cloud deve includere gli impegni di comunicazione, non solo gli SLA di uptime. Nei contratti che rivedo, la sezione sulla sicurezza specifica quasi sempre disponibilità e localizzazione dei dati, quasi mai entro quanto e con quale dettaglio il fornitore comunica un incidente che tocca il mio tenant. Per i soggetti NIS2 questo non è un dettaglio contrattuale opzionale: l'art. 24 del D.Lgs. 138/2024 chiede di gestire i rischi derivanti dai fornitori ICT, e la capacità del fornitore di darti informazioni utili durante un incidente è parte di quel rischio.

Secondo: i log di identità vanno esportati e conservati fuori dal servizio che li produce. Se l'unica copia dei tuoi sign-in log vive dentro Entra ID con la retention di default — 30 giorni per la maggior parte delle licenze, 7 giorni per i tier più bassi — una notizia come questa ti trova senza materiale su cui indagare. Portare i log in un SIEM, in uno storage esterno o anche solo in un Log Analytics workspace con retention estesa costa poco e cambia completamente la posizione in cui ti trovi il giorno in cui devi rispondere.

Il fronte normativo

Un aspetto delicato riguarda gli obblighi di notifica. In quanto responsabile del trattamento ai sensi dell'art. 28 GDPR, Microsoft è tenuta a informare i titolari — cioè le aziende clienti — di una violazione dei dati personali "senza ingiustificato ritardo". Un advisory pubblico che conferma lo sfruttamento ma non identifica i tenant coinvolti non equivale a una notifica ai sensi dell'art. 33, paragrafo 2.

Questo lascia i titolari italiani in una posizione scomoda: non hanno elementi per valutare se ci sia stata una violazione di dati personali nel proprio tenant, e quindi non hanno nemmeno l'innesco delle 72 ore verso il Garante. La posizione difendibile, in caso di verifica successiva, è documentare la valutazione fatta: registrare nel registro delle violazioni la conoscenza dell'advisory, l'analisi svolta sui propri log, le eventuali richieste inoltrate al fornitore e la conclusione raggiunta. Un registro che non contiene traccia di questa valutazione è più difficile da difendere di uno che documenta un'analisi conclusasi con "nessuna evidenza di impatto".

Per gli enti finanziari soggetti a DORA, l'evento rientra nel monitoraggio del rischio da fornitore terzo critico: Microsoft è, per moltissime entità, un fornitore ICT che supporta funzioni essenziali, e un incidente sulla sua piattaforma di identità va valutato nel processo di gestione del rischio anche in assenza di impatto diretto rilevato.

Cosa fare subito

  • Non cercare patch: non ce ne sono. La correzione è già applicata da Microsoft. Chi promette "l'aggiornamento per CVE-2026-69836" sta vendendo qualcosa.
  • Esporta e analizza i sign-in log e gli audit log di Entra ID relativi alle ultime settimane. Cerca autenticazioni riuscite da paesi o ASN inconsueti, accessi fuori orario per utenze amministrative, e in generale sessioni che non trovano corrispondenza in attività note.
  • Rivedi le assegnazioni dei ruoli privilegiati. Global Administrator, Privileged Role Administrator, Application Administrator: verifica che l'elenco corrisponda a quello atteso e che non siano comparse assegnazioni recenti non giustificate.
  • Controlla le registrazioni di applicazioni e i service principal creati o modificati di recente, con attenzione ai permessi applicativi concessi e ai nuovi segreti o certificati aggiunti a registrazioni esistenti. È il punto di persistenza preferito da chi compromette un ambiente di identità.
  • Verifica i metodi MFA registrati sugli account amministrativi: un metodo aggiunto che l'utente non riconosce è un indicatore forte.
  • Estendi la retention dei log di identità oltre il default, portandoli in un SIEM o in uno storage esterno. Se questa notizia ti ha trovato con 30 giorni di visibilità, la prossima ti troverà uguale.
  • Apri un ticket al supporto Microsoft chiedendo esplicitamente se il tuo tenant rientra fra quelli interessati. Anche se la risposta fosse negativa o generica, la richiesta documenta la diligenza del titolare.
  • Rivedi le clausole contrattuali sulla notifica degli incidenti con i fornitori cloud in fase di rinnovo, chiedendo tempi e livello di dettaglio espliciti.

In sintesi

CVE-2026-69836 è tecnicamente chiusa e operativamente aperta. Microsoft ha corretto la falla e ha scelto di renderla pubblica, il che è più di quanto facesse l'industria fino a pochi anni fa. Ma la trasparenza senza indicatori di compromissione lascia i clienti nella condizione di sapere che qualcosa è successo senza poter verificare se sia successo a loro.

Per le aziende italiane il senso pratico di questa vicenda non è "il cloud è insicuro", che sarebbe una conclusione sbagliata e inutile. È che la delega dell'identità a un fornitore va accompagnata da due contromisure che quasi nessuno ha implementato per intero: conservare i log fuori dal servizio che li genera, e negoziare la comunicazione degli incidenti come si negozia la disponibilità. Entrambe si fanno prima, non durante.