Criterio di accesso condizionale non applicato: come diagnosticare e risolvere i problemi in Microsoft Entra

By Mirko Peters · 2026-04-23 · Updated 2026-07-28

Un criterio di accesso condizionale non applicato richiede uno scenario di business chiaro, confini di sicurezza e dati validati e una responsabilità definita. Parti dal risultato atteso, testa la configurazione e gli effetti del criterio con utenti rappresentativi, documenta le decisioni e il processo di supporto, poi rivedi l'approccio con regolarità, man mano che cambiano i requisiti e le funzi

Automatically translated with AI from the original post. Read the English original

Cover: Fix Microsoft Entra ID Conditional Access and Identity Debt

Criterio di accesso condizionale non applicato: checklist pratica

Definisci lo scenario, il responsabile e i criteri decisionali.
Valida autorizzazioni, criterio, sicurezza e impatto sugli utenti.
Testa con un pilota e documenta le decisioni di supporto e revisione.

Usa Microsoft Learn per le indicazioni aggiornate.

Ultima revisione: luglio 2026.

L'accesso condizionale è il pilastro della protezione delle identità in Microsoft Entra (in precedenza Azure AD). Ma quando nei log compaiono i temuti stati «NotApplied», significa che i controlli di accesso non stanno facendo il loro lavoro e la tua organizzazione potrebbe essere esposta agli utenti sbagliati. Il problema resta nascosto finché non emergono i buchi durante un audit di conformità, una risposta a un incidente o per colpa di utenti poco prudenti.

La parte difficile? Raramente c'è un solo motivo per cui un criterio di accesso condizionale non viene applicato. Potrebbe trattarsi di un'impostazione dimenticata, di una entità servizio che sfugge ai controlli o del solito proliferare di criteri che complica tutto. Quando l'accesso condizionale non funziona, la risoluzione dei problemi diventa rapidamente complicata. Per questo è fondamentale capire come Microsoft Entra valuta e salta i criteri. È così che colmi queste lacune invisibili, riduci i problemi per gli utenti e tranquillizzi il team di sicurezza.

Con questa guida otterrai un percorso chiaro per capire perché un criterio non è stato applicato, evitare le trappole più comuni e iniziare a creare criteri di accesso condizionale che fanno davvero ciò che intendi: né più, né meno.

Come funziona la valutazione dell'accesso condizionale in Azure e perché i criteri risultano «Not Applied»

L'accesso condizionale in Microsoft Entra può sembrare semplice, applica la regola e ottieni il risultato, ma sotto il cofano le cose si complicano in fretta. Prima ancora di pensare a come risolvere un problema «NotApplied», devi capire come Entra analizza ogni criterio nel momento in cui qualcuno tenta di accedere. Non tutti i criteri vengono attivati o ignorati solo in base a ciò che hai controllato nell'interfaccia di amministrazione.

Quando un criterio è contrassegnato come «NotApplied», significa che Entra ha valutato l'accesso rispetto al criterio, ma ha stabilito che la regola non si adattava alla situazione. Forse l'utente, il dispositivo, l'app o il contesto di accesso non rientravano nell'ambito del criterio, oppure un altro criterio con priorità più alta ha già prodotto il risultato richiesto.

Tutto dipende dall'ordine di valutazione e da come Entra decide quali criteri prevalgono quando si sovrappongono. Poi ci sono le esclusioni dei criteri, i flussi delle entità servizio, le particolarità delle posizioni denominate e i piccoli comportamenti anomali di alcuni servizi di Microsoft 365. Molti criteri vengono saltati, a volte per motivi non ovvi, e lo stato «NotApplied» è l'unico indizio che qualcosa non va.

Se non approfondisci questi motivi e non riconosci «NotApplied» per quello che è, rischi di lasciar passare falle di sicurezza o di causare problemi di accesso agli utenti legittimi. È qui che entrano in gioco i log di accesso, che ti aiutano a distinguere criteri applicati, saltati e ignorati e ti offrono un quadro reale di ciò che sta accadendo. Per approfondire l'accesso condizionale e il rischio, questo episodio del podcast sulla proliferazione dei criteri e sulla governance propone strategie collaudate per le organizzazioni di grandi dimensioni.

Come i log di accesso di Microsoft Entra aiutano a individuare le lacune nell'applicazione dei criteri

