Microsoft Entra ID App Governance: How to Clean Up Apps Without the Chaos

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.

Why the Entra ID Application Cleanup Process Matters

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.

What is the 'Scream Test' in Entra ID App Governance?

Why Admins Rely on It

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.

The Risks of the Scream Test

Administrators under pressure have taken several approaches:

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.

The Business Impact of the Scream Test

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.

App Registrations vs. Enterprise Applications in Entra ID

Enterprise Apps and App Registrations in Entra ID offer different options, but they’re not always obvious.

How App Registrations Work

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.

What Service Principals Do

The service principal is the app’s identity in a specific tenant and is what actually lets it sign in and use resources.

Single-Tenant vs. Multi-Tenant Apps

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.

Disable vs. Delete in Entra ID

App Registrations

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

Enterprise Applications

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!

Figure 3: "Disabling" an Enterprise application

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.

Limitations of the Entra ID Recycle Bin

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

• • In some cases, the Enterprise application doesn’t have a corresponding app registration in your tenant because it is a third-party application, and the app registration is in the third party’s home tenant; the Enterprise application is merely a representation of that app in your tenant as a service principal. So, if you delete the Enterprise application of a third-party application, you will not have the 30-day recycle bin in app registrations option to restore that service principal. Refer to viewing Deleted Service Principals using PowerShell.

      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

Common Pitfalls in Entra ID Application Cleanup

• Orphaned app registrations
• Misleading recycle bin behavior
• Lost conditional access policies
• Third-party app limitations

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.

Data-Driven Application Governance

Tired of the scream test?
Get visibility into stale and orphaned applications with ENow App Governance Accelerator.
👉 Request a demo today

Why Data Beats the Scream Test

This is where proper data becomes your shield. Instead of relying solely on the scream test, gather actionable insights to substantiate cleanup decisions.

What to Check Before Deleting an App

• Last activity date: When was the app last used? 
• User count: How many people or teams are actively using it? 
• Access scope: What resources does this app have permissions to? 
• Dependencies: Are there workflows or automations tied to this app? 
• Created date: A recently created app might not yet have many users, and if the CEO recently created it and you delete it, that could be problematic. 

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. 

Using ENow App Governance Accelerator

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.

Figure 8: App Registration without Associated Enterprise Applications (Orphaned App Registrations)

• • • Creation dates and sign-in activity: ENow’s information, which is surfaced for apps in all reports, clearly shows creation information along with activity.

       

      Figure 9: App Governance Accelerator shows the created date along with sign-in activity.

  • • Sign-in logs collected: Sign-in Activity data is collected and stored from the first day the Application Governance Accelerator is enabled, giving you up to 180 days of sign-in activity.

           Figure 10: Sign-in activity up to 180 days.

Entra ID Application Cleanup Best Practices (Step-by-Step)

To summarize, here are the steps I would take to remove an app from Entra (after completing your inventory and assessing data points):

1. Backup existing config and policies
2. Disable first, allow 15 days
3. Soft-Delete with option to restore from the recycle bin
4. Permanently delete the App registration after another 15 days
5. Manually delete the Service Principal; otherwise, it will be permanently deleted 30 days after the application is deleted.

This process is 30-45 Days all up.

Additionally, take a look at this list of Entra ID application governance best practices. 

Avoid the Scream Test with Data-First Governance

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.

 

Request a Demo of ENow App Governance Accelerator