Microsoft 365 bloccato nel mondo: il rischio di dipendere da un solo fornitore

Un guasto all’infrastruttura di Microsoft ha interrotto dal tardo pomeriggio di giovedì 12 novembre una parte dei servizi usati ogni giorno da imprese, scuole e amministrazioni in tutto il mondo. I problemi sono partiti da Exchange Online, il sistema di posta alla base di Outlook, e si sono estesi a funzioni di Teams, Microsoft 365 Copilot, SharePoint e di alcuni strumenti per la sicurezza e la gestione dei dati. Venerdì 13 novembre il ripristino risultava ancora graduale: la capacità dei server rimaneva inferiore al normale.

Il blackout rende visibile il modo in cui un unico fornitore può diventare il punto di dipendenza di molti processi aziendali. Posta, calendario, collaborazione, identità digitali, applicazioni collegate e AI sono spesso progettati per funzionare insieme. Questa integrazione rende più semplice lavorare quando tutto funziona; quando viene meno un componente comune, la perdita di funzionalità attraversa reparti e organizzazioni differenti, perfino dove i singoli programmi continuano ad aprirsi.

Secondo i bollettini di Microsoft sullo stato dei servizi e gli avvisi EX1550543 e MO1550821, il problema ha interessato funzioni collegate a Exchange Online. La società ha individuato un processo dei server addetto a stabilire connessioni sicure che, sotto carico, diventava incapace di rispondere; ha quindi applicato una correzione a componenti di autenticazione e instradamento, riavviato infrastrutture e reintrodotto traffico per gradi. Nell’aggiornamento del 13 novembre alle 09:55 UTC (10:55 in Italia) indicava primi segnali di stabilizzazione, ma capacità ancora insufficiente.

Intorno a mezzogiorno, ora italiana, la società spiegava, secondo quanto riportato da NBC News, che il traffico veniva ripristinato per gradi, con miglioramenti nell’accesso alle caselle e nella consegna della posta rimasta in coda, ma che alcuni utenti potevano incontrare ancora problemi intermittenti. Per non perdere i messaggi in ritardo, Microsoft ha esteso a 48 ore il tempo massimo di attesa per il loro recapito, come riportato da CNN. La società afferma di non avere indicazioni di attività malevole e prevede di pubblicare un rapporto tecnico finale dopo il ripristino.

Il guasto nasce nella posta, ma si propaga alla macchina dell’ufficio digitale

L’elenco delle dipendenze diffuso da Microsoft spiega perché la cronaca sia andata rapidamente oltre Outlook. Quando un’applicazione chiede di leggere un calendario, creare un appuntamento o recuperare una casella tramite Microsoft Graph, l’interfaccia con cui le applicazioni accedono ai dati di Microsoft 365, utilizza servizi condivisi. Se uno di questi non risponde, si bloccano anche operazioni eseguite da applicazioni apparentemente diverse. Lo stesso vale per un assistente AI che deve trovare una mail, riassumere una conversazione o consultare documenti aziendali.

La portata del disservizio richiede precisione. Microsoft ha indicato che la messaggistica, le chiamate e gran parte delle riunioni di Teams hanno continuato a funzionare, mentre calendari, inviti e altre funzioni legate a Exchange potevano generare errori. L’accesso ai file già archiviati in SharePoint è rimasto disponibile, pur con problemi in alcune condivisioni e funzioni collegate. Gli avvisi hanno riguardato anche operazioni di Microsoft Defender e Purview, senza che questo consenta di parlare di uno spegnimento generalizzato delle protezioni.

La crisi ha coinvolto organizzazioni lontane tra loro. Secondo Associated Press, disagi alla posta si sono registrati nelle amministrazioni di Singapore e del Giappone e presso la Corte suprema delle Filippine; la statunitense Workhorse Group ha rinviato una conference call sui risultati trimestrali. In India, Air India ha deviato temporaneamente i propri servizi di posta per continuare a ricevere le richieste dei clienti, mentre IndiGo ha segnalato problemi all’assistenza via email; entrambe le compagnie hanno precisato che i voli non sono stati interessati. Sono esempi di impatti differenti sulla stessa infrastruttura: dal servizio al pubblico ai rapporti commerciali.

Dall’email all’intelligenza artificiale, la dipendenza si allarga

L’incidente colpisce un ecosistema che negli ultimi anni ha incorporato analisi, automazione e AI. Microsoft 365 Copilot può utilizzare contenuti aziendali, appuntamenti e documenti per rispondere alle richieste degli utenti. Quando le relative interfacce di accesso ai dati si interrompono, l’assistente perde proprio il contesto aziendale che ne giustifica l’adozione: può non caricare una conversazione o non recuperare le informazioni necessarie per svolgere un compito.

