Skip to main content

When discussing Azure App Registrations backup and recovery, one question that often comes up is, “How does Veeam handle secrets and certificates that are embedded within these registrations?”. It is a great question and I wanted to take the opportunity to double click on this.

Client Secrets:

Client secrets in App Registrations are treated similarly to passwords. Once a secret is created, its value is only displayed once and is never retrievable again. This behaviour is by design, enforced by Azure and Microsoft Graph to maintain strong security hygiene.

It is because of this that:

  • Veeam does not back up or restore the actual secret values as that data is not exposed by the Microsoft Graph API.
  • Veeam does capture metadata such as secret names, creation dates, expiration dates, and key identifiers.
  • The secret value itself must be stored securely elsewhere, such as in Azure Key Vault, at the time of creation.

If the secret is lost or needs to be restored, Veeam can restore the App Registration and its structure, but the secret itself must be manually or programmatically re-created and then securely re-associated with the application.


Certificates:
Much like secrets, certificates added to App Registrations are not stored in a retrievable format once uploaded.

Here’s how Veeam handles them:

  • Certificate metadata is backed up — including thumbprints, key identifiers, start/end dates, and usage.
  • The certificate file content (e.g., `.cer`, `.pfx`, `.pem`) is not backed up or restorable, as that data is not exposed by the Microsoft Graph API.
  • Certificates cannot be re-imported during a restore unless the original certificate is stored securely elsewhere (for example, Azure Key Vault).

In a restore scenario, Veeam can rehydrate the App Registration itself and alert you to re-add the required certificate. You’d then need to re-import the original certificate manually or via script.

To Summarize:
 

Component Protected by Veeam Secret / Certificate value Restored Recommended storage for component
Client Secret All Metadata No Store the key in secure storage for managing sensitive information - like Azure Key Vault
Certificate All Metadata No Store original certificate (.pfx, .cer) in secure storage for managing sensitive information - like Azure Key Vault

 

There is one important exception to the limitations above - if an App Registration is deleted but still within the Entra ID recycle bin, it can be fully restored, including:

  • Its client secrets (in usable form)
  • Its certificates (including private keys)

This is because Azure retains the entire object in a soft-deleted state for a limited period (typically 30 days). During this time, recovery restores the object exactly as it was — including secrets and certificates — without requiring re-entry.

Here is a screen shot from Veeam Backup and Replication along with Veeam Data Cloud for Entra ID showing the “Restore from Entra ID Recycle Bin” option:
 

Veeam Backup and Replication:

 

Veeam Data Cloud for Entra ID:


Veeam is designed to capture and protect critical identity configurations, including App Registrations, users, groups, and role assignments, etc. However, due to Azure platform limitations, sensitive material like secrets and certificates must be handled through complementary secure practices like Azure Key Vault or a credential manager.

If you're planning a restore or implementing disaster recovery for applications relying on app registrations, it’s essential to pair Veeam with a solid key and secret management strategy.

An interesting concept.  Thanks for the share as it was a great read.

 
 
 

Thanks for sharing. I had question about that. Now is answered :)


Comment