Information
In Microsoft Entra ID, applications and service principals can authenticate using password credentials (also referred to as client secrets). This setting enforces a tenant-wide maximum lifetime for new password credentials added to any application registration or service principal. When enabled, any client secret created must have an expiration date that falls within the configured maximum, which for this recommendation is 180 days or less. The policy is implemented through the default app management policy and applies to all applications unless scoped exceptions are configured.
The setting does not retroactively shorten or invalidate existing password credentials; secrets created before the policy was enabled remain valid until they expire or are explicitly removed.
The recommended state is Restrict max password lifetime set to On : 180 days or less.
Long-lived client secrets extend the window of exploitation if a credential is compromised. A secret valid for multiple years that is never rotated remains usable even if it was leaked in source code, a build log, or a security breach long after the initial exposure. Enforcing a maximum lifetime of 180 days ensures that client secrets expire on a regular basis, limiting the period during which a stolen credential remains valid and reducing the blast radius of a compromise. This control also encourages teams to establish automated rotation practices, which further reduces reliance on static, long-lived credentials.
Solution
To remediate using the UI:
- Navigate to Microsoft Entra admin center https://entra.microsoft.com/.
- Expand Entra ID and select Enterprise apps.
- Under Security select Application policies.
- Select Restrict max password lifetime.
- Set Status to On.
- Set the maximum lifetime to 180 days or less.
- Set Applies to to one of the following:
- All applications
- All applications with exclusions (if using exclusions, ensure they are reviewed annually).
- Set Only apply to apps created after to a desired date or leave it unconfigured.
- Select Save and close to apply the changes.
To remediate using the Microsoft Graph API:
Important: The PATCH request replaces the passwordCredentials array in full. Retrieve the current policy first and include all existing entries in the request body to avoid overwriting other configured restrictions or exclusions.
- Execute a GET request to retrieve the current policy:
v1.0/policies/defaultAppManagementPolicy
- Modify the returned JSON to reflect the following changes:
- Set isEnabled to true.
- Under applicationRestrictions.passwordCredentials, locate the entry where restrictionType is passwordLifetime and set the following:
- state to enabled
- maxLifetime to P180D or a shorter duration.
- restrictForAppsCreatedAfterDateTime to 0001-01-01T00:00:00Z or a desired date.
- Under servicePrincipalRestrictions.passwordCredentials, locate the entry where restrictionType is passwordLifetime and set the following:
- state to enabled
- maxLifetime to P180D or a shorter duration.
- restrictForAppsCreatedAfterDateTime to 0001-01-01T00:00:00Z or a desired date.
- Execute a PATCH request to the same URI with the modified JSON in the request body to apply the changes.
Note: The References section includes a link to the API documentation with full remediation examples in multiple languages including HTTP, PowerShell, and Python.
Impact:
Any automated process, pipeline, or script that creates client secrets with a lifetime exceeding the configured maximum will fail once the policy is enabled, unless an exception is configured. Organizations will need to update secret creation workflows to specify expiration dates within the allowed range and establish rotation processes for secrets approaching expiry.