Un problema simile riguarda chi costruisce applicazioni sopra i servizi Microsoft. Durante il blackout, OpenAI e Anthropic hanno segnalato difficoltà nei collegamenti ai loro strumenti Microsoft 365. Per un’azienda che usa agenti AI per organizzare appuntamenti, classificare messaggi o aprire richieste di supporto, la continuità dell’automazione dipende anche dalla disponibilità delle API, le interfacce con cui un programma interroga un altro servizio, e delle autorizzazioni sottostanti. Il rischio si trasferisce quindi dal software impiegato dai dipendenti ai processi affidati alle macchine.

Qui si apre un problema per chi compra e integra tecnologia. Spostare l’interfaccia da un’applicazione a un’altra cambia poco se entrambi i prodotti chiedono dati allo stesso Exchange Online o si appoggiano a un identico servizio di identità. Le aziende devono capire quali componenti sono davvero indipendenti, invece di misurare la diversificazione dal numero di fornitori che compaiono nei contratti.

Mercato concentrato e clienti difficili da spostare: il dossier britannico

Il blackout coincide con un passaggio regolatorio rilevante. Il 13 novembre scade la consultazione con cui la Competition and Markets Authority britannica (CMA) propone di attribuire a Microsoft lo status di impresa con posizione strategica nel software aziendale. L’autorità deve ancora decidere: la conclusione dell’esame è prevista entro il 13 febbraio 2027. La procedura riguarda la concorrenza, non l’accertamento delle cause del blackout, ma intercetta le stesse dipendenze che oggi rendono difficili i piani alternativi delle imprese. Nel comunicato del 16 ottobre, del resto, l’autorità collega la libertà di scelta alla resilienza: per le amministrazioni e le organizzazioni critiche, la possibilità di scegliere, cambiare e combinare servizi digitali, soprattutto di intelligenza artificiale, senza dipendere troppo da un solo fornitore viene definita sempre più importante anche per la resilienza e l’autonomia strategica.

Secondo i dati diffusi dalla CMA il 16 ottobre 2026, i prodotti Microsoft per le aziende, considerati nel loro insieme, sono utilizzati da oltre un milione di imprese ed enti pubblici britannici e da circa 20 milioni di utenti mensili. Nel perimetro rientrano sistemi operativi, suite di produttività, strumenti di sicurezza, database e server: sono numeri di diffusione dell’ecosistema nel Regno Unito, non una stima degli utenti colpiti dal guasto.

L’autorità rileva ostacoli nel cambiare software e fornitori, l’effetto delle integrazioni fra i prodotti e il ruolo dei pacchetti commerciali. Fra i temi che potrebbe esaminare figurano la possibilità di combinare software e assistenti AI concorrenti con Microsoft 365, le condizioni di accesso all’ecosistema, le licenze e il modo in cui i prodotti per la sicurezza vengono proposti insieme. Sarah Cardell, amministratrice delegata della CMA, ha sintetizzato l’obiettivo: «Le organizzazioni dovrebbero poter scegliere i prodotti più adatti, cambiare fornitore quando vogliono e combinare servizi di fornitori diversi».

La stessa CMA ha concluso nel luglio 2025 una separata indagine sul mercato britannico dell’infrastruttura cloud, segnalando il potere di mercato di Microsoft e Amazon Web Services e le barriere tecniche e commerciali al cambio di provider. Software aziendale e infrastruttura cloud sono mercati distinti: l’incidente attuale riguarda soprattutto Microsoft 365, e le segnalazioni non provano un’interruzione generalizzata di Azure. Le due analisi si incontrano però sulla portabilità dei dati, sull’interoperabilità e sulla possibilità di ridurre le dipendenze.

Il costo del fermo va oltre i crediti previsti dai contratti

Il rischio viene spesso discusso attraverso le percentuali di disponibilità promesse nei contratti. Ma anche un’azienda che ricevesse un accredito per il mancato rispetto dei livelli di servizio avrebbe comunque dovuto gestire lavoratori senza posta, ordini sospesi, appuntamenti da riprogrammare e clienti in attesa. La documentazione Microsoft sugli accordi sul livello di servizio (Service Level Agreement) di Microsoft 365 spiega che, quando gli impegni di disponibilità non sono rispettati, il cliente può ottenere un credito pari a una percentuale del canone mensile del solo servizio interessato, richiesto dall’amministratore e soggetto all’approvazione di Microsoft; che cosa conti come interruzione dipende dalle definizioni previste per ciascun servizio. Un credito sul canone non ricostruisce la capacità di lavorare durante il fermo.

