Workload ID Premium, CAP policies with multitenant apps

The Core Concept: Who Has Authority?

Conditional Access is a policy engine that enforces rules at the moment of authentication against a specific directory (tenant). The fundamental principle is that a tenant administrator only has the authority to enforce policies on identities and resources that are under their direct control within their own tenant.

Let's use an analogy:

• Imagine your company's office building is your Home Tenant. You are the building manager.
• A single-tenant application is like a delivery robot that you built and registered specifically for your building. It only works there. You can put any rules you want on that robot (e.g., "It can only use the service elevator between 2-4 AM"). You have full authority.
• A multi-tenant application is like a FedEx delivery person. They have their own uniform, their own scanner, and their own rules set by FedEx (the app's home tenant). They are registered with FedEx, not with your building.

When the FedEx delivery person (the multi-tenant app's service principal) shows up at your building's front desk (your tenant's authentication endpoint) to access a resource (like delivering a package to your mailroom), you can set rules for them while they are in your building. For example, you can say, "Anyone entering this building, including FedEx drivers, must have their ID badge scanned." This is like applying a CA policy to the access of your resources.

However, you, as the building manager, cannot call FedEx headquarters and say, "I want all your delivery drivers, everywhere in the world, to wear blue hats." That's not your authority. Only FedEx can set that policy for their own employees (their workload identities).

Applying the Analogy to Entra ID

1. Single-Tenant Service Principals:
   • When you register a new application in your tenant and set it to "Accounts in this organizational directory only," you are creating both an Application Object and a Service Principal that are native to your tenant.
   • You "own" this identity. You control its lifecycle, its permissions, and its authentication behavior.
   • Therefore, you can apply Conditional Access for workload identities directly to this service principal because you have the authority to do so.
2. Multi-Tenant Service Principals (The "Out of Scope" Part):
   • When a third-party SaaS provider (like Salesforce, Slack, or even another Microsoft service) builds a multi-tenant app, they create the Application Object in their own home tenant.
   • When you grant consent to that application in your tenant, a "ghost" or "linked" Service Principal is created in your tenant. This service principal is just a local representation of the real identity that lives in the other tenant.
   • The "brain" and the credentials of this identity are managed by the application's home tenant, not yours.
   • This is the technical limitation: Your Conditional Access policy cannot control the authentication behavior of an identity whose home and authority reside in a different tenant. You cannot enforce a rule like "This multi-tenant app can only get a token if it's coming from a specific IP address" because the token issuance is ultimately controlled by the app's home tenant, not yours.

So, How Do You Protect Against Risky Multi-Tenant Apps?

You are not powerless. You just have to shift your thinking from controlling the identity to controlling the access.

Instead of applying the policy to the workload identity itself, you apply Conditional Access policies to the resources that the identity is trying to access.

Here are the correct ways to secure multi-tenant app access:

1. CA Policies on Resources: Create a Conditional Access policy that targets All cloud apps and then excludes the ones you don't want to affect. In the "Users and groups" assignment, you can include specific users. When a user tries to use the multi-tenant app, the policy will evaluate the user's sign-in context (location, device, risk) before allowing access to that app.
2. App Protection Policies: For third-party SaaS apps, you can use Microsoft Defender for Cloud Apps (part of the E5 license) to apply session controls. This allows you to do things like block downloads, apply sensitivity labels, or monitor activity for multi-tenant apps after the user has authenticated.
3. Reviewing Permissions (Least Privilege): The most important control for multi-tenant apps is to be extremely diligent about the permissions you grant them. If an app is asking for Mail.ReadWrite.All but only needs to read calendar entries, deny the consent and push back on the vendor. This limits the "blast radius" if the app itself is ever compromised.

Conclusion: It's a Technical Limitation, Not Licensing

To summarize your question directly:

• A. Is there a technical limitation? Yes. The limitation is fundamental to the federated, multi-tenant architecture of Entra ID. A tenant administrator's authority is scoped to their own tenant. You cannot enforce identity-centric policies on identities that are homed in another tenant.
• B. Is this a licensing perspective? No. Even with the highest-level licenses (like E5), you cannot overcome this architectural boundary. The licenses give you the ability to create and apply CA policies, but they don't change the fundamental rules of tenancy and authority.