Disattivare NTLM: cosa significa il piano di Microsoft per i vostri dispositivi mobili

Lukas Schönbächler · Giugno 2026 · 8 min di lettura

Ecco perché Microsoft lo fa, cosa fanno davvero i due successori, perché il mobile resta escluso e come colmare il divario.

Perché Microsoft elimina finalmente NTLM

A marzo 2025 Microsoft ha corretto CVE-2025-24054, una vulnerabilità di divulgazione dell’hash NTLM. Per sottrarre le credenziali bastava che un utente facesse clic con il tasto destro su un file .library-ms malevolo, e in pochi giorni Check Point ha documentato attacchi attivi contro enti governativi in Polonia e Romania. Ad aprile 2026 Cymulate aveva pubblicato un bypass (CVE-2025-50154); a giugno 2026 un secondo (CVE-2025-59214). Corretto due volte, ancora sfruttabile, senza alcuna interazione dell’utente.

È questa catena il motivo per cui Microsoft ha smesso di tappare le falle NTLM una alla volta. A gennaio 2026 ha pubblicato il piano per disattivare NTLM per impostazione predefinita su Windows, con il protocollo destinato a essere infine rimosso del tutto dal sistema operativo.

Come avviene la rimozione

La transizione si svolge in tre fasi.

• Fase 1, ora: auditing NTLM avanzato su Windows Server 2025 e Windows 11 24H2. I nuovi ID evento (4020 sui client, 4022 sui server, 4032 sui domain controller) mostrano finalmente perché è stato scelto NTLM e quale versione è stata negoziata. È il presupposto per tutto il resto: non si può migrare ciò che non si vede.
• Fase 2, seconda metà del 2026: IAKerb e LocalKDC raggiungono la disponibilità generale. Separatamente, a ottobre 2026 il valore predefinito di BlockNTLMv1SSO passa da Audit a Enforce (KB5066470) e blocca il single sign-on tramite NTLMv1. NTLMv1, la vecchia variante basata su DES, è banale da violare ed è il primo a sparire; NTLMv2 segue il percorso più ampio della fase 3. Ottobre 2026 è la scadenza vincolante più vicina.
• Fase 3, prossimo Windows Server LTSC (previsto per il 2027): NTLM di rete disattivato per impostazione predefinita. Resta riattivabile tramite Criteri di gruppo, ma il fallback automatico scompare.

Figura 1: le tre fasi della rimozione di NTLM da parte di Microsoft. Ottobre 2026 è la prima data che richiede un intervento nella maggior parte degli ambienti.

Cosa fanno realmente IAKerb e LocalKDC

Kerberos ha sempre avuto un requisito strutturale: il client deve avere una linea di vista diretta verso un Key Distribution Center (KDC) sulla porta 88. Quando non ne raggiungeva nessuno, che si trattasse di una macchina remota, di una rete segmentata o di un computer in workgroup, Windows ripiegava silenziosamente su NTLM. IAKerb e LocalKDC eliminano i due motivi principali per cui quel fallback esisteva.

IAKerb consente di inoltrare tramite proxy lo stesso scambio Kerberos. Quando un client Windows 11 24H2 non riesce a raggiungere direttamente un domain controller, instrada il suo AS-REQ attraverso un server compatibile con IAKerb che invece può farlo, così il client completa una normale autenticazione Kerberos invece di ripiegare su NTLM. È implementato nel security support provider Negotiate e Kerberos all’interno di LSASS; on-premises richiede un Windows Server 2025 con il ruolo KDC Proxy sul percorso (i dispositivi aggiunti a Entra possono usare il proxy KDC di Azure). Per l’applicazione è Kerberos dall’inizio alla fine.

LocalKDC colloca una piccola autorità Kerberos sul dispositivo Windows stesso, così anche gli account locali, non aggiunti al dominio, si autenticano tramite Kerberos contro il SAM locale. Questo elimina l’annosa convinzione che l’autenticazione locale debba per forza significare NTLM.

Entrambi sono miglioramenti reali. Entrambi sono anche esclusivamente Windows.

Perché nulla di tutto ciò raggiunge il mobile

IAKerb e LocalKDC sono funzionalità dello stack di autenticazione di Windows. Cambiano il modo in cui Windows negozia l’autenticazione all’interno di LSASS e del modello SSP. Android e iOS non hanno né l’uno né l’altro. Non hanno mai preso parte a quella negoziazione.

Sul mobile, un browser o un’app si autentica a livello applicativo, direttamente verso l’endpoint, con il meccanismo offerto dal server. Per le risorse on-premises basate su Active Directory, quel meccanismo era molto spesso NTLM, proprio perché le piattaforme mobili non dispongono del macchinario Kerberos integrato come un PC Windows aggiunto al dominio. In pratica, NTLM era la via di integrazione che permetteva al mobile di funzionare con l’on-premises.

