Microsoft Entra: reduce multi-tenant app risk

Key insights

• A shared vendor credential can put every customer tenant that authorized the app at risk.
• Consent creates a service principal in the customer tenant, but the vendor retains the app credential.
• App instance property locks and allowed tenants (preview) have specific limits; they do not eliminate shared-credential risk.
• The source recommends considering a separate app for each customer to reduce the blast radius.
• App management policies can block client secrets and cap their lifetimes.

Microsoft Entra multi-tenant apps can expose multiple customer organizations if a shared vendor credential is compromised. This matters to ISVs, managed service providers (MSPs), and tenant administrators who approve or operate apps across organizations. Merill Fernando’s discussion with Kelvin Tegelaar raises the design and operational trade-offs behind reducing that exposure.

What's new

The central issue is the trust model, not a newly announced Entra feature. A vendor can register one multi-tenant application and ask customers to consent to it; each customer that approves it gets a service principal in its own tenant. The credential used to authenticate the app remains with the vendor, so a leak of that shared credential could affect more than one customer.

That is different from a user signing in with a password. The source focuses on application credentials and workload identities: the app authenticates as itself, using a credential such as a secret or certificate. A control aimed at interactive user sign-ins may not address that path in the same way. The result is a cross-tenant risk that deserves review before an organization approves a vendor app.

The source also flags several controls and design choices rather than presenting a single fix. These include app instance property locks, allowed tenants (identified as preview in the source), Conditional Access for workload identities, disabling an application's sign-in, app management policies, and certificate rotation using Microsoft Graph’s operation. Each addresses a different part of the problem; none should be treated as a guarantee that a vendor's shared credential cannot be abused.

Who it is for and what you need

This applies most directly to software vendors building services for multiple organizations, MSPs deploying management tools, and Microsoft Entra administrators who grant consent to those tools. It is also relevant when assessing existing enterprise applications: an integration that is no longer needed may still represent an authorized path into the tenant.

The source does not specify a license requirement, tenant type, geographic limit, or general rollout status for the controls it mentions. It describes allowed tenants as preview, but does not provide further eligibility or deployment details. Check the linked Microsoft documentation for the current scope and prerequisites before relying on a particular control.

Administrators should first identify which applications have been consented to, whether the business still needs them, and what permissions they hold. The source does not provide a full inventory procedure or a permissions baseline. It does, however, emphasize that consent places a service principal in the customer tenant while the vendor retains its credential, an important distinction when deciding who controls the risk.

How it works

For service providers, the source raises an architectural alternative: use one app per customer rather than a single app shared across all customers. This can reduce the number of customers exposed by one credential, but it comes with an operational trade-off: maintaining separate app instances and credentials. The material does not quantify that effort or prescribe a deployment pattern.

1. Review the app relationship. Confirm that the integration is still needed and understand which customer tenants have consented to it. The source warns that an app may remain present even when a service is not actively used.
2. Assess the shared-credential boundary. Establish whether one application identity and credential serve many customers. For an ISV or MSP, consider whether separate per-customer apps would reduce the potential blast radius.
3. Evaluate Entra controls. Review app instance property locks and allowed tenants, noting that the latter is described as preview. For an emergency, Microsoft documents how to disable user sign-in for an enterprise application; check the documentation for the exact portal steps.
4. Revisit credential handling. The source recommends certificate rotation through Microsoft Graph rather than relying on Application.ReadWrite.All for that approach. It also points to app management policies as a way to block client secrets and set lifetime limits.
5. Account for delegated administration. The source warns that GDAP can widen the blast radius for MSP tools. Include the administrative relationship in the risk review rather than assessing only the app registration.

Conditional Access for workload identities is another item to evaluate, but the source explicitly cautions that it cannot cover a vendor's multi-tenant app in the scenario discussed. Review the policy documentation to understand its boundaries; do not assume that enabling a workload identity policy controls every app used by an external vendor.

Limitations and open questions

There is no universal switch here that makes a multi-tenant app safe. An app lock, a tenant restriction, credential policy, or sign-in disablement applies to a particular part of the configuration or response. The right combination depends on the app design and the access the customer has approved.

The source does not give a complete step-by-step configuration for every control, name required licenses, or confirm the rollout status beyond labeling allowed tenants as preview. It also does not provide a full incident-response checklist or quantify the cost of separate app instances. Those details should be verified in current Microsoft documentation and with the vendor before making a production change.

The practical takeaway is to treat vendor consent as an ongoing trust decision. Remove access that is no longer needed, understand whether credentials are shared across customers, and consider how a compromise would be contained. For new services, decide on tenant and application separation early rather than assuming that a single shared identity will remain a low-risk convenience.

Sources

• Microsoft Learn: Configure app instance property locks
• Microsoft Learn: Conditional Access for workload identities
• Microsoft Learn: Disable user sign-in for an enterprise application
• Microsoft Graph: Add a key to an application
• Microsoft Learn: Configure app management policies
• Merill Fernando’s discussion with Kelvin Tegelaar

Frequently asked questions

Why can a multi-tenant app put several customers at risk?

Customers can consent to the same vendor app in their tenants while the vendor retains a shared credential. If that credential is compromised, the risk can extend to multiple tenants where the app was authorized.

Does Conditional Access for workload identities protect against a vendor's multi-tenant app?

The source cautions that it cannot cover the vendor's multi-tenant app in the scenario discussed. Review Microsoft's workload identity documentation for the policy's scope and limits.

Can administrators block client secrets for applications?

The source points to Microsoft Entra app management policies for blocking client secrets and capping their lifetimes. Check Microsoft's documentation for configuration details and applicability.

Is the allowed tenants control generally available?

The source labels allowed tenants as preview but gives no broader rollout or eligibility details. Confirm its current status and prerequisites in Microsoft documentation.