Enterprise Application

The PowerShell syntax used to create a new client secret on the service principal is correct for renewing a client secret on a Microsoft Entra application/service principal:

$appId = "b1d4c2f8-6e39-4c12-a7a2-5f83d2e4c901"  # Enterprise App's AppId
$displayName = "EApp-sec"
$yearsValid  = 1

Connect-MgGraph -Scopes "Application.ReadWrite.All"

$sp = Get-MgServicePrincipal -Filter "appId eq '$appId'" -ErrorAction Stop
$cred = @{
    DisplayName   = $displayName
    StartDateTime = (Get-Date)
    EndDateTime   = (Get-Date).AddYears($yearsValid)
}
$newSecret = Add-MgServicePrincipalPassword -ServicePrincipalId $sp.Id -PasswordCredential $cred
$newSecret.SecretText

This is the same pattern used in the documented scenario for renewing secrets on ACS service principals (older-style principals), where a new password credential is added to the principal and the SecretText is returned and must be copied and used by the application.

If the application still fails after updating the secret, typical causes (based on the documented flows) are:

1. The wrong object was updated
   • For some integrations, the secret must be renewed on the application registration (App registration) rather than directly on a service principal created elsewhere (for example, some Azure DevOps-created service principals must be updated from Azure DevOps instead of directly in Entra, as documented for Azure DevOps service connections).
   • Verify that the appId used is the one the application actually uses and that the correct principal/registration is being updated.
2. Propagation delay
   • For some SharePoint/ACS scenarios, there is an explicit propagation delay requirement (up to 24 hours) before the new secret is honored. If the enterprise app is used in a similar way, there may be a short delay before the new secret works.
3. Secret value vs. ID confusion
   • Ensure the application owner is using the secret value (SecretText) as the client secret, not the credential ID or some other field.
4. Lifetime and policy restrictions
   • Application management policies can enforce restrictions on secrets and certificates (for example, blocking client secrets or enforcing rotation rules). If such a policy is in place, the new secret might be rejected or blocked at use time. These policies are managed via Microsoft Graph and can block client secrets entirely, as shown in the tutorial where client secrets are blocked by tenant-wide policy.

If the app is an API Management, SharePoint add-in, or other platform-generated application, also confirm whether the platform has its own secret-generation mechanism that must be used (for example, API Management “Applications” page or Azure DevOps service connections) instead of directly manipulating the Entra service principal.

Difference between Enterprise Applications and Managed Identities (at a high level, based on context):

• Enterprise Application (service principal):
  • A representation of an application in a specific tenant (service principal) that can have credentials (secrets or certificates) added and managed in Microsoft Entra ID.
  • Secrets are created and managed explicitly (for example, via Certificates & secrets in App registrations or via Microsoft Graph PowerShell Add-MgServicePrincipalPassword).
  • Subject to application management policies that can enforce how secrets/certificates are used and rotated.
• Managed Identity:
  • Not detailed in the provided context, but in contrast to the above, managed identities are typically used to avoid managing secrets directly; the platform handles credential rotation and token issuance automatically.

To move away from client secrets in production, the documentation recommends using certificates or federated credentials instead of client secrets for higher security.

References:

• Replace an expiring client secret in a SharePoint Add-in
• Add and manage application credentials in Microsoft Entra ID
• Tutorial: Enforce secret and certificate standards using application management policies (ms-powershell)
• Client secret key is expired error occurs when deploying or terminating virtual machines
• Securely access products and APIs with Microsoft Entra applications