Monitor Entra app secrets and certificates and renew them before expiration

How do you prevent an Entra application from failing due to an expired client secret or certificate? All app credentials must be inventoried with the application, deployment location, owner, and expiration date. Renewal happens before expiration in parallel operation: add the new credential, update the target system, validate the real sign-in, and only then remove the old credential.

A secret or certificate is not the application itself. It is proof that allows a workload to authenticate as a service principal. When this proof expires, the application no longer receives a token. Typical errors are invalid_client, invalid client credentials, or certificate errors.

Distinguish credential types

For new production workloads, a secret should remain the exception. If hosting and the vendor allow it, managed identity, workload identity federation, or certificates are more robust and easier to manage in operations. Client secrets remain more of a compatibility or transition mechanism.

Client secret

A symmetric secret value is used during the token request. It is easy to set up but risky during storage and distribution. The value is shown in the portal only at creation and must be stored securely.

Certificate

The application signs a client assertion with the private key; Entra recognizes the public certificate part. Microsoft recommends certificates over client secrets for production applications. The private key must be protected securely.

Federated identity credential

Workload Identity Federation allows certain external workloads to obtain a token based on a trust relationship without a stored secret. Typical scenarios include GitHub Actions, Kubernetes, or other supported platforms.

Managed identity

For supported Azure resources, a managed identity can reduce credential management. The platform manages the identity; the application does not need its own secret in the code.

The best method depends on the hosting and the application. A secret should not be used reflexively just because it is created quickly.

A complete credential register

For each application, at least the following are recorded:

• Display name and client ID,
• Application object and service principal,
• business and technical owner,
• target system or hosting location,
• credential type,
• key ID or certificate thumbprint,
• start and expiration date,
• storage location of the private material,
• rotation procedure,
• last successful use,
• advance notice periods,
• fallback contact.

The secret value or private key does not belong in the registry. It only points to a secure secrets store.

Where credentials can be located

Besides Certificates & secrets of an App Registration, credentials can also appear on Service Principals, SAML-SSO configurations, Provisioning Connectors, or third-party applications. Therefore, a pure App Registration list is incomplete.

Check:

• App Registrations,
• Enterprise Applications,
• SAML signature certificates,
• SCIM provisioning secrets,
• Automation Accounts and Runbooks,
• Azure Key Vault,
• CI/CD systems,
• Power Automate Custom Connectors,
• local services and scheduled tasks,
• source code and configuration repositories.

Secure storage

Secrets do not belong in:

• source code,
• unencrypted configuration files,
• tickets or emails,
• Wiki pages,
• chat messages.
• Desktop notes.

Appropriate storage locations include managed secrets stores such as Azure Key Vault or a shared enterprise password management system, depending on architecture and application. Access and retrieval should be logged and restricted to the workload or operator.

Expiry monitoring

Microsoft Entra provides recommendations for expiring application and service principal credentials, sometimes as preview and via Microsoft Graph. Regardless of the feature used, a dedicated operations monitoring system should generate advance warnings.

Recommended levels:

• long-term advance warning for planning,
• second warning with assigned change,
• critical warning shortly before expiry,
• escalation when no owner is available,
• incident when the credential has already expired.

The lead time must match the application. A business-critical service with an external vendor requires more time than an internal script with an immediately available owner.

Rotation in parallel operations

1. Determine usage

Before rotation, it must be known where the credential is stored. Client ID alone is insufficient. Search in deployment configuration, Key Vault, App Service, automation, local services, and vendor portals.

2. Create new credential

Create a new secret, certificate, or federated trust. Use a clear description and an appropriate lifespan. Copy secret values directly into secure storage.

3. Update target system

Update the secret reference or certificate in the workload. For multiple instances, a staggered deployment may be necessary.

4. Validate new authentication

Health checks alone are rarely sufficient to verify a successful transition. Relevant are primarily the appropriate sign-in logs: Service Principal sign-ins and Managed Identity sign-ins are evaluated separately in Microsoft Entra and should therefore also appear separately in monitoring and diagnostics.

