Il problema: MFA non è tutto uguale

Quando una Conditional Access policy richiede semplicemente “Require multifactor authentication”, accetta qualsiasi metodo registrato dall’utente: da un SMS OTP fino a una FIDO2 security key. Ma in scenari ad alto rischio — accesso a risorse privilegiate, ruoli amministrativi, dati regolamentati — non tutti i fattori offrono lo stesso livello di garanzia. SMS e voice call sono soggetti a SIM swapping e phishing in tempo reale; una passkey no. Le authentication strengths rispondono esattamente a questa esigenza: permettono di specificare quali combinazioni di metodi sono accettabili per soddisfare l’MFA in una data policy.

Authentication strengths come grant control

Un’authentication strength è un grant control in Conditional Access. Microsoft Entra ID ne fornisce tre built-in:

  • Multifactor authentication — qualsiasi combinazione valida (equivalente al vecchio “Require MFA”).
  • Passwordless MFA — esclude la password: Windows Hello for Business, passkey (FIDO2), Microsoft Authenticator (passwordless sign-in).
  • Phishing-resistant MFA — solo metodi resistenti al phishing: FIDO2 security key, Windows Hello for Business e certificate-based authentication (multi-factor).

Puoi anche creare una custom authentication strength selezionando manualmente i metodi ammessi (es. imporre passkey + certificate per un gruppo specifico).

Scenario tipico

Per gli amministratori (o per una policy scoped ai directory roles privilegiati) la scelta corretta è assegnare la strength Phishing-resistant MFA. Così un admin che ha registrato solo Authenticator con push non soddisfa la condizione e viene forzato a onboardare una passkey o Windows Hello: la policy stessa guida l’adozione dei metodi forti. Per gli utenti standard si può mantenere la strength MFA generica, alzando l’asticella solo dove il rischio lo giustifica.

Il buco della legacy authentication

Il rischio più subdolo è che tutto questo impianto MFA può essere completamente aggirato dalla legacy authentication. Protocolli come POP, IMAP, SMTP (e vecchi client MAPI/Exchange ActiveSync) usano basic authentication: inviano solo username e password, senza supportare il challenge interattivo dell’MFA. Un attaccante con credenziali valide, rubate via password spray, entra tramite IMAP ignorando ogni policy che richiede un secondo fattore.

La contromisura è una Conditional Access policy dedicata che blocca la legacy auth:

  • Conditions → Client apps: seleziona Exchange ActiveSync clients e Other clients (è la categoria che copre i protocolli basic auth legacy).
  • Grant → Block access.
  • Applica a tutti gli utenti (con eventuali exclusion mirate per account di servizio che non possono ancora migrare).

Questa deve essere una policy separata dalle policy MFA, non una condizione aggiunta: la separazione rende l’intento esplicito e l’audit più pulito.

Named locations per gli scenari sede-based

Le named locations definiscono range di IP o country/region e possono essere marcate come trusted. Si usano nella condizione Locations delle policy CA per differenziare il comportamento in base a dove avviene il sign-in:

  • Richiedere phishing-resistant MFA quando l’accesso arriva da fuori le sedi corporate, mantenendo un’esperienza più fluida (ma mai “no MFA”) dagli IP trusted.
  • Bloccare l’accesso da country non previste (impossible-travel, geo-blocking).

Attenzione a non confondere “trusted location” con “assenza di controlli”: la best practice è comunque richiedere MFA ovunque, usando la location per modulare la strength, non per creare zone franche.

Trappole tipiche d’esame

  • Scenario: devi bloccare POP/IMAP/SMTP ma temi di disconnettere caselle applicative in produzione. → Prima analizza i sign-in logs filtrando per Client app = legacy authentication clients per identificare chi e cosa usa basic auth; poi crea la policy di blocco (eventualmente in report-only) per evitare lockout involontari.
  • Scenario: gli admin devono usare solo metodi resistenti al phishing. → Assegna la built-in authentication strength “Phishing-resistant MFA” come grant control su una policy scoped ai ruoli privilegiati, non una generica “Require MFA”.
  • Scenario: serve MFA rafforzata solo per accessi da fuori sede. → Combina la policy con una named location trusted (IP corporate) nella condizione Locations e applica la strength più forte al traffico esterno.
  • Scenario: hai attivato una policy MFA robusta ma gli account vengono comunque compromessi via posta. → Manca la policy dedicata di blocco della legacy authentication: l’MFA da sola non copre i protocolli basic auth.
  • Trappola su Security Defaults: se il tenant usa i Security Defaults, la legacy auth è già bloccata ma non puoi definire authentication strengths granulari — per entrambe le esigenze devi passare alle Conditional Access policies (richiede Entra ID P1/P2).