App management policies in Entra ID block new client secrets

In real-world Microsoft Entra ID environments, I still find far too many service principals with client secrets that never expire. Usually they are leftovers from old scripts, line-of-business apps or projects nobody quite remembers. Even tenants with solid processes drift back into bad habits when there is no technical guardrail. This is where app management policies now help. They let you block the creation of password credentials centrally and enforce sensible validity periods for secrets and certificates, so app registration governance no longer depends on good intentions and is actually enforced.

App management policies turn governance rules into technical enforcement

Microsoft's app management policies close the gap between written policy and what actually happens in the tenant. You no longer have to rely on every admin or developer doing the right thing every time. Instead, you can make it technically impossible to create new secrets unless someone has explicitly granted an exception. For tenants that want to phase out outdated models and move to managed identities or certificate authentication, that matters a lot. You configure the policies via Microsoft Graph, not in the Entra portal. The details are in the official documentation and in the reference for the tenantAppManagementPolicy object in Graph.

A tenant default policy sets the baseline and per-app policies handle exceptions

App management policies come in two types. The tenant default policy applies globally, and per-app policies cover targeted exceptions. You start with the tenant default, which acts as a safety net. Once it is in place, nobody can create new secrets for any new or existing app unless you assign that app a more permissive policy. This setup works particularly well in environments that run a mix of modern and legacy apps. According to the current announcement, the rollout begins with an audit-like mode, so you can see which apps would be affected before anything is actually blocked.

The following Mermaid diagram shows how the evaluation runs whenever someone tries to add a new credential:

flowchart TD
    Start["App registration"] --> CheckPolicy["Check policy"]
    CheckPolicy -->|"Per-app exception?"| ExceptionPolicy["App policy"]
    ExceptionPolicy -->|"Allowed?"| AllowSecret["Secret/credential allowed"]
    ExceptionPolicy -->|"Not allowed"| BlockSecret["Secret/credential blocked"]
    CheckPolicy -->|"No exception"| DefaultPolicy["Tenant default policy"]
    DefaultPolicy -->|"Allowed?"| AllowSecret
    DefaultPolicy -->|"Not allowed"| BlockSecret

Figure: How app management policies control the creation of new credentials

Graph PowerShell configures the policies with Update-MgPolicyDefaultAppManagementPolicy

These policies are managed through Microsoft Graph only. The Entra portal has no UI for them (as of today). I use the Microsoft.Graph PowerShell module for this, and you need the Cloud Application Administrator role (or higher) as well as the Workload Identities Premium license. For tenant-wide blocking, the cmdlet you want is Update-MgPolicyDefaultAppManagementPolicy. Per-app exceptions are set with Update-MgPolicyAppManagementPolicy, where you specify the app's object ID. This example blocks secrets across the tenant and makes an exception for one legacy app:

# Block client secrets tenant-wide
Update-MgPolicyDefaultAppManagementPolicy -PasswordCredentialCreationBlocked $true
# Allow secrets for one app (by object ID)
Update-MgPolicyAppManagementPolicy -AppId 12345678-1234-1234-1234-123456789abc -PasswordCredentialCreationBlocked $false

Field tip: Always start in audit mode, keep an eye on the logs and talk to app owners early. You'll be surprised what breaks. Sometimes it's an integration nobody has updated in years.

If you haven't done so yet, take a complete inventory of your app registrations and their credential types before you change any policies. In my earlier post Unused apps in Entra ID: Safe cleanup and a real-world process I show how to audit your environment with Microsoft Graph PowerShell.

Exceptions and the rollout come with their own pitfalls

Not every legacy app can be modernized overnight, of course. Scoping exceptions to individual apps is essential, but document each one and review it regularly. Otherwise you have just moved the problem somewhere else. The audit-first rollout isn't a nice extra either. It is what brings hidden dependencies and integrations to light that would otherwise break quietly. Also remember to set sensible maximum lifetimes for certificates. The defaults are still too long for most environments, and shorter lifetimes push teams toward regular rotation.

I see app management policies as a real governance breakthrough

With app management policies, admins can finally enforce standards for app credentials at scale instead of just hoping people follow them. Blocking client secrets centrally and requiring a justification for every exception gives you real control, especially in larger tenants where shadow integrations used to be a nightmare. Process, communication and cleanup still matter, but this closes an important gap. If you introduce these policies with some care, your security improves, audits get easier, and as an Entra admin you will probably sleep a bit better.