Quindi, quando NTLM viene bloccato lato server, le due piattaforme divergono completamente. Un client Windows 11 passa in modo trasparente a IAKerb o LocalKDC. Un dispositivo Android o iOS non ha nulla verso cui passare. Semplicemente fallisce: le app web interne restituiscono 401, le condivisioni SMB non si montano più, SharePoint on-premises entra in un ciclo di autenticazione che non si conclude mai.

Figura 2: IAKerb copre i client Windows che non riescono a raggiungere direttamente un DC. I dispositivi Android e iOS non hanno un equivalente nel sistema operativo. Senza un client Kerberos dedicato sul dispositivo, o falliscono quando NTLM viene bloccato oppure necessitano di una soluzione a livello applicativo.

La lezione dal lato Windows è che Kerberos è la destinazione. Per il mobile, niente nel piano di Microsoft vi ci porta. Questa capacità Kerberos dovete fornirla voi stessi, e dovreste avere la relativa strategia pronta prima che scattino le scadenze.

Portare Kerberos su Android e iOS

Su Windows, LSASS ottiene i ticket in modo trasparente. Sul mobile non esiste un client Kerberos a livello di sistema operativo, quindi la capacità deve provenire da un’applicazione che implementa il client Kerberos e PKINIT direttamente sul dispositivo.

PKINIT è la pre-autenticazione Kerberos basata su certificato. Un certificato utente, distribuito tramite il profilo SCEP o PKCS del vostro MDM, serve a ottenere un TGT Kerberos dal domain controller; il client sul dispositivo emette poi i ticket di servizio per browser, WebView gestite e applicazioni gestionali. NTLM non compare in alcun punto di questa catena. Sui dispositivi Android e iOS gestiti, Hypergate Authenticator è l’implementazione esatta di questo flusso, e lo stesso approccio è alla base delle nostre guide a un proxy Kerberos per Android Enterprise e al SSO su Android.

La conseguenza è ciò che conta: un dispositivo che si autentica in questo modo usa già Kerberos. Bloccare NTLM lato server non ha alcun effetto su di esso, perché non resta alcun fallback da rimuovere.

L’autenticazione basata su certificato è anche l’upgrade di sicurezza

Portare il mobile a PKINIT non riguarda solo il mantenere tutto funzionante. L’autenticazione basata su certificato è un passo avanti per la sicurezza. Il certificato è legato all’utente e al dispositivo, e non c’è alcun segreto condiviso né hash da inoltrare o riprodurre, ossia proprio la classe di attacchi che le CVE NTLM citate all’inizio di questo articolo sfruttano.

Non è terreno nuovo. Banche e altri ambienti ad alta sicurezza usano l’autenticazione basata su certificato da anni. La novità è che la rimozione di NTLM, unita alla Strong Certificate Mapping Enforcement di Microsoft, la sta rendendo lo standard ben oltre quei settori.

Un prerequisito da rispettare: il certificato PKINIT deve contenere il SID dell’utente AD nel Subject Alternative Name (tag:microsoft.com,2022-09-14:sid:<SID>). La Strong Certificate Mapping Enforcement, in modalità rigorosa da settembre 2025, rifiuta i certificati che non lo fanno. Se state configurando ora il Kerberos mobile, questo lavoro di mapping ricade sulla stessa configurazione MDM. Abbiamo descritto la configurazione SAN per ogni MDM in un articolo dedicato.

Individuate le vostre dipendenze NTLM mobili prima di bloccare

Il traffico NTLM mobile si vede dal lato server. L’evento 8003 (o 4022 su Windows Server 2025) sui vostri server applicativi registra le autenticazioni NTLM in ingresso, incluso l’account e il client di origine:

Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" |
    Where-Object { $_.Id -eq 8003 } |
    Select-Object TimeCreated,
        @{N='User';E={$_.Properties[0].Value}},
        @{N='Client';E={$_.Properties[2].Value}},
        @{N='Process';E={$_.Properties[3].Value}} |
    Sort-Object TimeCreated -Descending

Confrontate il campo Client con l’inventario del vostro MDM. (Nota VPN: dietro una VPN il client potrebbe apparire come il concentratore, quindi correlate per account utente.) Una volta migrato un dispositivo, vedrete l’evento 4768 (TGT Kerberos emesso) dove prima compariva 4776 (validazione NTLM). È così che confermate che non usa più NTLM.

A che punto vi lascia

Il piano di Microsoft copre bene Windows. Il versante mobile spetta a voi, e il lavoro è semplice una volta reso visibile il traffico: fare auditing con l’evento 8003, distribuire un certificato legato al SID e PKINIT tramite il vostro MDM, confermare con l’evento 4768, quindi limitare NTLM. Niente di tutto ciò richiede nuova infrastruttura; il vero vincolo è iniziare abbastanza presto per validare tutto prima della scadenza di ottobre 2026.

---