Remove EIDGuard

To remove EIDGuard, you delete the resource group you deployed it into. Because recovery points are protected by a locked immutability policy, and some objects EIDGuard creates live outside the resource group, removal takes a few steps before and after that deletion.

What removing involves#

Before you begin#

You need:

• The Admin role in the dashboard, to export and to offboard tenants.
• Permission to delete the resource group, and to assign roles on the data storage account (Owner, or User Access Administrator plus Contributor).
• In the workforce tenant, permission to delete the app registration (an owner of the app, or a role such as Cloud Application Administrator).
• The Azure CLI in a Bash shell, for example Azure Cloud Shell.

Then, in this order:

1. Export the recovery points you want to keep. Configuration > Export > Export recovery points copies every recovery point, report and manifest for all tenants to a storage account you own. See Export recovery points.
2. Offboard every tenant. On Tenants, select Offboard… on each tenant's row. Offboarding deletes the backup and restore app registrations EIDGuard created in that External ID tenant, disables the tenant's certificates and stops new recovery points. Deleting the resource group cannot reach those applications, and the restore application holds write permissions in your directory, so do not leave it behind. See Offboard a tenant.
3. Wait until the newest recovery point is older than its immutable window. Until then, Azure refuses to delete it, for anyone, including a subscription Owner. The window is shown under Configuration > Protection > Deletion protection. To check a recovery point, open it from Recovery points: its Deletion protection field shows Window ended once its files are past the window. Reports added later by a comparison or a restore keep their own window from when they were written. An Admin can raise the window but nobody can lower it, so every raise lengthens this wait. See Protect recovery points from deletion.

Empty the backups container#

Azure does not delete a storage account while its immutability-enabled backups container holds any blob or blob version, even one whose window has ended. If you delete the resource group first, the deletion fails on the data storage account with AccountProtectedFromDeletion ("The container(s) backups have object level immutability enabled.") and leaves the resource group behind with the account in it. Empty the container first.

The data storage account is the one named in the deployment output storageAccountName, which holds the backups container, not the storage account the Function App uses for its own state.

1. If the deployment uses private networking, the data storage account refuses public network access. Enable public network access on it for this procedure, or run the commands from a machine inside the virtual network.

2. Assign yourself Storage Blob Data Owner on the data storage account. Storage Blob Data Contributor is not enough: it deletes the current blobs but is refused on their previous versions with OperationNotAllowedOnAutomaticSnapshot.

   acct=<data storage account>
   az role assignment create --role "Storage Blob Data Owner" --assignee <your sign-in name> \
     --scope "$(az storage account show -n $acct --query id -o tsv)"
   

3. Wait a minute or two for the role assignment to take effect.

4. Delete every blob and blob version in the container. Deleting a current blob leaves its previous version behind, so one pass is not enough:

   az storage blob list --account-name $acct --container-name backups --include v \
     --auth-mode login --query "[].[name,versionId]" -o tsv |
     while IFS=$'\t' read -r name ver; do
       az storage blob delete --account-name $acct --container-name backups --name "$name" \
         ${ver:+--version-id "$ver"} --auth-mode login >/dev/null
     done
   

5. Count what is left:

   az storage blob list --account-name $acct --container-name backups --include v --auth-mode login -o tsv | wc -l
   

   Repeat steps 4 and 5 until the count is 0. A version whose immutable window has not ended is refused with an HTTP 409. That is the protection working: come back when its window has ended.

Delete the resource group#

1. In the Azure portal, open the resource group and select Delete resource group, or run:

   az group delete --name <resource-group>
   

2. If the deletion fails with AccountProtectedFromDeletion, the backups container is not empty yet. Finish emptying it and delete the resource group again. See Deleting the resource group fails with AccountProtectedFromDeletion.

Remove what is left behind#

The dashboard sign-in app#

Setup created the app registration EIDGuard-WebUI (<web app name>) in the workforce tenant that holds the subscription, where <web app name> is the deployment's Function App name. Deleting the resource group does not remove it. In the Microsoft Entra admin center for the workforce tenant, open App registrations, select the app and select Delete. Microsoft Entra ID keeps a deleted app registration restorable for 30 days.

Setup also created enterprise applications (service principals) in the workforce tenant for Vambris's setup sign-in application and its licensing application. If no other EIDGuard deployment uses the tenant, you can delete them under Enterprise applications.

Enterprise applications in your External ID tenants#

Offboarding does not delete the enterprise application EIDGuard-WebUI (<web app name>) that an administrator of each External ID tenant consented to during onboarding, or its consented permissions. In each External ID tenant you onboarded, open Enterprise applications, select it and delete it.

Custom role definitions#

The deployment creates five custom role definitions in the subscription. Deleting the resource group normally removes them, but Azure can keep listing them for a while afterwards. If one is still listed a day later, follow Custom role definitions left behind after a teardown.

The soft-deleted Key Vault#

Deleting the resource group soft-deletes the Key Vault. Purge protection means nobody can purge it early; Azure purges it automatically 90 days after deletion. Once every tenant is offboarded, the certificates in it no longer belong to any application. Until the purge, the vault's name stays reserved, so deploying EIDGuard again with the same Resource name prefix into a resource group with the same name can collide with it. See Deployment fails because the Key Vault name is already in use.

Role assignments you made outside the resource group#

If you granted the Automation account's managed identity access to resources outside the resource group, such as Storage Blob Data Contributor on an export destination or Network Contributor on your own virtual network, those assignments remain and now refer to an identity that no longer exists. Remove them under each resource's Access control (IAM) > Role assignments.

Subnets in your own virtual network#

If you enabled private networking with a virtual network you already had, deleting the resource group removes the private endpoints, DNS zones, NAT gateway and worker VM, but the three subnets stay in your network: snet-eidb-pe, snet-eidb-hw and snet-eidb-app (unless their names were changed). So do the app subnet's delegation to Microsoft.Web/serverFarms, the private-endpoint subnet's disabled network policies, and any association with EIDGuard's NAT gateway.

A subnet that already had one of these names may have been reused rather than created, so check before deleting:

1. Confirm each subnet is one EIDGuard created: nothing else is attached to it, and it is not one you had before the deployment.
2. Remove a NAT gateway association only where it referred to EIDGuard's eidb-natgw. Leave your own NAT gateway in place.
3. Remove the Microsoft.Web/serverFarms delegation from the app subnet; a delegated subnet cannot be deleted.
4. Delete only the subnets you confirmed in step 1.

If in doubt, leave the subnet. An empty subnet costs nothing.

Activity Log routing you added#

If you routed the Activity Log to a workspace as described in Monitoring and alerts, that diagnostic setting is at subscription scope and remains. If nothing else uses it, remove it:

az monitor diagnostic-settings subscription delete --name eidb-activity

Also delete any alert rules you created outside the resource group.

Verify#

• az group exists --name <resource-group> returns false.
• In each External ID tenant, App registrations no longer lists EIDGuard-Backup-ReadOnly or EIDGuard-Restore-ReadWrite.
• In the workforce tenant, App registrations no longer lists EIDGuard-WebUI (<web app name>).
• A day after the deletion, the role definition list in Custom role definitions left behind after a teardown shows no definitions with the deployment's suffix.
• az keyvault list-deleted -o table lists the deployment's vault with its scheduled purge date. That is expected until the purge.

Related pages#

• Manage protected tenants
• Export recovery points
• Protect recovery points from deletion
• Troubleshooting