How to find multi-tenant Azure app registrations: exposure review and lock-down

Any app registration set to accept accounts from other Microsoft Entra tenants can be consented into a tenant you do not control, and its credentials then work there too, so every multi-tenant registration you own is an identity that can reach beyond your boundary. Registrations are single tenant by default, but the setting is often flipped during development, copied from a sample or left on after a partner integration ends. This guide shows how to find registrations in your tenant whose sign-in audience includes other tenants, decide which genuinely need it, restrict or convert the rest, and stop new ones appearing without review. It is for Entra ID administrators, cloud identity engineers and application owners. The wider model of applications, service principals and consent is in the Entra ID Applications and Consent Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• The property to find is signInAudience: registrations set to AzureADMultipleOrgs or AzureADandPersonalMicrosoftAccount can be used from other organisations' tenants.
• Consent creates a foothold elsewhere: when a user or admin in another tenant consents, Entra ID creates a service principal for your app in that tenant, and your app's secrets and certificates obtain tokens there.
• Most internal apps do not need it: line-of-business apps used only by your own staff should be AzureADMyOrg; multi-tenant should be a reviewed exception with an owner.
• There are now native guardrails: an allowed-tenants list on the registration (signInAudienceRestrictions, Microsoft Graph beta as of November 2026) and an app management policy that blocks new multi-tenant apps.
• Audience settings do not replace code checks: Microsoft states that apps must still validate the tenant (tid) claim in tokens.

Why multi-tenant registrations are an exposure

An application object lives in the tenant where it was registered (its home tenant). A service principal is the local instance of that application in each tenant where it is used. For a single-tenant app both live in one place. For a multi-tenant app, the first consent from a user or admin in another tenant creates a service principal there and records the consent, as Microsoft describes in its multi-tenant conversion guidance.

• Credentials travel: the client secrets and certificates are on the application object in your tenant. Anyone holding them can request tokens in any tenant where the app has a service principal and permissions.
• Your security posture becomes someone else's risk: a leaked secret for a multi-tenant app is a cross-tenant incident. The Multi-Tenant SaaS App Credential Compromise Playbook covers response.
• Forgotten test apps: an application registered in a development or test tenant, outside production change control, can still be consented into production and hold production permissions. See Test tenants and legacy app registrations as a breach source.
• Phishing reach: a multi-tenant app with a convincing name can be presented for consent to users in any tenant that allows user consent. That is the inbound side, covered in the Consent Phishing and Illicit OAuth Grants Guide.

The sign-in audience values

Microsoft's validation rules also differ by audience: a multi-tenant registration needs a globally unique Application ID URI, and the personal-account audiences have tighter limits on secrets and permissions. The value is visible in the registration's Authentication pane and in the manifest.

Step 1: inventory registrations by audience

All queries below are read-only. Run them with an account or app holding only read permissions such as Application.Read.All.

1. Portal view: in the Microsoft Entra admin center, open App registrations, select All applications and add the supported account types column, or open each candidate's Authentication pane. Practical for small tenants.
2. Microsoft Graph filter: the signInAudience property on the application resource supports $filter with eq, ne and not. List everything that is not single tenant with a filter of signInAudience ne 'AzureADMyOrg'. Microsoft documents that advanced filters need the ConsistencyLevel: eventual header and $count=true.
3. Collect context per app: appId, displayName, createdDateTime, owners, publisherDomain, verified publisher, credentials (keyCredentials, passwordCredentials with end dates), and requiredResourceAccess (the permissions it asks for).
4. Find where it is used: in your own tenant, check the matching service principal's sign-in activity. For use in other tenants, the registration itself does not list them; ask the owner, check the app's own customer records, and look for an existing signInAudienceRestrictions list.

Repeat for every tenant you own, including development, test and acquired tenants. The registrations that matter most are often in the tenants nobody inventories.

The reverse view: service principals owned by other tenants

The same review run from the other direction shows which outside applications have a foothold in your tenant. Every service principal backed by an application carries appOwnerOrganizationId, the tenant ID where that application is registered, and Microsoft Graph supports filtering on it with eq and ne. Filtering for service principals whose owner is not your tenant ID lists third-party and partner multi-tenant apps, including any registered by your own other tenants.

• Your other tenants: service principals owned by your development, test or acquired tenants deserve the closest look, because they are your own registrations living outside production governance.
• Type check: servicePrincipalType separates applications from managed identities and legacy service principals, which have no app registration and can only be used in the tenant where they were created.
• Assignment required: appRoleAssignmentRequired defaults to false. Setting it to true means users and apps need an explicit assignment before they can get tokens for that app, a useful control for outside apps that only a few people should use.
• Permissions held: read each one's app role assignments and delegated permission grants. Inbound review is covered in depth in the SaaS and OAuth App Governance Guide.

Step 2: score each registration

Step 3: decide keep, restrict, convert or retire

