Removing Stale App Registrations and Enterprise Applications from Your Tenant

Over time, App Registrations and Enterprise Applications can accumulate in your tenant, especially if user consent has not been enabled in the past. Without proper controls, a new Enterprise application could easily be added to your tenant. Acknowledging the risk, Microsoft has acted by changing the default user consent settings.

As a responsible Entra ID admin, your goal should be to retain only applications that are actively used, while ensuring each one remains secure and properly managed. This blog post focuses on identifying actively used applications in your Entra ID tenant. This is particularly important because, depending on the permissions granted, a compromised application can have a significant impact on your environment. Additionally, when you allow access from an external multi-tenant application to your tenant, you have no control over its security posture, yet you've granted it access to your tenant’s resources. That’s why it’s essential to review your Enterprise Applications and ensure that every service with access is one you actually use and trust.

Of course, this is easier said than done. Some of those app registrations were created years ago, and it’s not always clear what they’re used for, or if they’re still needed at all.

In this blog post, we’ll walk you through some essential checks and considerations to perform before you start removing any App Registrations or Enterprise Applications from your tenant. The last thing you want is to break a critical integration by accident, which leads to a major business disruption. A few weeks ago, Microsoft MVP Matthew Levy had a great blog post on the risks of using the scream test to remove apps (hint - it's not generally recommended). 

Where do all applications come from?  

Applications can appear in your Microsoft Entra ID tenant through several mechanisms. 

User or Admin Consent to Multi-Tenant Applications 

The most common way applications are introduced is through user or admin consent to third-party multi-tenant applications. These apps are registered in another tenant but are designed to be usable across multiple Entra ID environments. When someone in your organization consents to such an app, an Enterprise Application (also known as a Service Principal) is automatically created in your tenant. This allows the external app to interact with your directory, often with significant permissions depending on the consent scope.

Creating an App Registration 

Another way applications are registered is when someone in your organization creates an App Registration. This process defines the app’s identity configuration, such as API permissions, redirect URIs, and secrets. Upon creation, Entra ID automatically generates a corresponding Enterprise Application in your tenant. This local instance is used to assign access, enforce policies, and manage how the app interacts with your environment. 

In summary: 

• Single-tenant App Registration: Created within your own tenant. It automatically generates an Enterprise Application, and you are fully responsible for managing its permissions and lifecycle. 

• Multi-tenant App Registration: Created in another tenant. When a user or admin in your tenant consents to it, an Enterprise Application is created locally. You inherit the app’s presence and permissions, even though you didn’t register it. 

                                        Figure 1: Graphic showing the differences between single-tenant apps and multi-tenant apps in Entra ID. 

App Registrations 

Start by reviewing your App Registrations; it’s the easiest place to begin. For every App Registration you delete, you can also remove the corresponding Enterprise Application. But don’t be too quick; make sure to complete all checks before deleting anything! 

Check the Owner 

While Entra ID doesn’t require an owner by default, some applications in your tenant may have one assigned. Contacting this person is a good starting point to verify whether the app registration is still in use. Keep in mind that an app registration without an owner doesn’t necessarily mean it’s unused; rather, it’s a potential indicator. 

Check for a Redirect URI 

A redirect URI, or reply URL, is the location where the Entra authorization server sends the user and delivers tokens once the user has successfully signed in or signed out. 

A redirect URI isn’t required for every app registration, but if it exists, it’s often a sign of integration with production services or third-party tools. For example, in the screenshot below, we see that after users are authenticated by Entra ID through the app registration, they are redirected to the login page of a web application, specifically via the configured redirect URI. The next step is to verify whether this redirect URI points to an application that is still actively used in your business.

                                                                                       Figure 2: A screenshot of an example redirect URI in the Entra portal.

Certificates, Secrets & Federated Credentials 

Check whether there are any active certificates or client secrets associated with the app registration. You can easily view their expiration dates. Also, verify if any Federated Credentials are configured; these may link the app to an external identity provider like Okta or OneLogin, or to Azure itself, which is the preferred option for services hosted on the Azure platform. Just because valid credentials exist doesn’t guarantee the app registration is actively used. It’s simply a sign that it might still be in use. 

On the other hand, if no credentials are configured or they are all expired, that’s a strong indicator that this app registration can likely be deleted. 

*Note: App Registrations do not generate sign-in logs. All authentication activity is recorded on the Enterprise Application, since that's where the Service Principal (the app's identity in your tenant) exists. 

Enterprise Apps 

As stated in the introduction, you will encounter more Enterprise Applications than App Registrations in your tenant. 

