Windows Hello for Business Fattore MFA Autonomo Entra Ottobre 2026: Il Secondo Requisito di Passkey Scompare

Windows Hello for Business Fattore MFA Autonomo Entra Ottobre 2026: cosa ha annunciato Microsoft

Windows Hello for Business fattore MFA autonomo Entra ottobre 2026 è il cambiamento che i team identity dovrebbero già pianificare. Nel post del Message Center MC1450134, "Microsoft Entra: Windows Hello for Business e macOS Platform SSO come fattori MFA autonomi" (pubblicato il 7 agosto 2026, aggiornato il 18 agosto 2026), Microsoft dichiara che Entra "riconoscerà Windows Hello for Business (WHfB) e macOS Platform Single Sign-On (PSSO) come fattori di autenticazione a più fattori (MFA) autonomi negli scenari di autenticazione supportati".

La finestra di rilascio è specifica. La disponibilità generale (General Availability) per i tenant Worldwide e GCC inizia "all'inizio di ottobre 2026 e si prevede si completi entro la fine di novembre 2026". Microsoft etichetta il post come planForChange con severità normale e afferma chiaramente che "non sono richieste modifiche di configurazione".

Quest'ultima frase merita attenzione. Nessuna azione dell'amministratore è richiesta, ma la postura di autenticazione di ogni tenant in cui gli utenti accedono con Windows Hello o un Mac cambia da sola — incluso quanti dei vostri account Entra segnala come MFA-capable, e da quali dispositivi un utente può ancora autenticarsi quando qualcosa va storto.

Cosa cambia realmente, e cosa già funzionava

Windows Hello for Business non viene aggiunto ai livelli di robustezza dell'autenticazione (authentication strengths) — c'era già. Il riferimento Microsoft sui livelli di robustezza dell'autenticazione elenca "Windows Hello for Business o credenziale di piattaforma" come soddisfacente tutti e tre i livelli integrati: MFA strength, Passwordless MFA strength e Phishing-resistant MFA strength.

Ciò che non ha funzionato in modo affidabile è il percorso di ri-autenticazione. La stessa pagina documenta il limite attuale con le parole di Microsoft:

Questo è il divario che MC1450134 colma. Secondo il post del Message Center, questi sono i comportamenti dopo il rilascio:

Due di queste righe meritano di essere sottolineate. La riga MFA-capable significa che il vostro numero di conformità si muove senza che un solo utente registri nulla di nuovo — se riportate la "percentuale di utenti MFA-capable" a un revisore o a un consiglio, ristabilite la baseline prima e dopo il rilascio per poter spiegare il salto. La riga del sollecito di registrazione significa che la rete di sicurezza che prima intercettava gli utenti a metodo unico scompare silenziosamente.

Microsoft documenta anche un problema noto sulla stessa pagina dei livelli di robustezza dell'autenticazione, che vale la pena rileggere sotto questa luce: quando una risorsa richiede sia un livello di robustezza dell'autenticazione sia una frequenza di accesso, gli utenti "possono soddisfare entrambi i requisiti in due momenti diversi", e l'esempio stesso di Microsoft è un utente che sblocca il proprio dispositivo Windows con Windows Hello for Business per soddisfare una frequenza di accesso di un'ora, mentre un accesso con passkey vecchio di 24 ore soddisfa il livello di robustezza.

La trappola: le credenziali legate al dispositivo non viaggiano

Microsoft segnala essa stessa il rischio, nella sezione "Azione richiesta e raccomandazioni" di MC1450134: "Poiché le credenziali WHfB e macOS PSSO sono legate al dispositivo (device-bound), gli utenti potrebbero non essere in grado di completare le sfide MFA da dispositivi in cui tali credenziali non sono disponibili."

Non è una cautela retorica. È la proprietà che definisce entrambe le credenziali:

• Windows Hello for Business è descritto da Microsoft come "principalmente un metodo di accesso legato al dispositivo, collegato alla device trust", con la credenziale "legata solo all'account aziendale o scolastico usato per registrare il dispositivo". Il suo tipo di passkey è elencato come legato al dispositivo (device-bound), non sincronizzato (passkey di Microsoft Entra su Windows).
• Platform Credential per macOS "effettua il provisioning di una chiave crittografica legata all'hardware, protetta dalla secure enclave", costruita sulla tecnologia Windows Hello for Business (Platform Credential per macOS).

