Secrets and certificates on app registrations: credential hygiene that holds up
An app registration with Microsoft Graph permissions is an identity in its own right. Its secrets and certificates are as good as a password, with no MFA to protect them. Yet they are often created for two years, pasted into a configuration file and forgotten.
Client secret or certificate
An application that authenticates as itself (the client credentials flow) presents one of two credential types:
- A client secret: a string sent as is. Anyone who reads it in a code repository, an environment variable or a log can use it from anywhere;
- A certificate: the application proves possession of a private key by signing an assertion. If the private key is stored as non-exportable, in a key vault or a hardware module, it is far harder to steal.
A certificate is therefore preferable to a secret. Better still, for workloads hosted in Azure or in a compatible CI/CD pipeline, managed identities and workload identity federation remove stored credentials altogether.
Lifetime and rotation
The portal offers limited lifetimes for secrets, but the APIs have historically allowed secrets and certificates valid for many years. In the tenants we audit, it is not unusual to find secrets valid until 2299. A long-lived secret is never rotated, so it is never revoked when a contractor leaves or a workstation is compromised.
App management policies let you enforce tenant-wide rules: block secrets, cap their lifetime, restrict certificate validity. Some of these features depend on a Workload ID licence; check the current Microsoft documentation. Failing that, a regular inventory of expiry dates and a documented rotation procedure are the bare minimum.
Two locations. Credentials can be added to the application object, but also directly to the service principal. The latter do not show up on the portal's "Certificates & secrets" page. An attacker looking for stealth prefers that location, so your inventory must cover both.
Owners: an escalation path
The owner of an app registration can add secrets and certificates to it. If the application holds high privileges, its owner can act with those privileges, whatever their own level. A standard user who owns an application holding Application.ReadWrite.All is effectively a hidden administrator.
The Application Administrator and Cloud Application Administrator roles grant the same power over every application in the tenant. They should be treated as privileged roles and assigned through PIM.
Orphaned applications
An orphaned application no longer has an identified owner or a real use, yet keeps its permissions and credentials. To find them:
- List registrations with no owner, or whose owners are disabled or deleted;
- Check service principal sign-in activity to spot those that no longer authenticate;
- Cross-reference with granted permissions to prioritise the most sensitive;
- Contact the teams, then disable before deleting so the change can be rolled back.
What an audit checks
- The split between secrets and certificates, and any credentials set on service principals.
- Secrets and certificates with excessive lifetimes, expired ones, or several on the same application.
- Whether app management policies are in place.
- Owners of highly privileged applications and holders of the application administration roles.
- Applications with no owner or no recent activity.