Clarification on Maximum Allowed Client Secrets for App Registrations & Service Principals

Hello cloudteam

Thank you for reaching out to Microsoft Q&A. Below are the mentioned steps: -

1. Maximum number of client secrets

App registration (application object)

1. If the app supports personal Microsoft accounts (signInAudience = AzureADandPersonalMicrosoftAccount, typical of Azure AD B2C “Accounts in any identity provider…”): Max = 2 client secrets. Attempts to add a third secret return errors such as TooManyAppPasswords or “credential limit has been reached.”
2. If the app supports only work/school accounts (AzureADMyOrg single-tenant or AzureADMultipleOrgs multitenant): Microsoft doesn’t publish a small fixed “N” like 2; the limit is governed by the app object’s overall collections and service constraints. Practically, you can maintain more than two secrets, but you should avoid high counts due to security and service limits.

Service principal (enterprise application)

The service principal uses the same password credential model as the application. You can add secrets via Graph (e.g., addPassword for service principals). The per‑object practical limit mirrors the app registration rules above—B2C/personal-account scenarios enforce max 2; otherwise, higher counts are possible but discouraged.

For your reference: https://dori-uw-1.kuma-moon.com/en-us/powershell/module/microsoft.graph.applications/add-mgserviceprincipalpassword?view=graph-powershell-1.0

Note: If you see “Unable to save changes because the credential limit has been reached,” check the app’s Supported account types (manifest signInAudience). If it’s set to AzureADandPersonalMicrosoftAccount, you’re hitting the 2‑secret ceiling

2.) Expiration and lifetime defaults

1. When creating a secret via Microsoft Graph (application: addPassword), default expiry = startDateTime + 2 years unless you specify endDateTime. This reflects the portal’s max 24 months UI option.
2. You can set custom lifetimes programmatically (PowerShell/CLI). Some blogs show longer lifetimes via CLI; however, Microsoft’s security guidance strongly recommends routine rotation and avoiding long‑lived secrets. Prefer certificates or federated credentials/managed identity for production.

For your reference: https://dori-uw-1.kuma-moon.com/en-us/graph/api/application-addpassword?view=graph-rest-1.0&tabs=http

3.) Tenant‑wide policies and limiting factors

1. Application management policies (Graph: defaultAppManagementPolicy and per‑app appManagementPolicies) let you enforce secret restrictions (e.g., maximum password lifetime) tenant‑wide or scoped to a specific app/service principal. These policies override portal defaults and require appropriate Graph permissions (e.g., Policy.ReadWrite.ApplicationConfiguration).
2. Throttling & service limits: General Entra service limits and throttling apply to Graph APIs for adding/reading credentials; avoid creating “hundreds” of secrets as this can hit service constraints and is a poor security practice.

4.) Below is the resolution: -

1. Confirm your app’s audience (root cause of “only 2 secrets”)
   • In the Entra admin center → App registrations → [App] → Manifest, check signInAudience.
   • If it’s AzureADandPersonalMicrosoftAccount (typical in B2C), you’re limited to 2 secrets. Consider switching to work/school-only where appropriate (not for B2C end‑user flows) or use certificates/federated credentials instead of piling secrets.
2. Use Microsoft Graph to add/rotate secrets with explicit lifetimes
   • Graph REST: application: addPassword (default 2‑year expiry). [dori-uw-1.kuma-moon.com]
   • PowerShell: Add‑MgApplicationPassword and Add‑MgServicePrincipalPassword.
3. Enforce organization‑wide secret standards
   • Configure Application management policies to cap lifetimes (e.g., max 12 months) or to disable client secrets in favor of certificates/federated credentials.
   For your reference: https://f12.hu/2023/06/18/fighting-azuread-app-registration-client-secrets-step2-limiting-app-password-lifetime/
   • Microsoft guidance: Use managed identities or federated credentials where possible; secrets are considered less secure and harder to manage at scale. See Security best practices for app registration.

For your reference: https://dori-uw-1.kuma-moon.com/en-us/entra/identity-platform/security-best-practices-for-app-registration

Please let us know the above steps help

Thanks