Microsoft elimina Basic Auth: sistemi ERP a rischio senza OAuth

C’è un momento in cui un’infrastruttura smette di essere soltanto “vecchia” e diventa un rischio operativo diretto. Non perché il software si rompa da un giorno all’altro, ma perché il mondo tutt’intorno sta cambiando: i fornitori eliminano protocolli insicuri, i servizi cloud alzano le difese, i sistemi di autenticazione evolvono e ciò che per anni ha continuato a funzionare per inerzia improvvisamente smette di essere compatibile con tutto il resto.

Vi raccontiamo il caso di un’azienda di notevoli dimensioni che utilizza ancora oggi un ERP (enterprise resource planning) del 2008, senza più supporto dal 2019, che dipende ancora da autenticazione di base (“Basic Auth”) e credenziali in chiaro per interagire con Microsoft Exchange tramite SMTP.

Nel momento in cui l’ecosistema Microsoft ha annunciato la stretta definitiva su Basic Auth per SMTP AUTH, il problema è emerso in tutta la sua gravità.

La parte più interessante, però, non è il dettaglio tecnico in sé. Il punto centrale è un altro: quando un’applicazione mission-critical non può essere aggiornata senza una riscrittura sostanziale, l’azienda non ha un problema di compatibilità, ma un problema di continuità operativa, di governance e di gestione del rischio. Il fatto è che nel software ERP in questione il supporto OAuth non può essere “aggiunto” facilmente perché i meccanismi di autenticazione sono distribuiti in tutto il codice.

Vi risparmiamo la reazione del management, che di fronte a un preventivo per aggiornare il software lo liquida semplicemente come troppo oneroso. Di fatto si pretende una soluzione economica a un problema che esiste proprio perché per anni non si è investito abbastanza.

Il malinteso più pericoloso: scambiare un requisito di sicurezza per un dettaglio tecnico

Molte imprese considerano cambiamenti come l’adozione di OAuth, uno standard aperto che permette di autorizzare l’accesso alle risorse senza condividere direttamente le credenziali, come semplici complicazioni imposte dai fornitori tecnologici.

In realtà, la dismissione di Basic Auth non è una scelta arbitraria, ma la conseguenza di una traiettoria ormai consolidata.

Microsoft ha già rimosso da Exchange Online la possibilità di usare autenticazione di base per numerosi protocolli e mantiene SMTP AUTH come eccezione storica in progressiva riduzione. Il vecchio piano prevedeva una dismissione graduale tra il 1° marzo e il 30 aprile 2026, ma a fine gennaio 2026 Microsoft ha aggiornato la roadmap: fino a dicembre 2026 il comportamento rimane invariato, mentre alla fine di dicembre 2026 Basic Auth per SMTP AUTH sarà disabilitata di default per i tenant esistenti, con OAuth come metodo supportato di riferimento.

Il dettaglio temporale è importante: la finestra si è allungata, ma il problema non è scomparso. Anzi, il rinvio rischia di produrre l’effetto peggiore: convincere aziende già in ritardo che sia ragionevole rimandare ancora.

Quando un sistema dipende da username e password trasmesse in modalità legacy per eseguire funzioni di business essenziali, non ci si trova davanti a una semplice incompatibilità futura; si è già dentro una condizione di fragilità strutturale.

Un ERP senza vendor è, di fatto, un sistema senza rete di sicurezza

Nel caso brevemente menzionato in apertura, il fornitore del gestionale non esiste più dal 2019: un elemento che, da solo, cambia completamente la natura del problema.

Finché un software ha un produttore attivo, esiste almeno in teoria una catena di responsabilità: roadmap, patch, supporto, compatibilità, escalation. Quando il vendor scompare, il software resta in piedi soltanto finché l’ambiente circostante continua a tollerarlo.

È qui che molte aziende commettono un errore di valutazione. Continuano a classificare il sistema come “in produzione” e quindi implicitamente “stabile”, quando in realtà è solo “non ancora collassato”. La stabilità non è assenza di incidenti nel passato; consiste invece nella capacità di assorbire i cambiamenti futuri senza interrompere i processi.