I log di accesso di Microsoft Entra sono il tuo principale strumento investigativo per fare chiarezza sui misteri dell'accesso condizionale. Ogni voce di log indica quali criteri sono stati valutati per un accesso e vedrai stati espliciti come «Applied», «NotApplied», «Failure» o «Success». «NotApplied» non significa che Entra abbia ignorato il criterio: significa che le condizioni non sono state soddisfatte oppure che un altro criterio ha avuto la precedenza.

Controlla nei log di accesso la scheda “Conditional Access”. Qui puoi incrociare il contesto di utente, dispositivo e applicazione per capire perché un criterio non è stato attivato. Presta attenzione ad artefatti come gli accessi delle entità servizio o i flussi solo app: spesso compaiono come “NotApplied” perché CA non elabora i token non interattivi. Saper leggere questi log è fondamentale per individuare le lacune e escludere errori di configurazione. Per approfondire i criteri di base e il monitoraggio dei problemi di fiducia, consulta questa guida sulle lacune di fiducia in Conditional Access.

Le configurazioni errate più comuni di Conditional Access che impediscono l'applicazione dei criteri

Diciamolo chiaramente: Conditional Access è uno di quegli strumenti in cui piccoli errori possono trasformarsi in grossi problemi di sicurezza. La causa più frequente dello stato “NotApplied”? La configurazione errata, semplice e pura. Un'esclusione posizionata male, una soglia di rischio troppo permissiva o protocolli legacy trascurati possono lasciare aperte porte che tutti credevano chiuse a chiave.

Le incongruenze di ambito e condizioni sono frequentissime, soprattutto con le impostazioni di posizione o la logica dei accessi rischiosi. Che si tratti di un utente in un luogo inatteso o di un'applicazione che usa un'autenticazione obsoleta, l'applicazione dei criteri cede in modi non ovvi in anticipo. Aggiungi le particolarità dei controlli di accesso, come confondere “require all” con “require any”, e capirai quanto sia facile che le regole previste sfuggano.

Inoltre, l'autenticazione legacy funziona come una via laterale che aggira Conditional Access e MFA: una falla che molte organizzazioni dimenticano, finché una verifica di conformità non porta la brutta notizia. Gli amministratori più esperti restano attenti ricontrollando il proprio lavoro e tenendo d'occhio le nuove falle man mano che Microsoft 365 cresce. Se vuoi vedere come una deriva sottile della configurazione possa modificare persino gli esiti di conformità di Microsoft stessa, questo podcast sulla deriva della conformità in Microsoft 365 è illuminante.

Insidie delle condizioni di posizione e di rischio nei criteri di Conditional Access

Posizioni denominate configurate male: Se le posizioni denominate hanno un intervallo IP errato, non includono gli indirizzi attendibili o elencano paesi incompleti, alcuni accessi possono eludere il criterio senza alcun avviso.
Livelli di rischio inappropriati: Se imposti soglie di rischio per utenti o accessi rischiosi troppo alte (o troppo basse), rischi reali possono passare inosservati oppure gli utenti legittimi possono essere bloccati per falsi allarmi.
Posizioni omesse o troppo ampie: Dimenticare di includere tutti gli intervalli IP richiesti, le app cloud necessarie o lasciare attendibili geografie obsolete porta a un'applicazione frammentaria.
Punti ciechi sullo stato del dispositivo: Non considerare la conformità del dispositivo o l'aggregazione ibrida con Microsoft Entra ID lascia fuori gli accessi da endpoint non gestiti.

Per evitare questi errori, verifiche costanti e una governance chiara, come spiegato in questa guida alla governance di Azure, fanno tutta la differenza.

Controlli di accesso e regole di concessione che fanno fallire Conditional Access

Controlli di concessione in conflitto (“require all” vs. “require any”): Impostare i criteri in modo da richiedere tutti i controlli di concessione, come MFA più dispositivo conforme più app approvata, crea una situazione in cui un solo requisito non soddisfatto causa uno stato “NotApplied” o un rifiuto non voluto.
Logica di blocco dell'accesso poco chiara: Attivare accidentalmente sia i controlli di “concessione” sia quelli di “blocco” in un criterio può annullarli a vicenda, con un'applicazione imprevedibile (o uno stato “NotApplied” se le condizioni di blocco non vengono attivate).
Gruppi di utenti sovrapposti o esclusi: Includere gruppi ampi in un criterio ad alta priorità può sovrascrivere quelli più mirati, facendoli apparire come “NotApplied” perché le loro condizioni non hanno mai la possibilità di attivarsi.
Destinazione errata delle app cloud: Applicare i criteri alle app cloud sbagliate, oppure dimenticarne una fondamentale, significa che le restrizioni previste semplicemente non si attivano.

