This post is part of a small blog series covering common Entra ID security findings observed during real-world assessments. Each article explores selected findings in more detail to support a clearer understanding of the underlying risks and practical implications. Introduction In the vast majority of tenants we review , there are enterprise applications that originate from another tenant (referred to here as foreign ). While most of them do not have privileged Entra ID roles assigned, they often have extensive API permissions granted as application permissions. This can introduce risk because the operational security of those identities lies outside the direct control of the organization. Let’s start from the beginning: what are enterprise applications and why are they required? What Are Enterprise Applications An enterprise application is the service principal of an application within a tenant. In other words, it is the local identity created from an application object (app registration) and is represented in the Entra portal as an Enterprise Application. In the case of a foreign enterprise application, the globally unique app registration is located in another Entra ID tenant. Throughout this post, the term “enterprise application” will refer to the service principal object created in the tenant. If a third-party Software as a Service (SaaS) application allows users from an Entra ID tenant to authenticate with their accounts, a corresponding foreign enterprise application must exist in the tenant. When users authenticate to such a multi-tenant application using their Entra ID identity, an enterprise application object is created automatically during consent, or it can be pre-provisioned by an administrator. However, there is a second use case. Sometimes it is necessary to allow a third-party application or external organization to access tenant resources and perform actions without involving a user account. In such app-only scenarios, the enterprise application represents a service principal used for non-interactive authentication (conceptually comparable to a service account in Active Directory). What Are Application API Permissions in Entra ID These third-party solutions use different Microsoft cloud APIs to perform the required actions. There are many APIs available. Some of them cover multiple services (for example, Microsoft Graph API), while others are specific to individual services (for example, SharePoint, Azure Key Vault, or Azure Resource Manager). Today, Microsoft Graph is most commonly used for tasks in Entra ID and Microsoft 365 services, which is why this post primarily focuses on that API. To define which privileges an application has, granular API permissions (OAuth scopes) 1 must be configured. Microsoft Graph allows permissions to be assigned at a very granular level and offers a large number of different permissions to choose from. For most permissions, two variants exist: Delegated permissions 2 : The enterprise application accesses the API in the context of a signed-in user. Application-only permissions 3 : The enterprise application runs as a background service without a signed-in user. This blog post focuses on the second variant. As described, permissions can be defined relatively granularly. For example, if an enterprise application needs to access SharePoint sites, it is possible to choose between: Sites.Read.All — Read items in all site collections Sites.ReadWrite.All — Read and write items in all site collections Sites.FullControl.All — Full control of all site collections Sites.Archive.All — Archive or reactivate site collections without a signed-in user Understanding Application Authentication When an application can act autonomously (without a user), it uses its own credentials to authenticate in the tenant and perform the required actions. These credentials can be either a client secret (password) or a certificate. The credentials used to authenticate are typically: Present on the globally unique app registration object in the publisher’s tenant. These credentials allow authentication in every tenant worldwide where the corresponding enterprise application exists. In rare cases, credentials may be additionally added directly to the enterprise application in the consumer tenant. These credentials are not visible in the Entra admin portal but can be enumerated via API or tools such as EntraFalcon . Since the credentials for the application are controlled in the external tenant, they lie outside the direct control of the consumer organization. If the external tenant is not properly secured or monitored, attackers might be able to steal existing credentials or add new ones and then authenticate as the application in other tenants where the enterprise application is present. It is important to understand that Conditional Access policies do not apply to sign-ins by foreign enterprise applications. While Microsoft Entra Workload ID Premium allows targeting single-tenant enterpri...