Share
Report
46Microsoft Entra ID — App registrations / Certificates & secrets
Environment: Azure Function App (isolated worker, .NET) calling Business Central API via client_credentials OAuth flow.
What I'm trying to do
I have a background service (Azure Function) that authenticates to an app registration using a client secret (client_credentials grant) to call Business Central's API on a scheduled/event-driven basis — no interactive user involved. When I go to Certificates & secrets → New client secret, the maximum expiry I can select is 24 months.
My questions
Is the 24-month cap a hard platform limit for all tenants, or is it something that can vary based on tenant/Conditional Access/Security Defaults policy? If it's policy-driven, where would an admin go to check or adjust that?
Is there any way to extend an existing secret's expiry once it's created, or is creating a new secret (with a new value) always required? (My understanding so far is: no, expiry is locked in at creation — just confirming.)
For a long-running, non-interactive service like this, is a certificate credential meaningfully better than a client secret in terms of allowed lifetime, or does it face the same practical cap?
Is workload identity federation (federated credentials) a realistic option outside of CI/CD platforms like GitHub Actions/Azure DevOps? Most examples I've found are CI/CD-focused — has anyone used it for a standalone backend service like an Azure Function?
For anyone running a similar unattended service in production: what's your actual rotation process/cadence? Calendar reminder + manual rotation, an internal tool, Key Vault-based automation, something else?
What I already know / have in place
Secrets expire and are not renewable in place — I already treat this as "create new, migrate config, delete old."
I'm aware Entra sends expiry-warning emails to app owners.
I already store secret values outside source control (using dotnet user-secrets locally, and Azure App Settings for the deployed app) rather than hardcoding them in source.
Mainly looking for clarity on whether 24 months is truly fixed platform-wide, and what the realistic best-practice alternative looks like for a small, single-tenant background service (not a large enterprise CI/CD pipeline). Any pointers to official docs on this specific point would also be appreciated — most docs I've found describe how to rotate, not why the ceiling exists or whether it's adjustable.
Thanks in advance!
All responses (
Answers (