Autenticazione legacy e aggiramenti di MFA che lasciano lacune

Protocolli legacy: Protocolli datati come POP, IMAP e SMTP aggirano Conditional Access e MFA, eludendo le difese tramite Exchange Online e altri endpoint classici.
App registrate non gestite: Le app registrate prima che Accesso condizionale fosse applicato (o che usano il flusso delle credenziali client) non sono soggette ai controlli dei criteri moderni, e permettono ad attaccanti o utenti inconsapevoli di accedere alle risorse senza alcuna verifica.
Esclusioni MFA per gli account di servizio: Le esclusioni generalizzate per sistemi legacy o per le caselle di posta condivise disattivano le protezioni principali, creando punti ciechi che gli attaccanti sfruttano volentieri.
Falle tra app: un'integrazione errata tra app client può far saltare le richieste MFA anche dove ti aspetti che siano attive. Per approfondire come chiudere queste lacune di Zero Trust, consulta questa guida su Zero Trust in Microsoft 365/Dynamics 365.

Risoluzione dei problemi di Accesso condizionale tra app di Microsoft 365, B2B e piattaforme dei dispositivi

L'applicazione dell'Accesso condizionale è valida solo quanto il suo anello più debole. Microsoft 365 ha le proprie peculiarità nei servizi, gli accessi degli ospiti B2B e dei partner si comportano in modo diverso, e l'applicazione dei criteri ai dispositivi non sempre è quella che ti aspetti. Queste sfumature possono mettere in difficoltà anche criteri ben progettati e lasciare tracce «NotApplied».

Gli account ospite, soprattutto quelli dimenticati dopo un progetto con un partner, ne sono un esempio tipico. I loro confini di attendibilità e il loro ciclo di vita non sono come quelli degli utenti interni, quindi i criteri possono non intercettarli oppure attivarsi in modo incostante. I comportamenti specifici dei servizi di Microsoft 365, come Exchange Online o SharePoint, aggiungono un ulteriore livello di complessità, dalle autorizzazioni delle app ai timeout di sessione.

Poi c'è il lato dei dispositivi: il modo in cui l'endpoint di un utente viene aggiunto, registrato o gestito (pensa a Microsoft Entra ID ibrido, alla conformità di Intune, alle piattaforme dei dispositivi mobili) determina quali criteri si applicheranno e quali verranno saltati. Se vuoi capire fino in fondo l'applicazione dell'Accesso condizionale in ambienti diversi, crea una checklist specifica per ciascun ambiente che ti permetta di individuare in tempo reale le lacune, prima che ti costino una chiamata di supporto a tarda notte. Per approfondire i rischi di governance legati agli utenti ospite e alla governance di Teams, consulta strategie per il rischio degli account ospite e miglioramenti della governance di Teams per una visione più ampia dei rischi in evoluzione.

Peculiarità dei servizi di Microsoft 365 che influiscono sull'Accesso condizionale

Non tutti i carichi di lavoro di Microsoft 365 seguono le stesse regole per quanto riguarda l'Accesso condizionale. Servizi come Exchange Online, SharePoint e Teams hanno API, endpoint e logiche di gestione delle sessioni specifiche. Alcuni protocolli o l'accesso tramite app mobili non sempre rispettano le impostazioni più recenti dell'Accesso condizionale, soprattutto quando sono coinvolti endpoint legacy o app con consenso OAuth.

Un criterio può risultare «NotApplied» perché l'app usa metodi di autenticazione diversi, come Exchange Online PowerShell o SharePoint Online tramite il flusso legacy. Questo può aprire catene di attacco basate su phishing del consenso o furto di token, e rende necessaria una bonifica mirata per ciascun carico di lavoro. Per approfondire questi vettori di attacco a livello di servizio e la relativa protezione, consulta la bonifica delle catene di attacco di Microsoft 365.

Accesso condizionale per la collaborazione B2B e gli utenti ospite

