Every application registered in your Microsoft 365 tenant or connected via OAuth retains its permissions and credentials until explicitly removed. Dormant apps — those with no recent sign-in or API activity — represent access that nobody is actively managing, monitoring, or aware of.

Overe flags applications that have been idle above a defined threshold while still holding live permissions or credentials. The risk is not the app itself but what remains attached to it: broad Graph permissions, active client secrets, service principal role assignments, or user consent grants that could be exploited if the app is compromised or its credentials are leaked.

Dormant apps commonly result from completed projects, vendor trials, deprecated integrations, or tenant migrations. They are rarely removed intentionally and accumulate quietly over time.

• Attacker discovers a dormant app's client secret through a code repository, configuration file, or credential dump
• Client secret used to authenticate silently and access data the app was originally granted — mail, files, directory
• Permissions never revoked mean the attacker has active access despite the app being unused for years
• Service principal associated with a dormant app used to enumerate the tenant or escalate privileges if it holds a directory role
• Credentials re-issued by an attacker who gains access to the app registration directly in Entra
• Long-lived secrets that have never been rotated provide a persistent, low-visibility entry point

Some apps are intentionally inactive for periods of time — seasonal tools, backup utilities that only run periodically, or apps in development not yet in production use.

The distinction is intent and documentation. A genuinely inactive app with a named owner, a known purpose, and managed credentials is different from an orphaned app with no clear owner and permissions that nobody has reviewed in two years.

Apps with application-level permissions and no recent activity require a higher level of scrutiny than apps with only delegated permissions and no active user consent grants.

Before modifying or removing a dormant app:

• Check the app's last sign-in date and last API activity date — both can differ
• Identify who created the app and whether there is still a named owner
• Review the permissions the app holds and whether those permissions are still appropriate
• Check whether the app has active credentials — client secrets or certificates — and when they expire
• Confirm whether any active business process or automation depends on this app
• Check whether the app has a service principal with Entra role assignments
• Review Overe for any alerts or recent activity associated with the app or its service principal

1. Use Overe to review the full list of dormant apps, sorted by last activity and permission scope
2. For apps with no identifiable owner or business purpose, investigate before removing — deletion is hard to reverse
3. For confirmed dormant and unnecessary apps, revoke permissions and disable before deleting
4. For apps where ownership is unclear, attempt to contact the original creator or team before taking action
5. Revoke or expire any active client secrets on dormant apps even if the app itself is not yet removed
6. For apps that may be needed in future, document the exception with a review date and disable credentials until required
7. Establish a regular review cycle to catch dormant apps before they accumulate

Where direct remediation is required, Overe provides links to the appropriate Microsoft admin controls to complete the action safely.

Microsoft: Manage application registrations in Microsoft Entra ID - https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/manage-application-registrations-overview

Microsoft: Remove a registered application - https://learn.microsoft.com/en-us/entra/identity-platform/howto-remove-app

Microsoft: Application security best practices - https://learn.microsoft.com/en-us/entra/identity-platform/security-best-practices-for-app-registration

After reviewing dormant applications, also check these related risk areas:

• Apps with Risky Permissions — dormant apps that also hold broad Graph API permissions are a particularly high-risk combination; a forgotten app with Mail.ReadWrite access is a silent data exfiltration vector.
• Apps with Admin Roles — check whether any dormant apps hold Entra admin roles; a forgotten service principal with Global Admin is a critical backdoor.
• Dormant Users — dormant apps and dormant user accounts are often created together in the same project; review both as part of the same hygiene cycle.