Per misurare l’esposizione, un’impresa deve individuare quali operazioni si interrompono se mancano mail e calendari: conferme d’ordine, approvazioni, comunicazioni con clienti, notifiche interne, escalation di incidenti e accesso a documenti. Il costo dipende dal settore, dal momento e dalle alternative disponibili. Una redazione che non riesce a coordinarsi e una fabbrica che perde comunicazioni con i fornitori hanno conseguenze diverse, anche se all’origine c’è lo stesso errore tecnico.

Nel settore finanziario europeo la questione è già trattata come rischio di vigilanza. Il regolamento europeo DORA (Digital Operational Resilience Act, regolamento UE 2022/2554), applicabile dal 17 gennaio 2025, chiede a banche, assicurazioni e altri operatori finanziari di gestire i rischi legati ai fornitori di tecnologie dell’informazione e della comunicazione, comprese dipendenze e concentrazione, e di assicurare la resilienza operativa. La direttiva NIS2 sulla sicurezza delle reti e dei sistemi informativi, recepita in Italia con il decreto legislativo 138 del 2024, richiede alle organizzazioni che rientrano nel suo perimetro misure di gestione del rischio, continuità e sicurezza della catena di fornitura. Affidare l’attività a un grande fornitore di servizi cloud non trasferisce interamente al fornitore la responsabilità di gestire il fermo.

Che cosa insegna il blackout sui piani di continuità

L’interruzione indica un criterio per valutare l’architettura IT: seguire la catena delle dipendenze, dal processo aziendale alle API e ai servizi che lo alimentano. Una seconda piattaforma di collaborazione serve poco se le comunicazioni d’emergenza dipendono dalla stessa posta bloccata. Lo stesso vale per le soluzioni di riserva interne all’ecosistema.

Le indicazioni di mitigazione per Microsoft 365 pubblicate da Microsoft suggeriscono, per esempio, di passare all’app Outlook per smartphone o alla versione web quando un guasto colpisce il protocollo usato dal programma per computer. Questa volta l’avviso EX1550543, riportato nel registro degli incidenti della University of Pennsylvania, elencava tra i metodi di connessione potenzialmente coinvolti l’accesso via browser, il protocollo del client per computer, quello usato da molti dispositivi mobili e le interfacce di programmazione: le strade alternative passavano dalla stessa infrastruttura. Le alternative interne a un ecosistema ne condividono i punti di rottura e vanno valutate come tali.

Per lo stesso motivo il ricorso a più fornitori di infrastruttura cloud, il cosiddetto multi-cloud, da solo non protegge da un guasto a un servizio software in abbonamento condiviso come Microsoft 365. Occorre verificare che le applicazioni siano progettate per continuare a funzionare senza quel componente, oppure che esista una procedura per lavorare mentre manca.

Cosa possono fare le aziende

Le indicazioni pratiche si possono ordinare per orizzonte di tempo: che cosa fare nei giorni successivi al guasto, che cosa preparare nei prossimi mesi, che cosa rivedere nei contratti e nei progetti di intelligenza artificiale. Valgono per Microsoft 365 come per qualunque suite integrata da cui dipendano posta, documenti e identità digitali.

