Il Controllo Che Avete Già Introdotto
La maggior parte delle imprese lussemburghesi di una certa dimensione ha chiuso questo progetto anni fa. L'autenticazione a più fattori è stata attivata su Microsoft 365, l'assicuratore ha fatto la domanda e si è dichiarato soddisfatto, il revisore ha messo la spunta e l'identità è uscita silenziosamente dal registro dei rischi. Per un certo tempo era una posizione ragionevole.
Poi qualcuno in amministrazione ha ricevuto un messaggio su una verifica di conformità, ha effettuato l'accesso da una pagina identica al portale aziendale, ha approvato la richiesta sul telefono perché era davvero lui a collegarsi, e nulla è sembrato andare storto. Due settimane dopo un pagamento a fornitore finiva sul conto sbagliato, oppure una casella iniziava a inviare spear-phishing interno, e l'indagine scopriva che a quell'account si accedeva ininterrottamente da quel pomeriggio, senza una sola ulteriore richiesta di autenticazione.
L'MFA ha funzionato esattamente come previsto. È proprio questo il punto da capire.
Gli Attaccanti Hanno Smesso di Indovinare e Hanno Iniziato a Inoltrare
La tecnica si chiama phishing adversary-in-the-middle ed è banale più che esotica. La vittima arriva su una pagina controllata dall'attaccante ma, invece di registrare la password in un database, quella pagina si comporta da proxy trasparente verso il vero portale Microsoft. Ogni battitura viene inoltrata al servizio reale e ogni risposta rimandata indietro. L'utente vede la schermata di accesso autentica, perché è la schermata di accesso autentica. Digita la password, che viene trasmessa. Riceve una richiesta MFA, che è una richiesta vera. La approva sul telefono, o digita le sei cifre, e Microsoft — correttamente, avendo verificato tutto ciò che le era stato chiesto di verificare — emette un token di sessione.
L'attaccante si porta via quel token. Da quel momento il secondo fattore è irrilevante, perché il token attesta che l'autenticazione è già avvenuta. Posta, file, Teams e qualsiasi applicazione dietro lo stesso accesso unificato diventano disponibili senza ulteriori richieste, spesso finché il token resta valido e ben più a lungo se l'attaccante registra un proprio metodo di autenticazione mentre è all'interno.
Il team di threat intelligence di Microsoft ha pubblicato a maggio un'analisi dettagliata di una campagna di questo tipo. Fra il 14 e il 16 aprile 2026 ha raggiunto oltre 35.000 utenti in più di 13.000 organizzazioni distribuite in 26 paesi, usando come esca una finta «verifica del codice di condotta» interna. La catena passava per un allegato PDF, un dominio controllato dall'attaccante, un CAPTCHA Cloudflare presentato come convalida di sessione, una seconda verifica per selezione di immagini e infine un pulsante «Accedi con Microsoft» che inoltrava la sessione di autenticazione e catturava i token. I servizi professionali costituivano l'undici per cento dei bersagli, accanto a sanità, servizi finanziari e tecnologia.
Rileggete quella catena e notate che cosa non contiene. Nessun malware, nessun exploit, nessuna vulnerabilità nell'ambiente del cliente. I due CAPTCHA servono a escludere l'analisi automatizzata e, per inciso, a rassicurare l'essere umano. Si tratta di un'applicazione web ben costruita e di un pretesto plausibile, e c'è un mercato funzionante che affitta questa capacità a persone che non saprebbero costruirsela.
Perché la Notifica sul Telefono Non Vi Salva
Le approvazioni push e i codici monouso condividono un presupposto progettuale: che chi deve approvare sappia per quale sito sta approvando. Quell'informazione non viaggia con la richiesta. Un codice a sei cifre è valido tanto per il servizio reale quanto per un proxy che gli sta davanti, e una notifica chiede «stai effettuando l'accesso?» — domanda alla quale, in questo scenario, la risposta onesta è sì.
La corrispondenza numerica protegge da un attacco diverso: quello in cui un attaccante con una password rubata bombarda di richieste alle tre del mattino finché qualcuno non tocca «approva». Qui non serve, perché l'utente sta attivamente effettuando l'accesso e leggerà volentieri il numero dalla pagina dell'attaccante.
Non È un Argomento per Disattivare l'MFA
Vale la pena mantenere le proporzioni, perché il settore della sicurezza ha la spiacevole abitudine di dichiarare morto un controllo appena qualcuno trova un modo per aggirarlo. Il Digital Defense Report 2025 di Microsoft attribuisce il novantasette per cento degli attacchi all'identità al password spray — tentativi massivi e rudimentali contro nomi utente esposti — su una base di circa 38 milioni di rilevamenti di rischio sulle identità analizzati in una giornata media. L'MFA ordinaria blocca praticamente tutto quel volume, e un'organizzazione che ne è priva non ha un sofisticato problema di adversary-in-the-middle. Ne ha uno molto più semplice e molto più probabile.
Ciò che è cambiato è la fascia alta. L'IA ha reso il pretesto economico e la scrittura impeccabile: Microsoft riferisce di campagne di phishing assistite dall'IA che raggiungono tassi di clic fino al cinquantaquattro per cento, contro circa il dodici per cento delle campagne tradizionali. La grammatica e l'impaginazione non sono più il segnale rivelatore, il che significa che il consiglio che tutti diamo agli utenti da dieci anni — cercate gli errori — ha smesso silenziosamente di funzionare. Abbiamo descritto come questo si manifesta a livello locale negli schemi di attacco che osserviamo nella Grande Regione, e abbiamo esaminato che cosa dicono i dati sulla formazione di sensibilizzazione. In sintesi: la formazione alza il pavimento e qui non vi salverà. Questo problema va risolto nel livello di autenticazione.
La distinzione che conta: un fattore soggetto a phishing dimostra che qualcuno ha completato una verifica. Un fattore resistente al phishing dimostra che l'ha completata sul dominio reale. Tutto il resto è dettaglio.
Microsoft Ha Fissato la Scadenza al Posto Vostro
Se usate Microsoft 365, questa decisione vi è stata in larga parte sottratta, secondo un calendario pubblicato. A luglio Microsoft ha confermato che le passkey diventano il metodo di autenticazione predefinito in Entra ID, con queste date:
- 1° settembre 2026 — attivazione automatica delle passkey e inviti alla registrazione per gli utenti attualmente su SMS o voce.
- 18 settembre 2026 — pubblicazione di prezzi, condizioni commerciali ed elenchi degli operatori telefonici supportati per le organizzazioni che devono mantenere gli SMS.
- 30 ottobre 2026 — gli amministratori possono selezionare e configurare un operatore telefonico terzo.
- 1° febbraio 2027 — Microsoft cessa di recapitare direttamente l'autenticazione via SMS e voce, e la registrazione della passkey diventa obbligatoria. La formulazione di Microsoft è inequivocabile: «There will be no opt-out option».
Due precisazioni, perché entrambe vengono spesso fraintese. Primo, si tratta della dismissione del servizio SMS e voce fornito da Microsoft, non di un divieto degli SMS: le organizzazioni che ne hanno davvero bisogno possono ingaggiare un partner telefonico tramite il Microsoft Security Store e pagarlo direttamente. Secondo, queste date riguardano solo Entra ID nel cloud pubblico; gli altri ambienti cloud seguiranno un calendario distinto.
La conseguenza pratica è che non fare nulla è ormai una scelta con una data attaccata. Ai vostri utenti verrà chiesto di registrare una passkey nel giro di pochi giorni, che abbiate o meno definito la vostra strategia, informato il service desk o risolto il caso del capoturno di magazzino che non ha un telefono aziendale.
Una Migrazione Che Non Crolla alla Seconda Settimana
Le passkey e le chiavi di sicurezza FIDO2 funzionano perché la credenziale è legata crittograficamente al dominio che l'ha emessa. Davanti a una pagina sosia l'autenticatore non avverte l'utente: semplicemente rifiuta, perché il dominio non corrisponde. Non resta alcuna decisione che un essere umano possa sbagliare, ed è esattamente questo il punto.
Arrivarci in un'organizzazione da cinquanta a cinquecento persone non è difficile sul piano tecnico. Fallisce sulle cose che nessuno aveva previsto.
1. Scoprite che cosa usano davvero i vostri utenti oggi
Estraete i metodi di autenticazione registrati per ciascun utente prima di modificare qualsiasi cosa. Nella maggior parte dei tenant il risultato è scomodo: una lunga coda su SMS, una manciata di account privi di qualsiasi secondo fattore per via di un'esclusione storica, e account di servizio di cui nessuno sa indicare il titolare. Questo inventario è il piano di migrazione; tutto il resto ne discende.
2. Decidete fra passkey legate al dispositivo e sincronizzate prima di registrare chiunque
Le passkey sincronizzate risiedono in un gestore di credenziali e seguono l'utente fra i suoi dispositivi, il che rende adozione e ripristino molto più semplici. Le passkey legate al dispositivo — una chiave di sicurezza hardware, o Windows Hello for Business vincolato a una macchina specifica — offrono una garanzia più forte su dove si trovi fisicamente la credenziale. La maggior parte delle organizzazioni dovrebbe usare entrambe: chiavi hardware per gli amministratori e per chiunque possa movimentare denaro, passkey sincronizzate per tutti gli altri. Decidetelo per primo, perché tornare indietro significa registrare di nuovo tutti.
3. Partite dagli account che un attaccante vuole davvero
Amministratori globali, finanza e pagamenti, gli assistenti di direzione con accesso delegato alle caselle, le risorse umane e chiunque possa modificare le coordinate bancarie in un'anagrafica fornitori. Quell'elenco è abbastanza breve da completarsi in due settimane e copre la maggior parte degli scenari di perdita realistici.
4. Risolvete per primo il quindici per cento scomodo, non per ultimo
Postazioni condivise in produzione. Personale senza telefono aziendale e con comprensibili obiezioni all'uso del proprio. Consulenti esterni. Tecnici in mobilità su dispositivi in prestito. Ogni migrazione si arena qui, e si arena nel momento peggiore: dopo che la policy è stata applicata e le eccezioni diventano ticket urgenti. Mettete a budget le chiavi hardware per queste persone fin dall'inizio; costano poco rispetto a una settimana di service desk sotto assedio.
5. Sistemate il service desk prima di sistemare l'accesso
Quando la porta d'ingresso diventa inforzabile, l'attacco si sposta sulla persona che può reimpostarla. Una telefonata da un collega plausibile che ha «perso il telefono andando dal cliente» è ormai il percorso più breve dentro il vostro tenant, ed è già in uso. Mettete per iscritto quale prova d'identità richiede una reimpostazione, sceglietene una che un esterno non possa procurarsi — una richiamata al numero registrato nel fascicolo del personale, o la conferma del responsabile diretto di chi chiede — e rendetela non negoziabile, per quanto autorevole o agitato suoni chi chiama. Un service desk che ha provato questo scenario una volta si comporta in modo molto diverso da uno che ha soltanto letto una procedura; è esattamente ciò per cui esiste il nostro lavoro di formazione sulla sicurezza.
6. Imponetelo con l'accesso condizionale, non con l'incoraggiamento
Le campagne di registrazione vi portano adozione. Non vi portano garanzia, perché un utente che dispone sia di una passkey sia di un ripiego via SMS userà ciò che è più comodo, e altrettanto farà chi lo sta phishando. Applicate una policy di accesso condizionale che richieda un livello di autenticazione resistente al phishing, mirata prima al gruppo prioritario e poi estesa man mano che la copertura cresce. Finché una popolazione non è interamente registrata, riducete per essa la frequenza di accesso, così che un token rubato abbia una vita utile più breve.
7. Chiudete le porte di servizio
Protocolli di autenticazione legacy, password per applicazioni, service principal non gestiti e gli account di emergenza creati nel 2019 e mai più guardati. Un attaccante troverà l'unico percorso di autenticazione soggetto a phishing che avete lasciato aperto, e di solito è quello che precede chi oggi guida l'IT. Gli account di emergenza devono continuare a esistere: dategli chiavi hardware, conservatele come si deve e generate un allarme a ogni utilizzo.
Che Cosa Sorvegliare Mentre Siete a Metà Strada
La finestra di migrazione è la parte rischiosa, perché avrete una popolazione mista e molte modifiche di autenticazione legittime che generano rumore. Alcuni allarmi vanno predisposti prima di iniziare: la registrazione di un nuovo metodo di autenticazione su un account che ne aveva già uno, un accesso da una località insolita poco dopo un'MFA riuscita, nuove regole di inoltro o di occultamento nella casella, e concessioni di consenso OAuth ad applicazioni che nessuno ha approvato. Questi quattro coprono il copione abituale dopo il furto di un token, e fanno la differenza fra accorgersene in un'ora e accorgersene quando la fattura non arriva. Se fuori dall'orario d'ufficio nessuno guarda quella telemetria, è una lacuna che merita di essere colmata di per sé: è il cuore del nostro lavoro nelle operazioni di sicurezza.
L'Aspetto di Conformità, in Breve
Per i soggetti che rientrano nell'ambito della legge NIS2 lussemburghese, le misure di gestione del rischio dell'articolo 21 citano esplicitamente l'autenticazione a più fattori. Il testo oggi non distingue fra metodi soggetti a phishing e metodi resistenti al phishing, ma le aspettative delle autorità di vigilanza seguono il panorama delle minacce, e un'organizzazione in grado di dimostrare un'autenticazione resistente al phishing sui propri account privilegiati si trova in una posizione nettamente migliore di una che deve spiegare perché il furto di un token di sessione dovrebbe contare come sicurezza adeguata. Se state ancora definendo la vostra posizione, il nostro supporto alla conformità NIS2 parte proprio dalla questione dell'ambito.
Da Dove Cominciare
Se da questo articolo portate via una sola azione: estraete l'elenco di chi nella vostra organizzazione dipende ancora da un SMS o da una notifica push, e guardate quanti di quegli account possono approvare un pagamento o reimpostare una password. Quel numero è la vostra esposizione reale, e si ricava in un pomeriggio.
Se l'elenco è più lungo del previsto, o se i casi scomodi sono proprio quelli che continuate a rimandare, saremo lieti di percorrerlo con voi: inventario, una sequenza realistica e le due o tre policy di accesso condizionale che fanno gran parte del lavoro. Scriveteci e vi diremo con franchezza quanto è grande il lavoro prima che vi impegniate.
