Section A — Add Domain to Collaboration Allow List
1
Sign In with PRV Account & Elevate to Global Administrator
entra.microsoft.com
▼
💡 Why is this step needed?
The collaboration allow list is a tenant-wide security boundary that controls which external organisations can receive B2B invitations. Modifying it requires Global Administrator privileges — the highest role in Entra ID — because changes directly affect who can be invited into the R&R tenant. Using a PRV account with PIM activation ensures this powerful access is time-limited and fully audited.
| # | Action | Notes |
|---|---|---|
| 1 | Navigate to the Entra Admin Centre | entra.microsoft.com |
| 2 | Sign in with your PRV (privileged) account | Never use a standard user account |
| 3 | Activate Global Administrator via PIM | Navigate to PIM → My Roles → Activate |
2
Navigate to External Collaboration Settings
External Identities
▼
💡 Why is this step needed?
External Collaboration Settings is the central policy blade in Entra ID that governs all B2B collaboration behaviour for the R&R tenant — including who can be invited, what roles guests receive, and which domains are allowed or blocked. The allow list is managed within the Collaboration restrictions section of this blade.
| # | Action | Notes |
|---|---|---|
| 1 | Navigate to Entra ID → External Identities → External collaboration settings | |
| 2 | Scroll down to the Collaboration restrictions section | This shows the current allow list of approved domains |
3
Add the Partner Domain to the Allow List
Collaboration restrictions
▼
💡 Why is this step needed?
R&R uses a domain allow list model for B2B collaboration — only users from explicitly approved domains can be invited as guests. This is a security decision: rather than allowing invitations to any organisation and blocking specific threats (a deny list), R&R takes a zero-trust approach where every partner must be pre-approved. Adding a domain to the allow list is the gate that permits B2B invitations to be sent to users at that domain.
| # | Action | Notes |
|---|---|---|
| 1 | In the Collaboration restrictions text box, enter the partner's domain | e.g. supplier.com |
| 2 | Click Save at the top of the page | The domain is now added to the collaboration allow list |
| 3 | Verify the domain appears in the allow list |
What happens if a domain is NOT on the allow list?
Invitations sent to users whose domains are not in the allow list will be blocked. The inviting user will see an error indicating the recipient is not eligible for invitation. This is by design — it ensures R&R maintains tight control over which external organisations have any form of access to the tenant.
Invitations sent to users whose domains are not in the allow list will be blocked. The inviting user will see an error indicating the recipient is not eligible for invitation. This is by design — it ensures R&R maintains tight control over which external organisations have any form of access to the tenant.
✔ What happens next?
Users from the approved domain can now be invited as B2B collaboration guests into R&R's tenant. They will receive an invitation email and can redeem it to access the resources they are aligned with. However, without inbound MFA trust (Section B), they may be required to register a separate MFA token for R&R.
Section B — Configure Inbound Cross-Tenant Trust
4
Verify the Partner Meets R&R Security Requirements
Pre-check
▼
💡 Why is this step needed?
Configuring inbound MFA trust means R&R will accept the partner's MFA claims as valid — effectively trusting that the partner's Entra tenant enforces MFA to a standard equivalent to R&R's own policies. If the partner's MFA configuration is weak (e.g. SMS-only, no Conditional Access, no number matching), trusting their claims would weaken R&R's security posture. Evidence of sufficient security configuration must be provided and reviewed before trust is established.
| # | Action | Notes |
|---|---|---|
| 1 | Confirm the partner has been designated as trusted by R&R security | This is a governance decision, not a technical one |
| 2 | Verify evidence of their tenant configuration has been provided and reviewed | e.g. Conditional Access policies, MFA methods, compliance posture |
| 3 | Obtain approval to proceed with inbound trust configuration | Document the approval in the change record |
⚠ Security Gate — Do Not Skip
Inbound trust is not automatic and should not be configured for every partner. Only partners that have demonstrated their tenant meets R&R's security bar should have inbound claims enabled. Configuring trust for an insecure partner creates a bypass of R&R's MFA Conditional Access policies.
5
Elevate to Security Administrator & Navigate to Cross-Tenant Settings
entra.microsoft.com
▼
💡 Why is this step needed?
Cross-tenant access settings — including inbound trust — are managed under External Collaboration Settings in Entra ID. This section requires at least Security Administrator role. This is a different (lower) privilege level than the Global Administrator required for the allow list in Section A, following the principle of least privilege.
| # | Action | Notes |
|---|---|---|
| 1 | Sign in with a PRV account and activate Security Administrator via PIM | If already elevated as Global Admin from Section A, this role is included |
| 2 | Navigate to Entra ID → External Identities → External collaboration settings | |
| 3 | Locate the Organizational settings section | This lists organisations with specific cross-tenant policies |
6
Add the Partner Organisation
Organizational settings
▼
💡 Why is this step needed?
Before configuring inbound trust, the partner's Entra ID tenant must be registered as a named organisation in R&R's cross-tenant access settings. This creates a per-organisation policy override — without it, the partner would inherit the default inbound settings which do not include MFA trust. Adding the organisation enables you to configure custom inbound policies specifically for that partner.
| # | Action | Notes |
|---|---|---|
| 1 | Under Organizational settings, click Add organization | |
| 2 | Enter the partner's domain name in the search box | e.g. supplier.com |
| 3 | Wait for the tenant details to populate | Entra will resolve the domain to the partner's tenant ID and name |
| 4 | Click Add | The organisation now appears in the Organizational settings list |
ℹ Tenant Resolution
When you enter the domain, Entra automatically looks up the associated tenant ID and display name. If the domain does not resolve, it may not be verified in the partner's Entra tenant — confirm the correct domain with the partner before proceeding.
7
Open Inbound Access & Navigate to Trust Settings
Organizational settings
▼
💡 Why is this step needed?
Each organisation in the cross-tenant settings has its own Inbound access policy — this controls what R&R will accept from incoming users from that tenant. By default, new organisations inherit the default settings (which do not include MFA trust). You must switch to Customize settings to configure trust policies that are specific to this partner.
| # | Action | Notes |
|---|---|---|
| 1 | Click the hyperlink under Inbound access for the partner | It will typically read "Inherited from default" |
| 2 | Navigate to the Trust settings tab | |
| 3 | Select Customize settings | This overrides the default and allows per-organisation configuration |
8
Enable Inbound MFA Trust & Save
Trust settings
▼
💡 Why is this step needed?
This is the critical configuration step. Enabling "Trust multifactor authentication from Microsoft Entra tenants" tells R&R's Conditional Access engine to accept MFA claims that the partner's tenant passes through the cross-tenant connection. Without this, guest users from the partner organisation would be prompted to complete MFA again using an R&R-registered method — which typically means registering a separate authenticator app, creating friction and support overhead. With trust enabled, the partner's MFA satisfies R&R's policies seamlessly.
| # | Action | Notes |
|---|---|---|
| 1 | Tick "Trust multifactor authentication from Microsoft Entra tenants" | This is the primary setting — enables MFA claims passthrough |
| 2 | Review whether additional trust checkboxes are required | See the available claims below |
| 3 | Click Save | Changes take effect immediately for the partner organisation |
Available Inbound Trust Claims:
MFA Trust
Accept the partner's MFA claims — guest users don't need to re-register MFA for R&R
✦ Primary — Enable for approved partners
Compliant Device
Accept the partner's device compliance claims from their Intune policies
◇ Optional — if R&R CA requires device compliance
Hybrid Joined Device
Accept claims that a device is Hybrid Azure AD Joined in the partner's tenant
◇ Optional — if R&R CA requires hybrid join
✔ Configuration Complete
The partner organisation is now fully configured for B2B collaboration. Their domain is on the allow list (Section A) and inbound MFA trust is enabled (Section B). When guest users from this organisation are invited and access R&R resources, they will be able to sign in with their home credentials and their home MFA will satisfy R&R's Conditional Access policies — no separate R&R MFA registration required.
ℹ How it works at sign-in
When a guest user from the trusted partner accesses an R&R resource, they are redirected to their home tenant to authenticate. Their home tenant handles username/password and MFA. The resulting token includes an MFA claim which is passed back to R&R's Entra via the cross-tenant trust. R&R's Conditional Access policy evaluates this claim and — because trust is configured — accepts it as valid, granting access without a second MFA prompt.