Microsoft Entra Token Protection: simplified device registration
Introduzione
Quando una policy di Conditional Access impone Microsoft Entra Token Protection, un utente che lavora da un dispositivo Windows non ancora registrato può vedersi interrompere l’accesso alle applicazioni aziendali. In precedenza il messaggio di errore rimandava a una procedura di registrazione separata. Ora è possibile completare la registrazione direttamente durante il sign-in, senza uscire dal flusso di autenticazione.
Il miglioramento è stato confermato come Generally Available nel riepilogo What’s new in Microsoft Entra del 12 ottobre 2026. La guida Microsoft per Windows, aggiornata il 21 settembre 2026, precisa che il nuovo comportamento richiede gli aggiornamenti Windows di settembre 2026. La documentazione non associa il requisito a una singola KB valida per tutte le versioni del sistema operativo.
Token Protection e il rischio del token replay
Partiamo dalle basi, il Token Protection è un controllo di sessione di Microsoft Entra Conditional Access che riduce il rischio di riutilizzo dei token di autenticazione sottratti. In un attacco di token replay, un aggressore prova a usare su un altro dispositivo un token ottenuto dalla sessione legittima dell’utente, senza dover necessariamente conoscere la sua password.
Sui dispositivi supportati, il Primary Refresh Token (PRT) rilasciato da Microsoft Entra viene associato crittograficamente al dispositivo. Quando un’applicazione richiede l’accesso a una risorsa protetta, Microsoft Entra verifica che la sessione utilizzi un protocollo con il binding richiesto. Il controllo interessa i flussi di autenticazione supportati: la sua efficacia dipende quindi anche dal client utilizzato e dal tipo di registrazione del dispositivo.
La protezione per le applicazioni native Windows era già disponibile in General Availability. L’aggiornamento descritto qui interviene sull’esperienza dell’utente quando manca la registrazione necessaria.
Cosa cambia durante la registrazione del dispositivo
Supponiamo che un dipendente avvii Outlook su un computer Windows idoneo che non risulta ancora registrato in Microsoft Entra ID. Se la risorsa richiesta è protetta da una policy che impone Token Protection, l’accesso deve soddisfare anche il requisito relativo al dispositivo.
Con il nuovo flusso, il sistema propone una schermata di registrazione all’interno del sign-in. L’utente può scegliere Register, completare i passaggi richiesti e riprendere l’autenticazione. L’esito dipende comunque dalle altre condizioni imposte dall’organizzazione e dalla compatibilità del client.
I dispositivi già registrati correttamente non dovrebbero mostrare differenze nell’esperienza di accesso. Per quelli che non hanno ricevuto l’aggiornamento Windows richiesto di settembre 2026, Microsoft documenta ancora il messaggio precedente, Register or enroll your device.
Registrazione Microsoft Entra ed enrollment in Microsoft Intune sono operazioni distinte. La nuova schermata non sostituisce Autopilot, non aggiunge automaticamente il dispositivo alla gestione MDM e non rende conforme un computer che non soddisfa una eventuale policy di compliance.
Prerequisiti e ambito di supporto
Token Protection richiede Microsoft Entra ID P1 oppure una sottoscrizione che includa tale licenza. Per creare o modificare la policy è necessario un ruolo amministrativo adeguato, ad esempio Conditional Access Administrator. Il nuovo prompt compare soltanto quando l’utente accede attraverso un’applicazione nativa compatibile, da un dispositivo idoneo e con la policy Token Protection effettivamente applicata.
La documentazione generale include i dispositivi Windows 10 e successivi Microsoft Entra joined, hybrid joined o registered, con alcune esclusioni per specifici metodi di registrazione. Sono inoltre supportati determinati scenari con Windows Server 2019 e versioni successive hybrid joined. Per la nuova esperienza inline occorrono gli aggiornamenti Windows indicati nella guida del 21 settembre.
Tra i client supportati figurano Outlook, Teams, OneDrive, Word, Excel, PowerPoint, Windows App e altri client Microsoft aggiornati. Le risorse che possono essere protette su Windows comprendono Exchange Online, SharePoint Online, Microsoft Teams, Azure Virtual Desktop e Windows 365. L’elenco delle applicazioni e delle versioni supportate va controllato prima del rollout, soprattutto in presenza di add-in, moduli PowerShell o client meno recenti.
La disponibilità GA per le applicazioni native Windows va distinta dalla preview relativa ad alcune applicazioni web che accedono ad Azure Resource Manager. Il nuovo flusso di registrazione illustrato qui riguarda le applicazioni native supportate.
Cosa controllare nelle policy di Conditional Access
Per verificare come viene applicato Token Protection, apri il Microsoft Entra admin center e raggiungi Entra ID > Conditional Access > Policies. Se devi creare una policy di prova, seleziona New policy e lavora inizialmente su un gruppo pilota, escludendo gli account di emergenza previsti dalla tua organizzazione.
Per una configurazione Windows, la guida Microsoft indica i seguenti elementi:
| Area | Impostazione da verificare |
|---|---|
| Users | Gruppo pilota dedicato; esclusione degli account di emergenza |
| Target resources | Risorse supportate selezionate singolarmente, ad esempio Office 365 Exchange Online e Office 365 SharePoint Online |
| Device platforms | Windows |
| Client apps | Solo Mobile apps and desktop clients |
| Session | Require token protection for sign-in sessions |
| Enable policy | Report-only durante l’analisi iniziale |
Personalmente sconsiglio, e anche Microsoft, di usare indiscriminatamente il gruppo di applicazioni Office 365 come target: alcune risorse incluse potrebbero non supportare il controllo. Anche la selezione dei browser nella condizione Client apps può provocare blocchi imprevisti, per esempio con applicazioni web che usano MSAL.js.
La modalità Report-only consente di analizzare quali accessi sarebbero interessati senza applicare il blocco previsto dalla policy. Dopo avere osservato per un periodo adeguato sia i sign-in interattivi sia quelli non interattivi, puoi decidere se abilitarla per gli utenti del gruppo pilota. Per un esempio del metodo di validazione di Conditional Access in un altro scenario, su Endpoint Ninja è disponibile la guida Configurare Conditional Access per Remote Help.
Come verificare l’esito nei Sign-in logs
Dal Microsoft Entra admin center apri Entra ID > Monitoring & health > Sign-in logs e seleziona un accesso effettuato da un utente pilota. Nella scheda Conditional Access, oppure Report-only quando applicabile, controlla l’esito del controllo di sessione. Nel riquadro Basic Info trovi il campo Token Protection – Sign In Session.
Il valore Bound indica che la richiesta ha utilizzato un protocollo con token associato al dispositivo; Unbound indica che il requisito non è stato soddisfatto per quella richiesta. Un accesso può generare più richieste: per valutarlo correttamente è utile esaminare anche quelle correlate, mediante il correlation ID.
| Codice | Indicazione fornita da Microsoft |
|---|---|
| 1002 | Mancano informazioni sullo stato Microsoft Entra del dispositivo |
| 1003 | Lo stato o il metodo di registrazione non soddisfa i requisiti di Token Protection |
| 1005 | La richiesta non è associata per una ragione non specificata |
| 1006 | Versione del sistema operativo non supportata |
| 1008 | Client non integrato con il broker di autenticazione, ad esempio Windows Account Manager (WAM) |
Durante il pilota conviene distinguere tre casi:
- dispositivo supportato che deve ancora registrarsi
- dispositivo aggiornato e già registrato
- client non compatibile
Il confronto tra il comportamento mostrato all’utente e i Sign-in logs permette di separare un problema di registrazione da uno di supporto applicativo.
Limitazioni e scenari da escludere
La registrazione inline non amplia l’elenco dei dispositivi supportati da Token Protection. La documentazione Microsoft segnala, tra gli altri, Autopilot self-deploying mode, dispositivi registrati tramite bulk enrollment, alcuni session host Azure Virtual Desktop Microsoft Entra joined, Cloud PC Windows 365 Microsoft Entra joined, Surface Hub e sistemi Microsoft Teams Rooms basati su Windows.
Azure Virtual Desktop e Windows 365 figurano tra le risorse che è possibile proteggere quando l’accesso avviene da un client supportato. Le esclusioni indicate da Microsoft riguardano invece alcune VM e modalità di registrazione dei dispositivi che avviano la sessione.
Microsoft documenta l’uso di device filters per escludere categorie di dispositivi incompatibili. Le regole devono essere costruite sulle proprietà effettive del proprio ambiente e testate prima di attivare la policy. Sono previste inoltre limitazioni per i client Office perpetui e per alcune applicazioni o estensioni che accedono a Exchange Online e SharePoint Online.
Prima dell’abilitazione in produzione, verifica client, metodi di registrazione e accessi non interattivi. La nuova schermata di registrazione non corregge un flusso non supportato: una policy applicata senza questi controlli può bloccare utenti e applicazioni legittimi.
Conclusioni
La possibilità di registrare un dispositivo Windows direttamente durante il sign-in elimina un passaggio che in precedenza poteva interrompere l’accesso alle applicazioni protette da Token Protection. È un miglioramento utile soprattutto dove convivono postazioni aziendali e dispositivi che devono ancora completare la registrazione in Microsoft Entra ID.
Per gli amministratori la verifica più immediata riguarda la distribuzione degli aggiornamenti Windows di settembre 2026 e l’effettiva comparsa del nuovo prompt sui client idonei. Se Token Protection non è ancora attivo, conviene partire da una policy in Report-only e dai Sign-in logs, controllando con attenzione le applicazioni e i dispositivi esclusi. La registrazione diventa più semplice per l’utente, mentre i requisiti del controllo di sicurezza rimangono quelli documentati da Microsoft.
