“Trust” in a world of Zero Trust

Or “Trust, but always verify”

Today, I was confronted with the Microsoft Entra ID configuration that allows an administrator of a tenant to “trust” an external party’s Microsoft tenant when guests access resources. In the Zero Trust world, because as the security framework implies, we have zero or no trust of anything, not even our partner organizations.

Why then does Microsoft allow me to:

• Trust multifactor authentication from Microsoft Entra tenants
• Trust compliant devices
• Trust Microsoft Entra hybrid joined devices

Cross-tenant access settings in Microsoft Entra govern how an organization interacts with other Entra ID tenants. These settings are essential for maintaining a Zero Trust posture across different organizational boundaries.

If I “trust” an external tenant in the inbound trust settings for MFA and device claims, is that still Zero Trust?

Yes, it can still be considered as adhering to the Zero Trust principle. The Zero Trust model operates on the assumption that threats can come from anywhere—both outside and inside the perimeter—and that every request and session must be verified and validated.

In the context of Entra ID B2B and “trusting” an external tenant, it doesn’t mean you’re blindly trusting the external entities. Rather, you’re trusting that the external tenant has implemented their own security measures, such as MFA, and that they are managing their identities securely.

However, it’s important to note that “trust” in this context doesn’t mean you’re not verifying. You should still have controls and monitoring in place to ensure that the activities of these external identities align with your security policies and expectations. This is in line with the Zero Trust principle of “Always Verify”.

Remember, Zero Trust is not about making networks, identities, or devices trusted or untrusted. It’s about considering every network, identity, and device as potentially compromised and thus always verifying every request as though it originates from an open network. Regardless of where it comes from or what it accesses, Zero Trust teaches us to “never trust, always verify.”

So, while you may “trust” an external tenant, you should still verify their activities and enforce your security policies. This way, you’re still adhering to the Zero Trust principle.

The “home tenant” in the context of Microsoft Entra refers to the original directory or domain where a user’s identity is managed. It’s the tenant that owns the user’s account and where the user’s credentials are stored and verified. When a user from one organization (the home tenant) attempts to access resources in another organization (the resource tenant), Microsoft Entra ID checks for a claim that the user has completed MFA. If such a claim is not present, an MFA challenge is initiated in the user’s home tenant to verify their identity.

In my tenant (Contoso Demo), firstly, I have a Conditional Access policy that requires everyone, including guest users to MFA. My policy is called “Multifactor authentication for Microsoft partners and vendors” and it applies to all users (with exclusions for my break-glass accounts) when accessing all cloud apps, and requires MFA:

In the my cross-tenant settings, for a particular partner, I have configured the inbound trust settings to trust MFA:

So, when I trust MFA from Microsoft Entra tenants, I’m essentially allowing my Conditional Access policies to recognize and accept MFA claims from users’ home tenants, which can streamline access while maintaining security as per the Zero Trust principle of “Always Verify.” This means that even though I’m trusting an external organization’s MFA claim, I’m still adhering to Zero Trust by verifying the user’s identity through their home tenant’s authentication process.

Because I signed in with my NBConsult account, but accessing the Contoso Demo resource tenant, I authenticated my NBConsult account with passwordless phone sign-in (MFA)

Then when I access the resource in Contoso Demo, if I am asked to sign in:

I was not prompted to provide MFA for the Contoso Demo tenant.

When I examined the sign-in logs for the guest signing in, I can see that MFA was in the token and that satisfied my conditional access policy:

If I were able to log into NBConsult without MFA (I am not able to, as it is required), and then tried to access Contoso Demo resources, I would be prompted to satisfy MFA first. I assume I will be prompted to MFA using my NBConsult registered methods otherwise I would need to manage MFA methods on Contoso Demo’s tenant.

I summary, as long as I have a conditional access policy requiring MFA of my guests, I can “trust” external Microsoft tenants to honor that requirement. My tenant, however, will verify this at sign-in though.

Next, I will dive into and test trusting device compliance from NBConsult.