1. Documentare l’impatto finché è recente. Conviene annotare quali processi si sono fermati, per quante ore, quali clienti e fornitori sono stati coinvolti e quali soluzioni di ripiego hanno funzionato. Il quadro serve a stimare l’esposizione reale, a sostenere un’eventuale richiesta di crediti e, per le organizzazioni soggette a DORA o NIS2, a valutare con i propri responsabili se l’interruzione rientri negli obblighi di segnalazione degli incidenti. Quando Microsoft pubblicherà il rapporto tecnico finale, il confronto tra la catena di guasti descritta e i propri processi indicherà quali dipendenze non erano state considerate.
2. Mappare le dipendenze per processo, non per applicazione. Per ogni attività critica, come ordini, fatturazione, assistenza ai clienti e gestione degli incidenti, va indicato quali servizi usa davvero: l’identità digitale con cui ci si autentica, la posta, il calendario, le interfacce con cui altri software leggono quei dati. Due applicazioni diverse che leggono dallo stesso Exchange Online costituiscono una sola dipendenza.
3. Preparare un canale di emergenza fuori dall’ecosistema. Le indicazioni di Microsoft citate sopra suggeriscono sistemi di allerta su più canali (email, telefonate e sms), catene di chiamata che attivino un sostituto se il reperibile non risponde, un servizio di riunioni a distanza di riserva offerto da un altro fornitore, telefoni che non dipendano dalla rete dati aziendale, i numeri di cellulare del personale chiave nella rubrica e, per avvisare clienti e fornitori, canali pubblici come i social network. La rubrica di emergenza e il piano di continuità vanno conservati anche fuori dall’ambiente Microsoft 365 dell’azienda: un piano archiviato solo sulla piattaforma che si è fermata può risultare irraggiungibile proprio quando serve.
4. Tenere copie locali dei documenti essenziali. Microsoft suggerisce di configurare la sincronizzazione di OneDrive in modo che i documenti critici restino disponibili anche sui computer, non solo nel cloud. Rientrano in questa categoria le procedure operative, i contratti in corso, i listini e i contatti di clienti e fornitori.
5. Stabilire tempi, dati minimi e responsabilità. Per i processi più esposti occorre fissare entro quanto tempo il servizio deve tornare disponibile, quali dati devono restare accessibili e dopo quante ore si passa a una procedura alternativa, per esempio ordini raccolti per telefono o approvazioni annotate in un registro temporaneo. La decisione di attivarla deve avere un responsabile e un sostituto, indicati in anticipo.
6. Provare il piano con un’esercitazione. Uno scenario concreto, come posta e calendari non disponibili per ventiquattro ore durante la chiusura di fine mese, mostra in poche ore quali passaggi funzionano e quali dipendenze erano sfuggite. Improvvisare un nuovo indirizzo o un nuovo sistema di comunicazione durante il blackout può fallire proprio per le dipendenze che non erano state mappate.
7. Rileggere i contratti alla luce del Data Act. Il credito previsto dai livelli di servizio compensa una parte del canone, non la continuità. Una leva più utile viene dal Data Act, il regolamento europeo sui dati (regolamento UE 2023/2854), applicabile dal 12 settembre 2025: impone ai fornitori di servizi cloud, compresi quelli che offrono software in abbonamento via internet, di rimuovere gli ostacoli al cambio di fornitore e di prevedere nei contratti clausole che lo consentano. Fino al 12 gennaio 2027 possono addebitare per il passaggio solo costi ridotti, legati direttamente alla migrazione; da quella data non potranno più farlo. È l’occasione per verificare le clausole di uscita e di esportazione dei dati anche senza l’intenzione di cambiare fornitore: un passaggio praticabile rafforza la posizione negoziale.
8. Censire agenti e automazioni di intelligenza artificiale. Per ogni assistente, agente o flusso automatico che legge posta, calendari o documenti attraverso Microsoft 365, compresi i connettori di strumenti di altri fornitori, va deciso come deve comportarsi quando le interfacce non rispondono: mettere in coda le operazioni, avvisare una persona, sospendersi senza produrre risultati parziali. Un’automazione che si interrompe senza segnalarlo è più difficile da gestire di una che si ferma in modo visibile. Ogni nuovo agente va aggiunto alla mappa delle dipendenze prima di entrare in produzione.

La resilienza fa parte dell’adozione dell’AI

Il blackout arriva mentre la trasformazione digitale concentra sempre più attività in suite integrate e l’intelligenza artificiale ne amplia le funzioni. La convenienza di un ecosistema unico resta elevata, soprattutto per organizzazioni che non possono gestire molti sistemi differenti, e nessuna delle indicazioni precedenti richiede di abbandonarlo. Il blackout invita però a confrontare quella convenienza con la perdita simultanea di più capacità operative quando si interrompe una dipendenza comune.

Il punto che questo incidente rende più evidente riguarda chi sta introducendo l’intelligenza artificiale in azienda. Quando la suite serviva soprattutto a scrivere, comunicare e archiviare, un guasto fermava le persone, che potevano ripiegare sul telefono o su procedure manuali. Con assistenti e agenti che leggono la posta, fissano appuntamenti e smistano richieste, il guasto ferma anche il lavoro affidato alle macchine, che non dispone di un ripiego se nessuno lo ha previsto. Ogni agente costruito sopra la suite ne eredita i punti di rottura. Per questo la resilienza non può essere trattata come un capitolo dell’IT da affrontare in un secondo momento: va decisa mentre si progetta l’adozione, insieme alla scelta di che cosa automatizzare. Le regole sulla concorrenza e sulla portabilità, a Londra come a Bruxelles, possono rendere più facile cambiare e combinare fornitori; che cosa debba continuare a funzionare quando un fornitore si ferma resta una decisione dell’impresa.