La documentazione Microsoft sulla campagna di registrazione mostra già quanto sia stretto questo legame nella pratica. Il sollecito della passkey viene valutato per combinazione dispositivo-e-browser, e la tabella delle piattaforme pubblicata mostra che una credenziale Windows Hello for Business sopprime il sollecito solo su Windows, mentre una credenziale Mac Platform SSO lo sopprime solo su macOS. L'esempio proposto da Microsoft: "se un utente ha una credenziale Windows Hello for Business e accede su Windows con Chrome, il sollecito viene soppresso. Ma se lo stesso utente accede su un Mac con Chrome, riceve il sollecito perché quella credenziale non si applica a quella piattaforma." La stessa pagina osserva che gli utenti Linux non ricevono mai il sollecito, perché le passkey FIDO2 non sono disponibili su Linux.

Mettendo insieme i pezzi, l'esposizione diventa concreta. Dopo ottobre, un utente la cui unica credenziale MFA registrata è una credenziale Windows Hello for Business conta come MFA-capable, smette di ricevere solleciti ad aggiungere qualcosa di portatile, e resta comunque incapace di completare una sfida MFA da un telefono personale, un laptop in prestito, un Mac o una postazione Linux. Laptop rotto, dispositivo reimmaginato, giorno di viaggio, risposta a incidenti dalla macchina di qualcun altro — tutto ciò diventa una chiamata all'helpdesk anziché un prompt di secondo fattore. Questo rischio colpisce più duramente gli account che meno ci si può permettere di bloccare, ed è per questo che gli account di accesso di emergenza non dovrebbero mai dipendere da una credenziale legata a una sola macchina.

Questo si somma al ritiro dell'MFA via SMS e voce e al cambiamento di registrazione MFA senza password: i fallback portatili su cui molti tenant fanno ancora affidamento vengono rimossi proprio mentre il sistema smette di chiedere agli utenti di registrarne uno sostitutivo.

Rilevamento: trovate i vostri utenti solo con credenziali legate al dispositivo prima di ottobre

Tutti gli utenti registrati per un metodo senza password — FIDO2, Windows Hello for Business, o accesso senza password da telefono. Questo è l'anello esterno, non la risposta:

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?$filter=isPasswordlessCapable eq true

Tutti coloro che possiedono una passkey FIDO2 legata al dispositivo. Notate cosa questo non restituisce: passKeyDeviceBound è il metodo passkey legato al dispositivo, non Windows Hello for Business o macOS PSSO, quindi da solo non troverà gli utenti solo-WHfB di cui tratta questa sezione:

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?$filter=methodsRegistered/any(x:x eq 'passKeyDeviceBound')

Microsoft documenta methodsRegistered come filtrabile con any/eq ma non pubblica l'insieme completo dei valori che può contenere, quindi non indovinate una stringa di metodo dentro $filter. Estraete methodsRegistered per ogni utente e filtrate localmente — è quello che fa l'export qui sotto — oppure leggete la colonna Methods registered nel portale, dove Windows Hello for Business è elencato per nome.

Import-Module Microsoft.Graph.Reports

# Stabilire la baseline dei metodi registrati di ogni utente prima del rilascio.
# Richiede AuditLog.Read.All (Reports Reader, Security Reader, Security Administrator o Global Reader).
Get-MgReportAuthenticationMethodUserRegistrationDetail |
  Select-Object UserPrincipalName, IsAdmin, IsMfaCapable, IsPasswordlessCapable,
    @{Name = "Methods"; Expression = { $_.MethodsRegistered -join ";" }} |
  Export-Csv .\entra-mfa-baseline-pre-october-2026.csv -NoTypeInformation

Rimedio (Remediation): cosa fare prima dell'inizio del rilascio