Confini di attendibilità B2B: le organizzazioni di origine degli utenti ospite possono avere proprie regole di sicurezza, e il tuo Accesso condizionale non sempre prevale su di esse, quindi l'attivazione dei criteri può essere irregolare.
Flusso di invito e flusso di accesso: l'Accesso condizionale si applica al momento dell'accesso, non dell'invito. Se un ospite non accede mai, i tuoi criteri non verranno mai eseguiti.
Monitoraggio e avvisi: tieni sotto controllo le anomalie negli accessi degli ospiti configurando avvisi e consultando i log di Microsoft Entra. Così la condivisione esterna o gli accessi ospite rimasti attivi non diventano un rischio di conformità.
Revisione e scadenza: le revisioni periodiche degli accessi e gli inviti con durata limitata aiutano a mantenere l'ambiente ordinato e a ridurre la superficie di attacco. Per risultati migliori, organizza processi di audit continui con una copertura più ampia, come descritto in questa guida pratica sui controlli della condivisione esterna.

Sfide di conformità di Windows e dei dispositivi nell'Accesso condizionale

Esclusioni per piattaforma del dispositivo: I criteri limitati a Windows, iOS o Android possono non applicarsi affatto agli utenti se il dispositivo non viene riconosciuto o non rientra nella conformità.
Problemi con Hybrid Azure AD Join: I dispositivi non aggregati correttamente (ibridi o di altro tipo) non superano i controlli dei dispositivi di Accesso condizionale, impedendo l'applicazione dei criteri.
Lacune nell'integrazione con Intune: I criteri di conformità basati su Intune possono richiedere del tempo per essere registrati, creando una finestra in cui l'applicazione dei criteri appare incoerente.
Dispositivi non conformi o non attestati: Gli accessi da dispositivi jailbreak, obsoleti o non gestiti di solito non attivano i criteri protetti per dispositivo. Ulteriori indicazioni sull'integrazione tra conformità e protezione dalle minacce sono disponibili in questa panoramica su Microsoft 365 Defender e Purview.

Come contenere la proliferazione e le sovrapposizioni dei criteri che rendono imprevedibile l'Accesso condizionale

Negli ambienti di grandi dimensioni è facile esagerare con i criteri di Accesso condizionale. Si vuole una copertura impeccabile, ma questo può facilmente portare a così tante regole sovrapposte o in conflitto che nessuno riesce a prevedere quali verranno applicate. Troppi criteri aumentano la complessità, creano lacune nascoste e rendono la risoluzione dei problemi molto più difficile.

La proliferazione dei criteri, quando gli amministratori con le migliori intenzioni aggiungono «ancora uno» sopra gli altri, genera punti ciechi nell'applicazione nascosti, soprattutto quando ci si basa su inclusioni di gruppo ed eccezioni oppure si dimentica di eliminare i criteri di test. Le dipendenze dai servizi peggiorano la situazione: una modifica a un'app cloud o una nuova integrazione può compromettere una catena di criteri che prima funzionava in modo affidabile.

La mossa giusta è effettuare audit periodici dei criteri e razionalizzarli. Concentratevi su criteri di base inclusivi e riducete al minimo le eccezioni a tempo. Assicuratevi che ogni criterio abbia uno scopo chiaro, un risultato documentato e sia affiancato da report utilizzabili, e non date mai per scontato che il vostro ambiente sia «impostato e dimenticato». Per approcci al monitoraggio delle lacune di fiducia e alla gestione dello Shadow IT nell'Accesso condizionale, consultate questo playbook sui problemi di fiducia di Accesso condizionale e la guida sulla bonifica dello Shadow IT.

Gestione delle dipendenze dai servizi e prevenzione della proliferazione dei criteri

Verificate i criteri attuali: Inventariate e documentate regolarmente tutti i criteri di Accesso condizionale attivi, prestando attenzione a sovrapposizioni inutili o regole obsolete.
Mappate i servizi interconnessi: Individuate le dipendenze dell'Accesso condizionale tra Azure, Microsoft 365 e app di terze parti per intercettare le lacune di applicazione introdotte dalle nuove integrazioni.
Consolidate e razionalizzate: Unite i criteri simili ed eliminate quelli vecchi o inutilizzati, concentrandovi su regole ampie e ben documentate con eccezioni mirate.
Valutate i rischi legati all'IA e all'automazione: Non dimenticate i processi in background: gli agenti IA e l'automazione richiedono controlli dedicati e circoscritti per bloccare i rischi dello Shadow IT, come spiegato qui: minacce dello Shadow IT legate agli agenti IA.

Test sicuro dell'impatto dei criteri con «Seleziona tutto» e report

