Secrets, certificates and federated credentials: credential hygiene for Entra ID apps

Three kinds of credentials

An application that authenticates to Entra ID in its own right must prove its identity. Three mechanisms are available:

• Client secret: a string of characters, equivalent to a password. Easy to use, easy to copy, easy to leak.
• Certificate: the application signs an assertion with its private key. The key can be kept in a vault (Azure Key Vault, HSM) without ever being exposed in clear.
• Federated credential (workload identity federation): the application presents a token issued by a trusted provider, such as GitHub Actions, a Kubernetes cluster or another identity provider, which is exchanged for an Entra ID token. No secret is stored.

The order of preference is clear: a managed identity when the code runs in Azure, a federated credential where the platform supports it, a certificate otherwise, and a client secret as a last resort.

Expiry and renewal

The portal limits the lifetime of client secrets, but longer lifetimes may still exist in older tenants or may have been created through the API. App management policies let you enforce tenant-wide rules: maximum lifetime for secrets and certificates, or even blocking secrets for new applications. Licensing terms for this feature change; check them for your agreement.

Expiry cuts both ways. Too long, and a stolen credential remains usable for years. Poorly tracked, and an outage hits the day the secret expires. You therefore need tracking: an inventory of expiry dates, advance alerts and a named owner for each renewal.

Owners as an escalation path

The owners of an app registration can add credentials to it. If the application holds high privileges, for example RoleManagement.ReadWrite.Directory or Application.ReadWrite.All, a mere owner can authenticate as the application and exercise those rights. The same applies to the Application Administrator and Cloud Application Administrator roles, which can manage credentials for every application.

Credentials on service principals

A credential can be added to the application object (visible under App registrations) or directly to the application's service principal in the tenant. The second case does not appear in the usual "Certificates and secrets" blade, and that is precisely why attackers have used it to keep discreet access to existing applications, multi-tenant ones included.

Points to watch:

1. inventory through Microsoft Graph the credentials held on service principals, not only on applications;
2. monitor the audit log for credential additions on applications and service principals;
3. for your own multi-tenant applications, enable app instance property lock, which prevents credentials from being added to their service principals in other tenants;
4. look very closely at any credential found on the service principal of a third-party or Microsoft application: legitimate cases are rare.

Where secrets live

A secret that is well configured in Entra ID can still be compromised by the way it is stored. We find them in configuration files, plain-text pipeline variables, Git repositories and shared scripts. Good practice is to keep secrets and certificates in a vault, restrict access to the workloads that need them, and regularly scan code repositories for leaked credentials.

What an audit checks

• The mix of credential types: secrets, certificates, federated credentials.
• Validity periods, and expired or soon-to-expire credentials.
• The app management policies in place.
• The owners of privileged applications and the holders of application administration roles.
• Credentials held on service principals, especially those of third-party applications.
• Monitoring of credential additions in the audit logs.