Cleaning up applications in Microsoft Entra ID (formerly Azure AD) is a critical part of application governance. Without the right data and process, admins risk disabling critical business apps, disrupting users, and failing audits.
Picture this: Gareth, an IT administrator, was performing routine cleanup on stale devices. Confident in his identification process, he remotely wiped what he thought was an inactive device. Only later did he realize his mistake. Two devices had near-identical service tags, and he'd only verified the last three digits. That night, Gareth received a frantic call from the user whose device had been irreversibly wiped. This was the scream he hadn't anticipated. His blood ran cold. The sinking feeling every IT admin dreads. Gareth had failed the scream test.
Now imagine applying that scenario to applications in your Entra ID environment, except instead of a single user device, it could be a critical business app. The stakes are higher, and the panic could ripple across teams and processes.
Application governance often comes with a temptation: the “scream test” or “ripping the band-aid off.” The idea is simple: you disable or delete an application and see what breaks.
Administrators under pressure have taken several approaches:
Hasty deletions: Removing apps based on assumptions, often triggered by “last sign-in” dates that aren’t always complete. Entra ID sign-in logs are used in the application’s “Usage & insights” blade and are available for the past 7 days or 30 days, depending on whether your tenant is licensed for Entra ID Premium. Thirty days does not even cover apps that are used quarterly, let alone apps that are used only once a year.Figure 1: Usage & insights in the Entra portal only go back 30 days
Partial verification: Checking only a subset of data about the app, similar to Gareth’s device example.
Manual scripts: Using PowerShell or Graph queries to identify inactive apps, but skipping the double-checking of critical access.
While the scream test may seem like a quick way to identify unused apps, the fallout can be significant. Disabling or deleting the wrong application can disrupt critical business workflows, halt automated processes, and even cause downtime for customer-facing services. These disruptions don’t just frustrate end users; they create compliance risks, increase help desk volume, and damage IT’s credibility with business leaders. What looks like a shortcut often leads to lost productivity, strained cross-functional relationships, and costly recovery efforts.
Enterprise Apps and App Registrations in Entra ID offer different options, but they’re not always obvious.
Remember, in Microsoft Entra ID, apps have two main parts: the app registration and the service principal. The app registration lives in your home tenant and acts as the blueprint. It holds the app’s name, redirect URIs, and what APIs it can access.
The service principal is the app’s identity in a specific tenant and is what actually lets it sign in and use resources.
For single-tenant apps, the app registration and service principal are in the same tenant. Multi-tenant apps work differently. When someone in another tenant gives consent, a service principal is created there. Deleting the app registration in your home tenant removes the service principal in the home tenant too, but the ones in other tenants stay put. That’s why it is important to keep track of both app registrations and service principals if you want to clean up safely and avoid surprises.
For App Registrations, there is no built-in way to fully disable the registration while keeping its configuration intact. You can, however, limit access by managing the associated service principal in your tenant, for example, by blocking user sign-ins, removing assignments, or adjusting policies to temporarily prevent the app from being used.
Figure 2: Deactivating an app registration is not possible even though it’s suggested in the Entra Admin center
Disabling an Enterprise Application is not entirely clear, but it is possible. You have to “Disable” user sign-in, and the setting is actually called “Enabled for users to sign-in?” Clear as mud, isn’t it!
For app registrations without an associated Enterprise application, you have no choice but to delete the app registration or remove the permissions the app has to resources.
Once you get to the point of soft deleting, you need to do it in a specific way because of how the recycle bin (Deleted applications) works:
Soft-deleted applications and associated Enterprise apps go into the Deleted applications container and remain available to restore for up to 30 days. After 30 days, they're permanently deleted.
If you delete an application registration in its home tenant through app registrations in the Microsoft Entra admin center, the enterprise application, which is its corresponding service principal, also gets deleted.
If you restore the deleted application registration through the Microsoft Entra admin center, its corresponding service principal is also restored.
You can recover the service principal's previous configurations, but not its previous policies, such as Conditional Access policies, which aren't restored.
If you delete the App Registration (and the Enterprise Application) in the portal, you can restore it, and its API permissions will be restored too.
If you delete an Entra Enterprise App, it doesn’t automatically delete the app registration in your tenant if there was one associated with the Enterprise App. You will be left with an orphaned App registration.
If you delete them both independently, at different times, it’s possible that you might be able to restore the one, but not the other, depending on the difference in days between the deletions.
Deleted Enterprise applications can't be viewed through the Microsoft Entra admin center. You can only restore soft-deleted service principals using PowerShell or Microsoft Graph API, provided it’s within the 30-day soft-delete window.
Figure 4: PowerShell view of deleted Service Principals
Figure 5: Enterprise Application without app registration in the same tenant
Recycle bin is misleading: Admins may have encountered the “Deleted applications” tab in the Entra portal, which lists apps deleted more than 30 days ago. This leads to a misconception that deleted apps can be restored at any time.
Figure 6: Restore failed for app deleted more than 30 days prior
Exporting configuration: Administrators can export the app registration’s manifest (JSON) before deletion.
This allows a restore if required, though it’s not a one-click recovery of the original app object.
Figure 7: App Manifest JSON download process
All this underscores the tension: admins want to reduce risk from unused applications, but the fear of breaking workflows makes it a high-stakes process.
Tired of the scream test?
Get visibility into stale and orphaned applications with ENow App Governance Accelerator.
👉 Request a demo today
This is where proper data becomes your shield. Instead of relying solely on the scream test, gather actionable insights to substantiate cleanup decisions.
This is certainly not an exhaustive list, and the more data the better. Correlating these pieces of information reduces risk, prevents panic, and ensures that critical resources remain operational. For example, an app with no sign-ins in six months, only one user assigned, and minimal resource access is a prime candidate for removal consideration. You can export the app registration manifest or temporarily block access as an extra safety net.
The ENow App Governance Accelerator tool provides exactly this type of data:
Suspected Stale Apps report: Provides an overview of the latest sign-ins (both interactive and non-interactive) and creation date for each enterprise application object. In a Zero Trust strategy, unused resources should be cleaned up to reduce the attack surface. Identifying stale applications allows administrators to confidently remove or disable apps without the guesswork.
Orphaned App registrations: Apps that have had an Enterprise Application deleted without the app registration being deleted too, introduce a misconfiguration which makes it hard to identify legitimate apps and usage.
Creation dates and sign-in activity: ENow’s information, which is surfaced for apps in all reports, clearly shows creation information along with activity.
To summarize, here are the steps I would take to remove an app from Entra (after completing your inventory and assessing data points):
This process is 30-45 Days all up.
Additionally, take a look at this list of Entra ID application governance best practices.
The scream test can be tempting, but with solid data, you rarely need to rely on it. Tools like the ENow App Governance Accelerator give admins the insights they need to clean up safely and confidently. The scream Gareth received serves as a reminder of what can go wrong, but in your Entra ID environment, having the right data ensures you can avoid those heart-stopping mistakes.
Instead of relying on scream tests or incomplete Entra ID logs, use ENow App Governance Accelerator to surface stale apps, orphaned registrations, and detailed sign-in history up to 180 days. Request a demo today to see how you can reduce risk while simplifying application governance.