Accesso Condizionale Informazioni di Sicurezza Windows Hello macOS Platform SSO: Cambio di Ambito (13 luglio 2026)

Accesso Condizionale Informazioni di Sicurezza Windows Hello macOS Platform SSO: cosa è cambiato

Accesso condizionale informazioni di sicurezza windows hello macos platform sso — è il termine tecnico che gli amministratori Microsoft Entra devono ora conoscere. Dal 13 luglio 2026, i criteri di Accesso condizionale che hanno come ambito l'azione utente Register security information regolano anche la registrazione delle credenziali di Windows Hello for Business (WHfB) e macOS Platform Single Sign-on (SSO), indipendentemente dal fatto che questo comportamento fosse voluto o meno al momento della definizione iniziale dell'ambito del criterio. Se il vostro tenant aveva definito l'ambito di quell'azione utente in modo ristretto — ad esempio coprendo solo l'esperienza combinata di registrazione MFA/SSPR — la registrazione WHfB e macOS Platform SSO è ora soggetta, senza che lo aveste previsto, agli stessi Grant controls. Se il vostro tenant escludeva deliberatamente questi flussi per mantenere un provisioning dei dispositivi privo di attrito, anche quell'esclusione non è più valida: questi flussi ora rientrano nell'ambito per impostazione predefinita.

Prima di questo cambiamento, la registrazione di Windows Hello for Business e macOS Platform SSO non valutava affatto i criteri di Accesso condizionale con ambito su Register security information — anche quando esisteva un criterio che aveva come target quell'azione utente, semplicemente non veniva consultato durante la registrazione WHfB/Platform SSO. Le indicazioni ufficiali di Microsoft sono esplicite su cosa è cambiato e cosa no:

Microsoft ha anche confermato la finestra di rollout e l'ambito dell'impatto nel post del Message Center MC1326253, «Conditional Access policies now apply to Windows Hello for Business and macOS Platform SSO registration»: il rollout è iniziato il 6 luglio 2026 ed è terminato il 13 luglio 2026, e i tenant privi di un criterio di Accesso condizionale con target su Register security information non riscontrano alcun cambiamento — l'applicazione predefinita dell'MFA per la registrazione delle credenziali passwordless resta invariata.

Come funziona l'applicazione

Il meccanismo in sé non è nuovo — è la stessa azione utente Register security information che da anni regola l'esperienza combinata di registrazione MFA/SSPR. Ciò che è nuovo è che il provisioning di Windows Hello for Business e la registrazione di macOS Platform SSO ora passano attraverso quella stessa valutazione di Accesso condizionale. In concreto, dopo l'applicazione, un utente che registra credenziali WHfB o macOS Platform SSO deve soddisfare i Grant controls richiesti dal criterio corrispondente — authentication strength, una posizione attendibile, un metodo MFA specifico o la conformità del dispositivo — prima che la registrazione venga completata.

Due dettagli delle indicazioni di Microsoft sono rilevanti per pianificare la vostra risposta:

• I metodi di autenticazione esterni sono attualmente incompatibili con authentication strength come grant control per questa azione utente — un divario di compatibilità che fa eco al ritiro dei Custom Controls per i metodi di autenticazione esterni già in corso in Entra. Se il vostro criterio abbina Register security information a un requisito di authentication strength e il vostro tenant si affida a metodi di autenticazione esterni, Microsoft raccomanda di usare invece il grant control Require multifactor authentication.
• Il Temporary Access Pass (TAP) soddisfa il requisito MFA dell'Accesso condizionale per la registrazione, ed è il modo in cui Microsoft prevede che gli amministratori facciano da apripista ai nuovi utenti verso WHfB/macOS Platform SSO senza incorrere nel problema dell'uovo e della gallina (un utente non può soddisfare un grant control MFA/authentication strength con una credenziale che non ha ancora registrato). Il TAP non funziona per gli utenti guest.

Chi viene colto impreparato

Si tratta di un cambio di ambito, non di un nuovo criterio da creare — proprio per questo è facile non accorgersene. Vale la pena verificare in modo specifico due scenari di errore:

