A Microsoft Entra group belongs to one tenant. Adding a group from tenant A does not automatically give its members access to a SharePoint site in tenant B. The target tenant needs identities it can resolve, an accepted sharing model and permissions on the target site.
There is a second, narrower issue that often gets mixed into this problem: a Microsoft 365 group owner can be an owner without also being a member. Microsoft documents that this can prevent the owner finding group content in SharePoint search. Adding that owner as a member can fix that search case, but it does not make a group portable across tenants.
Diagnose the access path in order
1. Confirm the target tenant
Open the SharePoint site and Microsoft Entra admin centre for the tenant that owns it. Record the tenant ID, site URL and affected user's sign-in identity.
In multi-tenant work, the same email-looking identity can exist as a home-tenant user and as an external identity in another tenant. Test the object that actually signs in to the target.
2. Identify the group type and tenant
Record whether the assigned object is a Microsoft 365 group, security group, mail-enabled security group, dynamic group or SharePoint group. Then confirm where that group was created.
SharePoint communication sites can grant access through SharePoint groups containing users, security groups or Microsoft 365 groups. Microsoft advises against nested security groups because they can cause performance problems. See the modern SharePoint permissions guidance.
3. Confirm the user exists in the target tenant
For cross-tenant collaboration, the person normally needs a corresponding external identity in the resource tenant, created by invitation or an approved cross-tenant synchronisation design.
Do not assume the source group's object ID has meaning in the target tenant. Microsoft Entra cross-tenant synchronisation has specific supported group scenarios and restrictions. Nested groups are not supported, and not every group type can be created in the target. Check the current cross-tenant synchronisation FAQ.
4. Check membership, not ownership alone
For a Microsoft 365 group-connected team site, owners become site owners and members become site members in the normal model.
Microsoft also documents a case where a group owner who is not a group member cannot find the group's content in Microsoft 365 search because security trimming evaluates membership. If the owner is meant to participate, confirm that they are also a member. Read Microsoft's group-owner search troubleshooting article.
5. Check the SharePoint permission grant
Use Settings > Site permissions and, when needed, Advanced permission settings.
Confirm which group or user was granted access, the permission level, whether the site or item has unique permissions, and whether the user reaches the exact resource being tested.
Test direct access and search separately. A person may open a known URL while a recent permission change has not yet appeared in search.
A safe multi-tenant pattern
For modest collaboration, invite or provision the required external users into the resource tenant, place those target-tenant identities in a target-tenant group, then grant that group access to SharePoint.
For larger organisations, design cross-tenant access and synchronisation centrally. Document who owns target groups, how leavers are removed, how failures are monitored and which group types are supported.
Do not solve a group problem by granting broad access. That removes the evidence needed to understand the original failure and may expose content.
A successful test proves that the selected target identity can access the selected SharePoint resource at that time. It does not prove that every source-group change will synchronise, that nested membership works or that external sharing complies with policy.
For practical SharePoint permission and multi-tenant troubleshooting, join the SharePoint & Teams Admins Space.