Deactivating an Entra ID Application

Deactivate Applications to Halt Access to Resources

Microsoft Entra ID documentation includes a page titled “Deactivate an enterprise application,” which explains that deactivating an application stops it being used because Entra ID will not issue access tokens to the application while it is deactivated, meaning that users cannot sign into the application and the application cannot be used to access protected resources (data) using its assigned permissions. Existing access tokens issued by Entra ID to the application continue to be valid until they expire (usually within an hour). The big plus point is that unlike the more radical deletion option, deactivation keeps application properties, roles, and permissions in place in a state that is easily reactivated to put the application back into use.

Applications are activated by default. Only an administrator or application owner can deactivate an application. If they’re signed into a Microsoft Graph PowerShell SDK interactive session, the delegated Application.ReadWrite.All permission must be available.

Microsoft says that deactivation is useful for security investigations, perhaps when a suspicious or unknown application is discovered during a periodic review of the app inventory or after a review of service principal sign-in activity. In these circumstances, it’s good to temporarily deactivate the application while everything is checked out.

Enterprise Applications and App Registrations

Microsoft’s use of the term “enterprise application” is loose and a tad misleading. Many enterprise applications, such as the first-party applications used by Microsoft 365 and the Microsoft Graph, or the Microsoft Graph PowerShell Tools application used for Microsoft Graph PowerShell SDK interactive sessions cannot be deactivated for a very simple reason: the ownership of these applications is tied to the Microsoft tenant, not yours. Deactivation is only possible if done in the tenant that owns an application.

In practical terms, this means that you can deactivate applications created in your tenant (often called app registrations), including applications designed for multi-tenant use because you have write access to those applications.

The isDisabled Property

The key to deactivate applications is to set the isDisabled property for applications to true. Today, this must be done through PowerShell because the Entra admin center doesn’t currently have an option to deactivate an application. Access to the isDisabled property is only available through the beta version of the Graph application endpoint.

When deactivating an application, I recommend that you update the application display name and notes to make sure that other administrators know about the application’s new status. This code creates a hash table containing the body for the Graph request and posts the request using the Update-MgApplication cmdlet:

# Create the request body
$NewDisplayName = $ApplicationObject.displayName + " (disabled)"
$NewNotes = ($ApplicationObject.notes.trim()) + "`nApp disabled on " + (Get-Date -format "dd-MMM-yyyy HH:mm") + " by " + (Get-MgContext).account

$RequestBody = @{}
$RequestBody.Add("isDisabled", $true)
$RequestBody.Add("displayName", $NewDisplayName)
$RequestBody.Add("notes", $NewNotes)

# Update the application
Update-MgApplication -ApplicationId $ApplicationObject.Id -BodyParameter $RequestBody

Assuming a successful request, the Entra admin center highlights the application’s deactivated status (Figure 1).

Attempts to sign into the deactivated application generate AADSTS7000112 (“application is disabled”) errors.

Reactivating an application is easily done by adjusting the content of the request body to reset the isDisabled property. This code also adjusts the display name and updates the application notes to record the reactivation:

$NewDisplayName = $ApplicationObject.displayName.split("(")[0]
$NewNotes = ($ApplicationObject.notes.trim()) + "`nApp reactivated on " + (Get-Date -format "dd-MMM-yyyy HH:mm") + " by " + (Get-MgContext).account

$RequestBody = @{}
$RequestBody.Add("isDisabled", $false)
$RequestBody.Add("displayName", $NewDisplayName)
$RequestBody.Add("notes", $NewNotes)

Update-MgApplication -ApplicationId $ApplicationObject.Id -BodyParameter $RequestBody

Remove App Owners

The documentation suggests that you remove application owners before deactivation to make sure that only administrators can reactivate the application. This advice is contrary to the assertion that deactivation is good because it preserves application data. However, let’s not argue and go ahead with some code to remove application owners (if present):

# Remove application owners
[array]$Owners = Get-MgApplicationOwner -ApplicationId $ApplicationObject.Id -All 
ForEach ($Owner in $Owners) {
    Try {
        Remove-MgApplicationOwnerDirectoryObjectByRef -ApplicationId $ApplicationObject.Id -DirectoryObjectId $Owner.Id
        Write-Host ("Removed owner {0} from application..." -f $Owner.DisplayName)
    } Catch {
        Write-Host ("Failed to remove owner {0} from application. Error details:" -f $Owner.DisplayName)
        Write-Host $_.Exception.Message
    }
} 

Remember to add the application owners back when you reactivate the application.

You can download a working script containing the code described above and other steps (like error checking) from the Office 365 for IT Pros GitHub repository.

Deactivate Applications is a Step Toward Full Application Lifecycle

Application deactivation is now the go-to method to put an application into an inactive state. It’s another small but welcome step along the path to full lifecycle management for Entra ID applications.

---

Need help to write and manage PowerShell scripts for Microsoft 365, including Azure Automation runbooks? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.