What is the difference between a disabled app and a deleted app in Microsoft 365?

Why This Matters for Security Teams

In Microsoft 365, the practical difference between disabled and deleted apps is not cosmetic. A disabled app can still persist as an identity object with configured permissions, metadata, and a path back into service if someone re-enables it later. That creates residual access risk, especially when the app was once connected to mail, SharePoint, Graph, or automation workflows. By contrast, deletion removes the object and reduces the chance that dormant access survives in the tenant.

This distinction matters because identity cleanup is part of attack surface reduction, not just housekeeping. The Ultimate Guide to NHIs — What are Non-Human Identities notes that 97% of NHIs carry excessive privileges, which is why stale application objects deserve the same scrutiny as active service principals. Microsoft 365 administrators also need to remember that app state does not always match business intent: an app can look inactive while still retaining consent grants, delegated permissions, or admin-approved scopes. Current guidance suggests treating disabled apps as temporary holds, not as a final offboarding state. In practice, many security teams encounter lingering access only after an incident review, rather than through intentional lifecycle management.

How It Works in Practice

The operational difference comes down to object lifecycle. Disabling an app usually blocks interactive or functional use, but it does not necessarily remove the identity from the directory, revoke all consent, or erase configuration that could be reactivated later. Deletion is the more definitive step when the app has no remaining business purpose. That is closer to the offboarding pattern described in NIST Cybersecurity Framework 2.0, where identity lifecycle hygiene supports broader access control and recovery discipline.

For security teams, the right sequence is usually: confirm ownership, validate whether the app still supports a process, review permissions and secrets, and then choose between disable, revoke, or delete. If the app is retained, it should be documented, monitored, and tied to an accountable owner. If it is removed, make sure associated credentials, certificates, and service dependencies are also retired. The Microsoft Midnight Blizzard breach is a reminder that identity sprawl and weak lifecycle controls can become material exposure paths, even when the original object appears low risk.

• Disable when the app is temporarily unused but recovery is likely.
• Delete when the app no longer has a business owner or justified purpose.
• Revoke secrets and consent grants before or during removal.
• Verify the app is not embedded in automation, CI/CD, or scripts.

These controls tend to break down in large tenants with delegated admin sprawl, where no single team can prove whether the app is still in use.

Common Variations and Edge Cases

Tighter cleanup often increases operational overhead, requiring organisations to balance security gains against app recovery friction. That tradeoff is real when an app supports a brittle business process, a vendor integration, or a shadow IT workflow that no one fully owns. In those cases, a disabled state may be used as a short-term quarantine while the team confirms downstream impact. Best practice is evolving here, and there is no universal standard for how long a disabled app should remain before deletion.

Edge cases also matter when app registrations and service principals are managed separately. Deleting one object without understanding the other can create confusion during incident response or break automation unexpectedly. For high-value environments, current guidance suggests pairing app deletion with entitlement review, secret rotation, and logging review so that the removal is not only administrative but also forensic. The Microsoft Azure OpenAI service breach shows why unused or poorly governed identity objects can become part of a larger access chain when permissions are left in place longer than necessary.

Where this guidance breaks down most often is in multi-team tenants with unclear ownership, because nobody wants to delete an object that might still be embedded in production automation.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between human IAM controls and NHI governance?