Attivate prima la modalità di sola segnalazione: Prima della distribuzione, usate la modalità di sola segnalazione per simulare l'impatto del criterio senza bloccare gli utenti legittimi. Analizzate l'effetto con le dashboard di reporting integrate.
Usate con cautela le conseguenze «Seleziona tutto»: Applicate tutte le azioni di applicazione in un ambiente di test sicuro per individuare risultati imprevisti o esclusioni non pianificate prima della distribuzione completa.
Documentate utenti e app interessati: Tenete traccia di ogni utente, gruppo e app coinvolti dalle modifiche, in modo da poter comunicare con gli stakeholder e tornare indietro se le cose vanno male.
Raccogliete il feedback di utenti e sistema: Incoraggiate gli utenti a segnalare subito i problemi e controllate i log degli errori di sistema per individuare blocchi causati dai criteri.
Affidatevi ai log di audit per la risposta agli incidenti: Usate Microsoft Purview Audit e i log del tenant per monitorare l'attività degli utenti e verificare i risultati dei criteri. Per indicazioni sull'audit, consultate questo approfondimento su Purview Audit.

Cosa fare in caso di blocco o se un criterio di Accesso condizionale non viene applicato

Ogni amministratore di Accesso condizionale conosce questo incubo: distribuisci un nuovo criterio e all'improvviso tu, o l'intero team, resti fuori dal tenant, oppure il criterio su cui contavi per risolvere il problema non funziona affatto. Le chiamate di escalation si moltiplicano e ti rendi conto che ti serve una strategia di ripristino solida solo per mantenere operativo il business.

La buona notizia? Esiste un playbook per riottenere l'accesso in fretta senza peggiorare la situazione. Ti conviene avere pronti gli account di accesso di emergenza, avere già predisposte le tattiche di rollback ed esclusione e, se serve, far scalare il caso a Microsoft Support o al tuo team di sicurezza.

Ma non fermiamoci al ripristino. Se non affronti la causa principale, ti ritroverai di nuovo in questo pasticcio la prossima volta che modifichi un criterio. Per questo una revisione post-incidente, l'aggiornamento degli stakeholder, i test continui e la documentazione delle lezioni apprese sono importanti tanto quanto riattivare il servizio. Per capire perché una proprietà frammentata degli strumenti compromette la governance, dai un'occhiata a questo approfondimento sui fallimenti della governance.

Ripristino passo dopo passo quando l'Accesso condizionale non funziona

Usa un account di emergenza: conserva almeno un account di emergenza con diritti di amministratore globale ma senza criteri di Accesso condizionale applicati. Accedi con questo account per recuperare l'accesso in qualsiasi momento.
Applica criteri di esclusione temporanei: se sei bloccato, crea o attiva un criterio di esclusione per l'account o il gruppo interessato, così da recuperare l'accesso normale e correggere la causa del problema.
Escalation per l'override da parte dell'amministratore: se i passaggi di primo livello non funzionano, contatta Microsoft Support o il tuo team di sicurezza per un intervento diretto o per lo sblocco del tenant.
Annulla le modifiche recenti ai criteri: ripristina le regole di Accesso condizionale nuove o modificate di recente all'ultima configurazione funzionante nota, verificando nei log di accesso che il problema sia risolto.

Passi successivi e revisione efficace dei criteri dopo aver individuato criteri non applicati

Documenta le lezioni apprese: registra esattamente cosa è andato storto, cosa ha funzionato come correzione e dove servono in futuro controlli o audit.
Testa in modalità solo report: prima di riattivare un criterio, usa la modalità solo report di Entra per verificare che stai intercettando i problemi senza causare nuove interruzioni.
Raccogli e applica i feedback: chiedi un riscontro agli utenti interessati e consulta i log di sistema, usando queste informazioni per chiudere le lacune rimaste.
Comunica con gli stakeholder: aggiorna tutti i team coinvolti, la leadership IT, i partner esterni e gli utenti su incidente, risoluzione e piani di prevenzione a lungo termine.
Impegnati in una governance regolare: pianifica revisioni, reportistica e aggiornamenti continui dei tuoi criteri di Accesso condizionale, perché una buona governance, come ricorda questo podcast sull'illusione della governance, è una pratica continua e non un semplice esercizio da spuntare una volta per tutte.

🎧 Ti consigliamo anche di ascoltare

Identity Governance in Microsoft Entra
Scopri i controlli di accesso e del ciclo di vita.
Microsoft Purview – Simply Explained
Approfondisci il contesto di protezione e conformità.
Microsoft 365 Governance Operating Model
Comprendi la proprietà sostenibile e le decisioni.