Un ERP abbandonato che dipende da metodi di autenticazione obsoleti non è stabile: è una sorta di “bomba a orologeria”.

Tanti amministratori raccontano di applicazioni a 16 o 32 bit, sistemi DOS, software industriali e strumenti verticali che continuano a sostenere processi reali anni dopo la fine del loro ciclo di vita.  Non 20 anni fa ma oggi, nel 2026. Il mondo aziendale è pieno di componenti apparentemente marginali che, in realtà, reggono intere funzioni operative.

Le scorciatoie esistono, ma raramente risolvono il problema vero

Quando un sistema non supporta OAuth, l’impresa comincia a cercare soluzioni intermedie. Gateway SMTP, relay interni, caselle di servizio, connettori, agenti esterni, middleware che “parlano moderno” verso Microsoft e “parlano vecchio” verso l’ERP.

In alcuni casi soluzioni similari possono offrire un sollievo temporaneo. Microsoft stessa, nel percorso di uscita da Basic Auth, indica alternative come High Volume Email per flussi interni al tenant e Azure Communication Services Email per scenari più ampi. Ma il fatto che esistano alternative non significa che siano equivalenti funzionalmente o che possano assorbire senza problemi i casi d’uso di un gestionale progettato 20 anni fa.

Il punto critico è che i workaround tendono a spostare il rischio, non a eliminarlo. Si costruisce un ponte intorno al componente fragile, mantenendolo in vita ancora un po’. La scelta può essere sensata solo se è dichiaratamente temporanea, documentata e inserita in un piano di dismissione.

Diventa invece pericolosa quando viene presentata come soluzione definitiva, perché consolida l’illusione che il cuore del problema sia stato risolto.

Un middleware può tradurre protocolli. Non può trasformare un ERP abbandonato in una piattaforma sostenibile. Può ridurre l’urgenza. Non può ricostruire manutenibilità, supportabilità, auditabilità e conformità.

Come si presenta davvero il business case in azienda

Per convincere la direzione, spesso non serve una presentazione tecnica migliore.

Finché il progetto viene raccontato come “migrazione a OAuth”, sembrerà un’iniziativa IT costosa e poco visibile. Quando invece lo si definisce correttamente – eliminazione di un single point of failure applicativo, riduzione del rischio di blocco ordini, messa in sicurezza di credenziali legacy, ripristino di una filiera supportata e governabile – il perimetro cambia.

Il confronto non è più tra un preventivo che sembra oneroso. Il confronto reale diventa tra quel preventivo e il costo complessivo di un’interruzione di processo, di un incidente di sicurezza, di un intervento forzato in regime d’urgenza.

Nelle aziende mature, una soluzione per gestire il debito tecnico critico non è approvata perché “conviene tecnicamente”. È approvata perché il mancato trattamento espone il business a un rischio inaccettabile.

La lezione più utile: non aspettare che sia il vendor cloud a imporre la priorità

Le realtà d’impresa sanno di avere applicazioni legacy fragili, ma finché il sistema continua a produrre output, il problema resta astratto.

A renderlo improvvisamente concreto non è quasi mai l’applicazione in sé, ma un cambiamento esterno: una accantonamento da parte di Microsoft o di altri fornitori, un aggiornamento di Windows, un requisito di sicurezza, una modifica normativa, la fine di una libreria, la rotazione dei certificati, un protocollo che sparisce.

Quando ciò accade, il margine negoziale è già consumato. Si lavora con tempi stretti, costi più alti e scelte peggiori.

Per questo, il caso dell’ERP incapace di gestire OAuth non andrebbe letto come una storia su Microsoft che “complica la vita” o su consulenti che “sparano cifre esagerate”. È la dimostrazione concreta di che cosa accade quando un sistema essenziale è lasciato “fuori dal tempo” troppo a lungo.

La tecnologia, prima o poi, presenta il conto. E quando il business dipende da software senza futuro, quel conto arriva sempre nel momento peggiore.