1. Rendete obbligatorio un metodo portatile nell'onboarding. È la prima raccomandazione di Microsoft stessa in MC1450134: "Aggiornare le linee guida di onboarding per garantire che gli utenti registrino almeno un metodo MFA portatile." Una credenziale legata al dispositivo e nient'altro è un singolo punto di fallimento per utente.
2. Scegliete deliberatamente il metodo portatile. Microsoft suggerisce "una passkey sincronizzata o una passkey Microsoft Authenticator in aggiunta a WHfB o macOS PSSO". Notate il compromesso documentato da Microsoft: "Le passkey sincronizzate non supportano l'attestazione", quindi un profilo con Enforce attestation impostato su Yes le esclude alla registrazione — l'esempio stesso di Microsoft per gli account ad alto privilegio abbina l'attestazione obbligatoria alla sola modalità legata al dispositivo (abilitare le passkey (FIDO2)). Decidete quale di queste due proprietà vi serve realmente prima di pubblicare le linee guida.
3. Verificate i livelli di robustezza dell'autenticazione personalizzati. MC1450134 chiede di "rivedere i criteri Authentication Strength personalizzati per confermare che WHfB e macOS PSSO siano consentiti dove appropriato". I tre livelli integrati includono già "Windows Hello for Business o credenziale di piattaforma"; sono quelli personalizzati che avete scritto voi stessi a poter ora comportarsi diversamente da quanto ipotizzato.
4. Controllate le liste di autorizzazione AAGUID del vostro profilo passkey prima di dire agli utenti di registrarsi. Se usate restrizioni sulle chiavi, Microsoft documenta che l'AAGUID del Platform Credential macOS 7FD635B3-2EF9-4542-8D9D-164F2C771EFC deve essere nell'elenco consentito per le sfide WebAuthn. Per le passkey Windows Hello, gli AAGUID documentati sono 08987058-cadc-4b81-b6e1-30de50dcbe96 (TPM hardware), 9ddd1817-af5a-4672-a2b9-3e3dd95000a9 (VBS hardware) e 6028b017-b1d4-4c02-b4b3-afcdafc96bb2 (TPM software) — e Microsoft precisa che un profilo mirato a queste non può imporre l'attestazione.
5. Sistemate prima gli account break-glass. Gli account di accesso di emergenza devono essere raggiungibili da un dispositivo diverso da quello che si è guastato. Confermate che detengono una credenziale portatile e restano esclusi dai criteri che altrimenti li isolerebbero.
6. Ristabilite la baseline della metrica MFA-capable e informate chi la consuma. Il numero si muoverà perché la definizione è cambiata, non perché la copertura è migliorata. Confrontate il vostro CSV pre-rilascio con quello post-rilascio invece di riportare la nuova cifra come un progresso.
7. Testate in modalità solo report (report-only). Le modifiche ai criteri Conditional Access che fate in risposta a questo devono essere validate contro traffico reale prima dell'applicazione, la stessa disciplina che intercetta le lacune di copertura dei criteri di base che la maggior parte dei tenant si porta dietro.
8. Aggiornate la documentazione dell'helpdesk. L'ultima raccomandazione di MC1450134 è esplicita: gli utenti che hanno solo WHfB o macOS PSSO "non verranno più guidati automaticamente a registrare un metodo MFA aggiuntivo", quindi la guida deve arrivare da voi. Una revisione più ampia di dove questo si colloca nell'igiene del tenant è trattata nella nostra guida all'audit di Microsoft Entra ID.

Come EtcSec rileva questo

I controlli Conditional Access e accesso privilegiato di EtcSec puntano alle condizioni che trasformano questo rilascio da un non-evento a un blocco degli accessi. CA_NO_MFA_REQUIREMENT segnala i tenant senza alcun criterio che richieda realmente l'MFA, dove un conteggio MFA-capable mutevole crea una falsa fiducia. CA_NO_BREAK_GLASS_EXCLUSION individua gli account di accesso di emergenza senza un pattern di esclusione documentato — gli account più a rischio di rimanere isolati a causa di una credenziale solo legata al dispositivo. PA_GLOBAL_ADMIN_NOT_MFA fa emergere gli account privilegiati la cui applicazione dell'MFA non regge. CA_NO_SESSION_CONTROLS trova i tenant che si affidano a una frequenza di accesso che WHfB e macOS PSSO ora soddisferanno durante il 2FA, e CA_POLICY_REPORT_ONLY individua i criteri che avete testato per questo cambiamento ma mai effettivamente applicato.