Managing external identities to enable secure access for partners, customers, and other non-employees
Hello Kumar k,
Greetings! Thanks for raising this question in the Q&A forum
You have already done the right diagnostic work, and it confirms this is not a configuration problem on your side. The Forbidden / "Invitations are blocked for this directory due to suspicious activity" response is Microsoft's automated fraud and abuse detection placing a tenant-wide hold on outbound B2B guest invitations at the Entra B2B backend, not something enforced by your External collaboration settings, cross-tenant access settings, or Security Defaults. That is why disabling Security Defaults and reproducing the failure through three separate paths (Entra portal, SharePoint/OneDrive, and raw Graph) all returned the identical error. It also explains the misleading ReadResponseFailure / "Cannot access a disposed object" message you saw in the portal and SharePoint/OneDrive flows: that is the same backend rejection surfacing through a different code path with a less specific error handler, not a separate bug.
Since your configuration is already confirmed correct, there is nothing further to change in the tenant. The only remediation path is:
- Open a Microsoft Support request for this specific hold From the Azure portal or the Microsoft Entra admin center, open a new support request with:
- Category: Microsoft Entra ID
- Problem type: B2B Collaboration / Guest Invitations
- Problem subtype: Invitation blocked / suspicious activity
Attach the identifiers you already have You already have everything the support engineer needs to locate the block server-side, so include it directly in the case description rather than only in this thread:
- Tenant ID:
705299f7-804d-40a1-938c-55dbdc1a894a(domainrpavault9.onmicrosoft.com) - Graph request-id:
5580c1b6-a5b5-4c31-aade-519cefc0a59c - Client-request-id:
f4a029e6-8422-f554-9f95-d38043907fca
- Timestamp: 2026-07-26T14:16:06 UTC A brief note on business context, as you posted here, plus the fact that you reproduced this through three independent paths with Security Defaults off, since that preempts the first round of troubleshooting questions support usually asks
- New tenant is a relevant detail worth including You noted this is a new tenant with no prior invitation history. New tenants sending their first invitations, especially to consumer domains like gmail.com, can trigger this fraud heuristic more readily than established tenants. Mention this explicitly in the case, since it helps the reviewing team distinguish a false positive from genuine abuse patterns faster.
- Avoid further retries while the case is open Since you've confirmed the failure is consistent and not intermittent, further invitation attempts (via any of the three paths) won't succeed and could add noise to the abuse signal Microsoft's system is evaluating. Hold off until support responds, then retry once you get confirmation the block has been lifted.
If this answer helps you kindly accept the answer which will help others who have similar questions.
Best Regards,
Jerald Felix.