Entra client secrets can have relatively short expiration periods, and I'm not aware of an automatic rollover mechanism comparable to certificate rotation. What is the recommended way to monitor, refresh, and safely rotate these secrets before they expire?
4 Answers
The preferred approach is to avoid client secrets whenever possible. Use managed identities for workloads running on Azure, or workload identity federation for platforms such as CI/CD systems and other OIDC-capable services. If a secret is unavoidable, automate rotation and alert application owners well before the expiration date.
Treat credential management as both a monitoring and rotation problem. A scheduled PowerShell script or Automation runbook can use Microsoft Graph to find passwords and certificates expiring within a chosen window, such as 60 days, and notify the assigned application owners. Make sure every app registration has a responsible owner and keep credential values in Key Vault instead of application configuration.
Automate the process with an Azure Automation runbook or an on-premises DevOps agent. A dedicated Entra application can use the required permissions to create a replacement secret, while the new value is stored in Azure Key Vault. You can also query applications to find credentials that are approaching expiration.
When federation or managed identity is not possible, certificates are generally preferable to client secrets because you can stage the replacement in advance. Add the new credential, deploy and verify it, then remove the old one. Do not wait until expiration and perform a direct swap, since that can cause an outage. Keeping credentials valid for many years only delays the problem and increases the impact if one is compromised.
How do managed identities or federated credentials apply to applications that were developed in-house and need to authenticate users? I thought those scenarios still required an app registration.