What this check looks at
Checks the tenant’s default app management policy: adding passwords (client secrets) to applications should be blocked, or failing that limited to 180 days.
Applications registered in Entra ID authenticate as themselves with a credential: a client secret (a password generated by Entra ID), a certificate, or, for apps running in Azure, a managed identity with no credential to look after. The tenant’s default app management policy can restrict these credentials: it can block new client secrets altogether, or cap their lifetime. By default the policy is off, so secrets can be created with long lifetimes.
The check passes when adding client secrets to applications is blocked. It warns when secrets are allowed but limited to 181 days or less, because the CISA baseline asks for them to be blocked where possible, and fails when the policy is off or sets no lifetime limit of that length.
Client secrets end up in scripts, configuration files, wiki pages and chat messages, and whoever finds one can act as the application with every permission it holds, often including reading all mail or files. An app does not do MFA and its sign-ins are rarely watched. Certificates and managed identities are much harder to leak and misuse.
Why it matters
Client secrets end up in scripts, configuration files and chat messages, and whoever finds one can act as the application. Blocking them pushes teams to certificates and managed identities; a short lifetime at least limits how long a leaked one works.
A script containing a client secret is pasted into a support forum, or committed to a public code repository. The app it belongs to has permission to read every mailbox. An attacker who finds it reads the organisation’s mail through Microsoft Graph without signing in as anyone, and nothing appears in the user sign-in logs.
In MSP-managed tenants, third-party tools for backup, reporting and security often create app registrations with secrets. Blocking new secrets forces a decision about each one and moves the tenant towards certificates, which is the point; where a vendor cannot support certificates, a custom app management policy can exempt that one app.
The CISA SCuBA baseline (MS.AAD.5.5v1 and MS.AAD.5.6v1) asks for client secrets on applications to be blocked or tightly restricted, and the rule maps to NIST CSF 2.0 PR.AA-01. App management policies need a Microsoft Entra Workload ID Premium licence.
How to fix it
Where: Entra admin centre → Enterprise apps → Security → Application policies
Before you start
- Needs Workload ID Premium for app management policies. List apps that use client secrets today (App registrations, Certificates & secrets) and plan their move to certificates or managed identities.
- The policy applies to new secrets; existing ones keep working until they expire.
Step by step
- List the apps that use client secrets. In Microsoft Graph PowerShell (Connect-MgGraph -Scopes Application.Read.All), run Get-MgApplication -All -Property DisplayName,AppId,PasswordCredentials | Where-Object { $_.PasswordCredentials.Count -gt 0 } | Select-Object DisplayName, AppId. For each app, find out who owns it and what uses the secret.
- Move apps to certificates or managed identities. For apps the client or MSP controls, upload a certificate under Entra ID > App registrations > the app > Certificates & secrets, change the script or service to use it, then delete the secret. For third-party tools, ask the vendor for certificate support. Moving each app is separate work, not counted in this estimate.
- Cap secret lifetimes as a first step. In Microsoft Graph PowerShell (Connect-MgGraph -Scopes Policy.ReadWrite.ApplicationConfiguration), read the current policy with Get-MgPolicyDefaultAppManagementPolicy. Then call Update-MgPolicyDefaultAppManagementPolicy -BodyParameter with isEnabled set to true and an applicationRestrictions.passwordCredentials entry of restrictionType passwordLifetime, maxLifetime P180D and restrictForAppsCreatedAfterDateTime set to a past date so existing apps are covered. Include any existing keyCredentials restrictions in the same body, because each list is replaced as a whole.
- Block new secrets once apps have moved. When the apps that need secrets have moved, add a passwordCredentials entry of restrictionType passwordAddition (again with restrictForAppsCreatedAfterDateTime in the past) in the same way. Where the admin centre shows Application policies under Enterprise apps, the same options are there. Existing secrets keep working until they expire.
- Exempt a single app only where you must. If a vendor cannot support certificates, create a custom app management policy that allows secrets (New-MgPolicyAppManagementPolicy) and assign it to that one application (a POST to applications/{id}/appManagementPolicies/$ref in Microsoft Graph), so the tenant default still applies to everything else. Record the exception and review it yearly.
- Confirm. Run Get-MgPolicyDefaultAppManagementPolicy and check isEnabled is True with a passwordAddition restriction (or, for now, a passwordLifetime of 180 days). Adding a client secret to a test app registration should be refused. Re-run the assessment: it passes when secrets are blocked and warns while they are only time-limited.
What users will notice
None for users. Developers can no longer add client secrets (or only short-lived ones) to app registrations.
How to confirm it worked
Entra admin centre, Enterprise apps, Security, Application policies: "Block password addition" is on, or the maximum password lifetime is 180 days or less.
Frameworks and controls
This check maps to controls in 14 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | B2.d Identity and access management (IdAM) |
| DSPT | Standard 10: Accountable suppliers |
| NIS2 | Art. 21(2)(i) Access control and asset management |
| Microsoft Cloud Security Benchmark | IM-3 Manage application identities securely and automaticallyIM-8 Restrict the exposure of credentials and secrets |
| Zero Trust | Applications |
| SOC 2 | CC6.1 Logical access security software, infrastructure and architectures |
| PCI DSS 4.0.1 | 8.6.3 Passwords for application and system accounts are protected |
| NIST SP 800-171 | 3.5.2 Authenticate users, processes and devices |
| CMMC Level 2 | IA.L2-3.5.2 Authentication |
| ISO 27001:2022 | A.5.17 Authentication informationA.5.15 Access control |
| CISA SCuBA | MS.AAD.5.5v1 Adding passwords (client secrets) to applications blockedMS.AAD.5.6v1 Application password lifetime of 180 days or less |
| CIS Controls v8.1 | 5.5 Establish and maintain an inventory of service accounts (IG2) |
| NIST CSF 2.0 | PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization |
| NCSC 10 Steps | Identity and access managementSupply chain security |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- App management policies (Microsoft Learn)