Capita a chi sta facendo una cosa del tutto ordinaria: invitare un gruppo di collaboratori esterni, fornitori o consulenti nel proprio tenant Microsoft 365. I primi inviti partono, poi all’improvviso non ne parte più nessuno. Il messaggio di errore cambia a seconda di dove lo si incontra, ma il risultato è sempre lo stesso: il tenant ha smesso di accettare inviti verso utenti esterni, e nessuna impostazione sembra rimetterlo in moto.
Il comportamento non è documentato da Microsoft. Quello che segue è ricostruito da cinque segnalazioni pubbliche su Microsoft Q&A fra luglio e ottobre 2026, verificate una per una, più la documentazione ufficiale dove esiste.
Tre errori diversi, un solo fenomeno
La ragione per cui questo problema è difficile da riconoscere è che si presenta in modi che sembrano scollegati.
Chi invita dal portale Entra vede un generico User invitation failed accompagnato da Insufficient privileges to complete the operation. È un messaggio che indica un problema di permessi, e manda chiunque a controllare i ruoli, le impostazioni di collaborazione esterna e le deleghe. Può costare giorni.
Chi invita tramite Microsoft Graph riceve invece il messaggio vero:
Invitations are blocked for this directory due to suspicious activity.
Please contact Microsoft support for help.Questo dice esattamente cosa sta succedendo e indica la strada da percorrere. Lo stesso blocco, due descrizioni completamente diverse, a seconda del punto di ingresso.
La conseguenza pratica è semplice: se il portale vi dice che non avete i privilegi, provate la stessa operazione via Graph prima di mettere mano alla configurazione. Il messaggio che ottenete da lì è quello che conta, ed è anche quello che vale la pena allegare a un ticket.
La soglia: una decina di inviti
Tre delle cinque segnalazioni riportano il numero esatto di inviti andati a buon fine prima del blocco.
| Caso | Inviti riusciti | Si blocca al |
|---|---|---|
| Tenant appena creato | 9 | decimo |
| Tenant di quattro mesi | 11 | dodicesimo |
| Onboarding di trenta persone | 8 | nono |
La soglia non è un numero fisso, ma si colloca fra gli otto e gli undici inviti riusciti. La variazione potrebbe dipendere dall’età del tenant: nel caso riprodotto deliberatamente su un tenant appena creato il blocco è scattato prima, mentre il tenant con quattro mesi di vita ne ha fatti passare due in più. Con tre dati non si può parlare di regola, ma l’ordine di grandezza è coerente.
Il dettaglio che conta di più è un altro: il conteggio sembra cumulativo, non una misura di frequenza. In uno dei casi un team aveva costruito una procedura con tutte le cautele contro un rate limit, inviti sequenziali invece che concorrenti, controllo preventivo dei duplicati, nessun tentativo ripetuto dopo un errore, interruzione immediata al primo rifiuto. I tenant si bloccavano comunque. Se il contatore è cumulativo, rallentare non serve: il decimo invito arriva lo stesso, solo più tardi.
Cosa non è
Vale la pena elencare le strade già percorse da altri, perché sono tutte senza uscita.
Non è un problema di ruoli. In tutti i casi chi invitava era Global Administrator. In uno dei casi l’amministratore ha assegnato esplicitamente anche il ruolo Guest Inviter, senza alcun effetto.
Non sono le impostazioni di collaborazione esterna. Sono state verificate e lasciate completamente aperte, senza restrizioni di dominio, in più di una segnalazione.
Non è la configurazione del cross-tenant access. Anche qui, verificata e permissiva.
Non è un throttling temporaneo. Questo è il punto che cambia la pianificazione: in uno dei casi il blocco era attivo da tre mesi al momento della segnalazione, su un tenant dove l’amministratore aveva nel frattempo controllato ruoli e impostazioni. Un rate limit si rilascia da solo in ore, al massimo in giorni. Tre mesi indicano uno stato persistente applicato al tenant, che non decade.
Non si risolve riducendo la frequenza, per la ragione vista sopra.
Il caso particolare dei tenant per clienti
Una delle segnalazioni merita un discorso a parte perché riguarda un errore di impostazione architetturale, non il blocco in sé.
Un team usava una Azure Function con autenticazione applicativa per chiamare POST /invitations e onboardare clienti in tenant Microsoft Entra External ID. I tenant funzionavano per un po’ e poi si bloccavano, uno dopo l’altro.
Qui il problema di fondo è che si stava usando il meccanismo di un contesto diverso. La documentazione Microsoft distingue con chiarezza i due mondi:
- External ID in un external tenant è CIAM, cioè gestione delle identità dei clienti. Il percorso previsto per farli entrare è il self-service sign-up user flow, che crea account di tipo Member.
- La B2B collaboration, con gli inviti, è una funzione dei workforce tenant e serve a invitare partner e fornitori come Guest.
Chi fa onboarding continuo di clienti attraverso gli inviti amministrativi sta eseguendo un pattern da workforce dentro un tenant pensato per i clienti. E se la soglia è intorno alla decina di inviti per tenant, nessun ritmo è sostenibile a lungo: prima o poi si supera, su ogni tenant.
Cosa fare se vi succede
Primo, accertate che sia davvero questo. Se avete incontrato l’errore dal portale, ripetete l’invito via Graph con POST /v1.0/invitations. Se ottenete il messaggio sulla suspicious activity, avete la conferma e avete anche il testo da mettere nel ticket.
Secondo, non riconfigurate nulla. Ruoli, impostazioni di collaborazione esterna e cross-tenant access sono già stati esclusi da altri prima di voi. Cambiarli aggiunge solo variabili.
Terzo, aprite un ticket, ma chiedete la cosa giusta. La richiesta ovvia è la rimozione del blocco. Il problema è che, se dovete ancora invitare venti persone e la soglia sta intorno a dieci, lo sblocco da solo vi riporta al punto di partenza nel giro di poco. Vale la pena chiedere esplicitamente come completare l’onboarding previsto senza riattivare la restrizione, che è una domanda diversa e corrisponde al problema reale.
Allegate al ticket il payload completo dell’errore restituito da Graph, con il request-id, e dichiarate quanti inviti sono andati a buon fine prima del blocco: è l’informazione che permette di correlare l’evento lato Microsoft.
Come ridurre il rischio
Non esistono indicazioni ufficiali, quindi quelle che seguono sono deduzioni dai casi osservati.
Evitate l’onboarding massivo in un’unica sessione. Se dovete inserire molti utenti esterni, mettete in conto che oltre la decina potreste non proseguire, e pianificate di conseguenza invece di scoprirlo a metà.
Diffidate dei tenant appena creati. Il caso riprodotto deliberatamente mostra che un tenant nuovo si blocca prima, il che è coerente con un meccanismo che valuta anche la storia del tenant.
Se state costruendo un onboarding automatizzato per clienti, verificate prima quale sia il meccanismo giusto. Per un tenant External ID il self-service sign-up non accumula inviti, quindi il problema non si pone affatto.
Se gestite tenant di clienti, sappiate che il fenomeno esiste. Un cliente che vi segnala di non riuscire più a invitare un fornitore, con un messaggio che parla di privilegi insufficienti, probabilmente non ha un problema di permessi.
Il punto aperto
Nessuna delle cinque segnalazioni ha ricevuto una soluzione documentata. Non si sa quale sia la soglia esatta, su quale finestra temporale venga calcolata, se e come il blocco possa essere rimosso in modo stabile, né come evitarlo in un onboarding legittimo di dimensioni normali.
È una lacuna che tocca un’operazione quotidiana per qualunque azienda che lavori con collaboratori esterni, e che diventa un problema operativo serio per chi gestisce molti tenant.
Se nella vostra organizzazione avete incontrato questo blocco e avete ottenuto una risposta dal supporto Microsoft, è un’informazione che manca a tutti. Scriveteci: se emerge una procedura che funziona, aggiorneremo questo articolo.