Once you’ve finished reviewing an App Registration, you can click through to the corresponding Enterprise Application. You can do this directly from the App Registration blade in the Entra portal.

                                                                  Figure 3: Screenshot of the link from app registration to the enterprise app in the Entra portal. 

Sign-in logs 

Within the Enterprise Application, you can review sign-in activity for the last 30 days. When checking, be sure to include: 

• Interactive sign-ins 
  • What it is: A user manually signs in—typically through a browser or app interface.  
  • Example: A user enters their credentials to access a web app. 
• Non-interactive user sign-ins 
  • What it is: A user is authenticated without manual input, often via background processes or token refreshes. 
  • Example: A mobile app silently refreshes a token to keep the user signed in. 
• Service principal sign-ins 
  • What it is: The app itself (via its service principal) authenticates to access resources, typically using a certificate or secret. 
  • Example: A backend service calling Microsoft Graph using its own identity. 
• Managed identity sign-ins 
  • What it is: Azure services (like Functions, VMs, Logic Apps) use their managed identity to authenticate securely without secrets. 
  • Example: An Azure Function accessing a Key Vault using its managed identity. 

Lack of activity in these areas strongly indicates that the app is rarely or no longer in use. If you are ingesting sign-in logs into a Log Analytics workspace with extended retention (such as Sentinel Datalake), review those logs to determine how long the app has been inactive and gain greater confidence in your assessment. 

*Note: It’s recommended to enable diagnostic logging in Microsoft Entra ID to ensure visibility into application activity and sign-in events. 

Provisioning 

It’s not uncommon to encounter Enterprise Applications in your tenant that exist solely for user provisioning purposes. 

Some applications support SCIM (System for Cross-domain Identity Management), an open standard that enables automated provisioning and deprovisioning of user accounts between identity systems and cloud apps. 

For example, if you want to automatically create user accounts in a tool like a learning platform or a project management app, you can (if supported) set up SCIM-based provisioning in Entra ID. This way, when a user is added to a specific group, Entra ID can automatically create, update, or remove their account in that external system. SCIM is especially useful when the target application manages its own users, groups, and roles internally. Without provisioning, these accounts would have to be created and maintained manually in the app. 

If you're evaluating whether an Enterprise Application is still actively provisioning users, start by checking whether a SCIM configuration is present. If SCIM is enabled but you're unsure if it's still in use, open the provisioning logs to review recent activity.  Look for the most recent events where users were added, updated, or removed. This can give you clues about whether the process is still active and may help identify the current application or product owner. Keep in mind that these logs have a limited retention of 30 days.  

Single Sign-On (SSO) 

Don’t confuse SCIM with Single Sign-On (SSO). Although they often work together, they address different needs. 

SSO allows users to sign in to an application using their Entra ID identity, typically via protocols like SAML or OpenID Connect. It handles authentication, but not user account provisioning. 

Many applications still require users to exist in their internal user directory to assign roles, permissions, or licenses. That’s where SCIM complements SSO, by ensuring that user accounts are already created and properly configured before the user attempts to sign in. 

If you're assessing whether the Enterprise Application is still in use, start by reviewing the SSO configuration. However, the sign-in logs of the Enterprise Application usually provide the most reliable indication of whether it’s actively being used. 

Checklist 

If you’re here for the key insights without extra reading, here’s a quick checklist outlining each step and the confidence level you can have when deciding to delete an app. Remember, this is a guideline. 

App Registration Cleanup Checklist 

Enterprise Application Cleanup Checklist 

By applying the checks outlined above, you’ll likely uncover numerous inactive App Registrations and Enterprise Applications lingering in your tenant.  

*Note: When deleting an App Registration, be sure to also remove the corresponding Enterprise Application, as Entra ID does not automatically delete the linked object. 

This blog post walked through several checks you can perform, either manually via the Entra ID portal or, if you're comfortable with PowerShell, you can automate them as part of your cleanup workflow for lingering app registrations and Enterprise Applications. However, many of these insights are already available through Enow’s App Governance Accelerator, offering a more scalable and streamlined approach. The bottom line is that I recommend starting your identification and review process sooner rather than later. It's a governance and security challenge that every tenant will eventually face, and it's best to proactively address the risk before a security incident occurs.  

⚡ Take the Guesswork Out of App Cleanup
Manually chasing stale applications is risky and time-consuming. One wrong move can break a critical integration and disrupt your business. ENow’s App Governance Accelerator helps you quickly identify ownerless, risky, or unused applications across your Entra ID tenant, with built-in automation and reporting that makes cleanup safer and more repeatable.

 

👉 Learn more about App Governance Accelerator

See how you can move from reactive cleanup to proactive control.