• Keep as multi-tenant: a product or integration genuinely sold to or used by many organisations. Requires a named owner, verified publisher, certificate or federated credentials instead of secrets where possible, and tenant validation in code.
• Restrict to named tenants: an app shared with a known, small set of tenants, such as a subsidiary or partner. Use the allowed-tenants restriction described below and keep the list under change control.
• Convert to single tenant: an internal app set multi-tenant by mistake. Change supported account types to single tenant after confirming with the owner that no other tenant depends on it.
• Retire: no owner, no current use, no business case. Disable first, then delete after a hold period. The How to find and remove stale service principals in Entra ID guide covers the staged approach.

For a small tenant with a handful of apps, a single review meeting with owners is enough. For a large estate, sort by the risk signals above and work in waves, starting with apps that hold application permissions and active secrets.

Step 4: lock down what stays

Restrict a multi-tenant app to allowed tenants

Microsoft Graph exposes a signInAudienceRestrictions property on the application. Setting it to the allowedTenantsAudience type limits the app to a list of tenant IDs, where it can act as a client or as an API. As documented in November 2026, this is in the Graph beta endpoint only; allowedTenantIds must hold between 1 and 20 tenant IDs; isHomeTenantAllowed currently accepts only true; and the app's signInAudience must be AzureADMultipleOrgs. Microsoft Graph examples of the change use the Application.ReadWrite.All permission. Because beta APIs can change, record the setting in your change system and recheck it after Microsoft updates the API.

Block new multi-tenant registrations

App management policies include an audiences restriction, shown in the admin center as Block multitenant applications and Block consumer account applications. It stops new apps being created with those audiences and stops existing ones being switched to them. Exceptions can be granted for named applications or for named callers (for example, a pipeline identity that publishes a product app) using custom security attributes. Test with a select-applications scope before applying to all applications.

Harden the apps that remain multi-tenant

• Validate tenants in code: check the token's iss and tid claims against your list of customer tenants. Microsoft states that neither signInAudience nor the allowed-tenants list replaces this.
• Prefer certificates or federated credentials: see How to audit Entra workload identity federated credentials.
• Request the least permissions: trim requiredResourceAccess to what the product uses; every unused permission is granted in every consenting tenant.
• Verify the publisher: so administrators in other tenants can tell your app from a lookalike.

Rollout and rollback

1. Inventory and notify: run the Step 1 queries in every tenant and send each owner their list with a response deadline.
2. Pilot one change of each type: convert one internal app to single tenant and restrict one shared app to allowed tenants, then confirm sign-ins still succeed for intended users and fail for others.
3. Apply in waves: highest-risk apps first. Record before-and-after values of signInAudience and signInAudienceRestrictions.
4. Turn on the blocking policy: first scoped to selected applications, then tenant-wide with documented exceptions.
5. Rollback: revert the audience on the registration, or set the restriction back to the unrestrictedAudience type, using the recorded values.

Detection and measurement

Monitor the Entra audit log for updates to applications that change the supported account types or the restriction property, for new credentials on multi-tenant apps, and for new registrations created with a multi-tenant audience. Route these to the SIEM with the app owner attached. The Entra ID Sign-In and Audit Log Detection Guide covers the log plumbing, and How to detect new credentials added to an app registration covers the credential event.

• Multi-tenant share: percentage of registrations not set to AzureADMyOrg, per tenant, trending down.
• Owned and justified: percentage of multi-tenant registrations with an owner and a recorded business case.
• Restricted: percentage of multi-tenant registrations with an allowed-tenants list, where the use case is a known set of tenants.
• Secret-free: percentage of multi-tenant registrations using only certificates or federated credentials.
• Unreviewed changes: audience changes with no matching change record, target zero.

Framework mapping

Common failure patterns

• Sample code defaults: a developer starts from a multi-tenant sample and the setting reaches production unchanged.
• Converting without asking: an app is switched to single tenant and a partner's integration breaks, so the change is reverted and never revisited.
• Trusting the audience setting alone: the app accepts any valid Entra token because the code does not check tid.
• Ignoring non-production tenants: the production tenant is clean, while a test tenant holds a multi-tenant app with consented permissions in production.
• Policy exceptions with no expiry: the blocking policy is on, but a broad caller exception lets any pipeline create multi-tenant apps.

Practitioner checklist

• List every registration with signInAudience other than AzureADMyOrg, in every tenant you own.
• Record owner, business case, permissions and credential types for each.
• Convert internal-only apps to single tenant after owner confirmation.
• Restrict shared apps to an allowed-tenants list, kept under change control.
• Replace client secrets on remaining multi-tenant apps with certificates or federated credentials.
• Confirm each multi-tenant app validates iss and tid in code.
• Enable the Block multitenant applications policy with narrow, reviewed exceptions.
• Alert on audience changes and new credentials on multi-tenant apps.

Standards and references

• Microsoft Learn: Convert single-tenant app to multitenant on Microsoft Entra ID
• Microsoft Learn: Validation differences by supported account types
• Microsoft Learn: Microsoft Graph application resource type
• Microsoft Learn: allowedTenantsAudience resource type (beta)
• Microsoft Learn: Configure app management policies
• Microsoft Learn: Microsoft Graph servicePrincipal resource type
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls

Related NHI Mgmt Group resources: Entra ID Applications and Consent Guide · Test tenants and legacy app registrations as a breach source · Entra ID Cross-Tenant Access and B2B Guest Governance Guide · SaaS and OAuth App Governance Guide