A successful health check is not always enough. Check:

• token request,
• Service Principal sign-in logs,
• certificate thumbprint used, where visible,
• actual API action,
• application telemetry,
• error and retry behavior.

5. Observation phase

Keep the old and new credential valid in parallel for a short time if the application supports it and the risk is acceptable. Observe whether the old credential is still being used.

6. Remove old credential

Remove the old credential only after successful validation. Then perform another test to detect hidden instances.

Certificate rotation

Certificates require additional checks:

• private key present and protected,
• correct Key Usage and algorithm support,
• certificate chain, if relevant for the application,
• clock time and validity start,
• thumbprint in the target system,
• permissions on the private key,
• deployment to all instances.

A common error pattern is updating only the public certificate in Entra while the application continues to sign with the old private key.

SAML signature certificates

For SAML Enterprise Applications, certificates may be relevant for signing assertions or metadata. Coordinate rotation with the service provider. Depending on the provider, prepare a secondary certificate or use a metadata refresh.

Test:

• new certificate in both systems,
• signature validation,
• NameID and claims unchanged,
• login via pilot user,
• Fallback to the old certificate during the maintenance window.

Typical failure patterns

invalid_client

Possible Causes:

• Secret has expired,
• incorrect secret value used instead of the secret ID,
• incorrect client ID or tenant ID,
• certificate missing or thumbprint mismatch,
• credential created in the wrong app object,
• clock skew or faulty assertion.

New secret created, application still disrupted

The new secret is not automatically updated in the application. Check secure storage, configuration reference, deployment, restart, and the actually used instance.

Old credential deleted too early

Rollback:

• if the old secret cannot be restored, create a new credential,
• update the target system,
• test the token request,
• document the incident.

Client secret values cannot be displayed again after creation. A deleted secret is not simply re-displayed.

Owner has left the organization

Operations must maintain the owner independently of the creator. Add new owners, determine usage, rotate credentials, and remove personal dependencies.

Application uses unknown credential

Sign-in logs, key IDs, thumbprints, and configuration search help with identification. Do not delete unknown credentials without an observation and test phase if a business-critical process is possible.

Incident with already expired credential

1. identify the affected application and business process,
2. record the error message and timestamp,
3. notify the owner and operations team,
4. create a new credential,
5. store it securely in the target system,
6. reload the service in a controlled manner,
7. test the token and business function,
8. reprocess the backlog or failed jobs,
9. fix the cause of the missing warning,
10. review other credentials of the same owner.

Do not expand permissions during rotation

Credential rotation is not a reason to grant permissions anew and more broadly. The identity remains the same service principal. If a new app registration is created at the same time, consent, roles, assignments, and Conditional Access must be reviewed separately.

Automation of inventory

Microsoft Graph can read applications and service principals along with credential metadata. An inventory should:

• capture key IDs and expiration dates,
• handle app and service principal credentials separately,
• add owner and last usage,
• deduplicate warnings,
• do not output secret values,
• document exceptions and accepted risks.

Preview recommendations can supplement but must not form the sole operational mechanism.

Test catalog

1. new secret in parallel operation,
2. new certificate with thumbprint check,
3. application on every instance,
4. token for the correct tenant and resource,
5. actual read/write operation,
6. old credential still active,
7. old credential removed,
8. restart or redeployment,
9. failover instance,
10. alert for the next expiration date.

To assess an application's business requirements, first distinguish between Enterprise Applications and App Registrations and then check app permissions and admin consent.

How to turn expiring app credentials from an emergency into a scheduled maintenance task

Credential operations consist of inventory, ownership, secure storage, advance warning, and tested rotation. New and old credentials are operated in parallel under control, the actual login is confirmed in logs, and only then is the old credential removed. This turns the expiration date into a normal change instead of an unannounced application outage.