A team's Azure Function currently authenticates to Dataverse with an app registration whose client secret is stored in app settings and expires every six months, causing outages when rotation is missed. The function runs only in Azure. Which change best removes the rotation burden?

The outages come from a credential lifecycle the team must manage manually. A managed identity eliminates that lifecycle for Azure-hosted workloads: Azure issues and rotates the underlying credentials, the function requests tokens from the local identity endpoint, and no secret is stored in configuration or code. Dataverse treats the managed identity like any other service principal once an application user is created for its application ID and given a security role, so the function's existing Web API or SDK calls continue to work with a different credential source. Moving the secret into Key Vault improves storage and access control, but the secret still expires, and someone must still create a new one and update the vault before the old one lapses, so the rotation burden remains. Choosing the longest available expiry only stretches the interval between outages and increases the damage if the secret leaks. Certificates are stronger than shared secrets, yet they also expire and must be renewed, uploaded, and redeployed; storing one in app settings recreates the same operational problem. Exam caveat: managed identities apply only where the code runs on Azure compute; a workload outside Azure needs another option, such as workload identity federation or a certificate. Operational check: after cutover, delete the old client secret from the app registration and confirm the function still authenticates.