Skip to main content
Version: Angophra

Multi-Tenant Applications

Menu path: Observe → Application Governance → Multi-Tenant Apps
URL: /en/insights/dashboard/appGov/multi-tenant

Purpose​

The Multi-Tenant Applications page identifies application registrations in your Entra ID tenant that are configured to accept sign-ins from users in other Azure AD / Entra ID tenants - not just your own. This is known as "multi-tenant" configuration.

When an application is set as multi-tenant, users from any Entra ID tenant (or in some cases, any Microsoft account) can authenticate to it. This is appropriate for software products intended to be sold or distributed to other organisations, but it is generally not appropriate for internal business applications. A multi-tenant configuration on an internal application means that an external party could potentially authenticate to it using their own Entra ID credentials - which may or may not be intentional.

This page helps you understand the external exposure surface of your application estate.

Charts​

Tenant Exposure Breakdown​

Chart type: add example --> Donut chart
What it shows: 32 total application registrations, broken down between Multi-Tenant (accepting external sign-ins) and Single Tenant (your organisation only).

In the example, the vast majority are Single Tenant, with a small multi-tenant segment - this is the healthy pattern for an enterprise environment.

Why it matters: Every multi-tenant application is a potential attack vector from external tenants. An attacker who can register a user in any Entra ID tenant (which is possible with a free Microsoft account) could potentially authenticate to your multi-tenant application.

External Exposure Over Time​

Chart type: add example --> Time-series area chart
What it shows: How the count of multi-tenant applications has grown over time, with Multi-Tenant and Single Tenant applications tracked separately.

Why it matters: A growing multi-tenant line without a corresponding business justification for each new multi-tenant app is a governance concern. This chart allows you to identify when multi-tenant applications started being created and whether the trend is accelerating.

The Multi-Tenant Applications Table​

The table lists all application registrations with:

  • Display Name - Application name
  • Sign-In Audience - The Entra ID audience setting:
    • AzureADMyOrg - Single tenant (your organisation only) ✅
    • AzureADMultipleOrgs - Multi-tenant (any Entra ID tenant) ⚠️
    • AzureADandPersonalMicrosoftAccount - Any Entra ID tenant plus personal Microsoft accounts ⚠️⚠️
  • Multi-Tenant - Yes/No flag
  • Redirect URIs - Count of redirect URIs configured
  • Highest Permission Risk - The overall risk level of the application's permissions

Key findings from the example data​

Three applications are configured as multi-tenant (AzureADMultipleOrgs):

  1. Apporetum Dev Integration - High permission risk, multi-tenant, with Group.ReadWrite.All and similar high-risk permissions. This is a development integration application that should likely be Single Tenant - a development app with high privileges accepting external sign-ins is a risk.

  2. nick-testing-stuff-delete-whenever - Low risk, multi-tenant. The name itself indicates this is a test application that should be deleted. A test/experimental application with a multi-tenant configuration that has not been cleaned up.

  3. Snow Connector - Low risk, multi-tenant. This is likely a ServiceNow (SNOW) connector that may legitimately need to accept connections from the ServiceNow tenant. This is an example of a legitimate multi-tenant configuration.

How to evaluate whether multi-tenant is appropriate​

Ask the following questions for each multi-tenant application:

  1. Is this application sold or distributed to other organisations? If yes, multi-tenant may be appropriate.
  2. Is this an internal business application? If yes, it should almost certainly be Single Tenant.
  3. Does this integrate with a specific external service (like ServiceNow, Salesforce, etc.)? If yes, check whether a dedicated service principal from that provider should be used instead.
  4. Can you identify the business owner and the original reason for the multi-tenant configuration? If not, treat it as a finding and default to converting it to Single Tenant.

Remediating unintended multi-tenant apps​

To convert a multi-tenant application to single tenant:

  1. Identify all external users or tenants that currently rely on the application (check sign-in logs)
  2. If no external use is found: update the signInAudience property in the application registration manifest to AzureADMyOrg
  3. If external use is found: work with the application owner to either migrate those users to your tenant or establish whether the multi-tenant configuration is genuinely required