1. Criterio ristretto, nuovo attrito. Un criterio con ambito su Register security information e Grant: require authentication strength (pensato per proteggere la registrazione MFA/SSPR) ora si applica anche a WHfB e macOS Platform SSO. Un nuovo assunto che registra un dispositivo Windows gestito da una rete attendibile può ritrovarsi bloccato a metà configurazione perché non può ancora soddisfare l'authentication strength richiesta dal criterio — esattamente il divario che il Temporary Access Pass esiste per colmare.
2. Esclusione deliberata, annullata silenziosamente. Se il vostro team aveva in precedenza tenuto deliberatamente il provisioning WHfB/macOS Platform SSO fuori dall'ambito dell'Accesso condizionale — ad esempio per non rallentare un deployment di dispositivi zero-touch — quell'esclusione non esiste più dal 13 luglio 2026. Il flusso di registrazione è ora applicato per impostazione predefinita; escluderlo di nuovo richiede una modifica esplicita.

Letture correlate: la nostra copertura del cambiamento nella registrazione MFA passwordless e la guida più ampia sulle lacune dell'Accesso condizionale trattano entrambe decisioni di ambito correlate che vale la pena rivedere insieme a questo rollout.

Rilevamento — Verificare l'esposizione del vostro tenant

GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=(createdDateTime ge 2026-07-06T00:00:00Z and createdDateTime le 2026-07-13T23:59:59Z) and conditionalAccessStatus eq 'failure'

Get-MgAuditLogSignIn -Filter "createdDateTime gt 2026-07-06T00:00:00Z" | Select-Object `
  @{Name="User";Expression={$_.UserDisplayName}}, `
  @{Name="ClientApp";Expression={$_.ClientAppUsed}}, `
  @{Name="CA Result";Expression={$_.ConditionalAccessStatus}}, `
  @{Name="FailureReason";Expression={$_.FailureReason}}, `
  @{Name="Device";Expression={$_.DeviceDetail.DeviceDisplayName}}

Correzione — I passi da compiere subito

1. Elencate ogni criterio con ambito su Register security information e annotatene i Grant controls. Questa è l'intera superficie di esposizione di questo cambiamento — nient'altro nel vostro set di criteri di Accesso condizionale è interessato.
2. Rieseguite ogni criterio in modalità report-only e rivedete i risultati di policy impact prima di assumere che il comportamento non sia cambiato il 13 luglio.
3. Escludete gli account di accesso di emergenza (break-glass) e gli account di servizio/service principal da qualsiasi criterio con target su questa azione utente, secondo la raccomandazione permanente di Microsoft — vedete la nostra copertura degli account break-glass per capire perché gli account di emergenza non esclusi sono un riscontro ricorrente.
4. Emettete un Temporary Access Pass per i nuovi assunti e il re-provisioning dei dispositivi, in modo che la registrazione WHfB/macOS Platform SSO non incappi nel problema dell'authentication strength dell'uovo e della gallina. Il TAP soddisfa il requisito MFA dell'Accesso condizionale per la registrazione — ma ricordate che non funziona per gli utenti guest.
5. Non abbinate i metodi di autenticazione esterni a un grant control Require authentication strength su questa azione utente; usate invece Require multifactor authentication, secondo l'avviso di compatibilità esplicito di Microsoft.
6. Aggiornate la documentazione dell'helpdesk riguardo alle nuove richieste di autenticazione che gli utenti potrebbero vedere a metà configurazione — questa era anche l'azione raccomandata dalla stessa Microsoft in MC1326253, ed è il modo più economico per ridurre i ticket di supporto dei nuovi assunti confusi. La nostra guida all'audit di Entra ID illustra dove si inseriscono le revisioni dell'ambito dell'Accesso condizionale in una revisione più ampia del tenant.

Come EtcSec rileva questo problema

I controlli Conditional Access di EtcSec segnalano esattamente le configurazioni errate che trasformano questo rollout da un non-evento a un'interruzione: CA_POLICY_REPORT_ONLY rileva i criteri lasciati in modalità report-only che gli amministratori credono in applicazione (quindi il cambiamento del 13 luglio è stato testato ma mai realmente attivato), CA_NO_BREAK_GLASS_EXCLUSION rileva gli account di accesso di emergenza non esclusi da un criterio Register-security-information — ora un rischio di lockout sulla registrazione, non solo sull'accesso — e CA_EXCESSIVE_EXCLUSIONS segnala i criteri le cui liste di esclusione sono cresciute al punto che l'inasprimento dell'ambito portato da questo rollout diventa di fatto irrilevante.