Workload identities: the accounts nobody watches
The applications and scripts connected to your tenant often hold more rights than your administrators, with no MFA and no review. Here is how to find them, reduce their privileges and replace the secrets lying around.
Faceless accounts
Every integration added to the tenant — a backup tool, an HR connector, an automation script, a SaaS application — creates an identity: a service principal. These identities do not sign in with a password and a phone, do not go through MFA and never go on holiday. In many tenants they outnumber users, and are far less monitored.
Application, service principal, managed identity
The app registration is the definition of the application in its home tenant. The service principal is its instance in your tenant: that is what receives permissions. Managed identities are service principals whose credentials Azure manages itself, for resources hosted in Azure. Where possible, they are the best option: no secret to store or rotate.
The permissions that hand over the keys
Application permissions apply with no signed-in user, across the whole tenant. Some are effectively equivalent to Global Administrator:
RoleManagement.ReadWrite.Directory: assign itself any Entra ID role.AppRoleAssignment.ReadWrite.All: grant itself any application permission.Application.ReadWrite.All: add credentials to other applications, and so borrow their rights.Mail.ReadWriteorFiles.ReadWrite.Allas application permissions: read every mailbox or every file.
An application holding one of these is a Tier 0 asset, just like a Global Administrator.
Secrets, certificates, federation
A client secret is a password: it gets copied, ends up in a code repository or a configuration file, and often stays valid for two years. A certificate is better, especially when the private key is protected. Workload identity federation goes further: a GitHub Actions pipeline or a Kubernetes workload exchanges a token from its own provider for an Entra ID token, with no stored secret at all.
Mind the owners. The owner of an app registration can add credentials to it. If a highly privileged application is owned by an ordinary user, that account becomes a direct path to those privileges.
Govern consent
Letting every user consent to any application opens the door to consent phishing. Restricting user consent to verified publishers and low-impact permissions, and enabling the admin consent request workflow, keeps collaboration smooth without signing a blank cheque.
What an audit checks
- Service principals holding sensitive application permissions.
- Expired secrets and certificates, or ones valid for excessive periods.
- Applications with no owner, or owned by non-administrators.
- User consent settings and the admin consent workflow.
- Applications inactive for months that still keep their rights.
For tenants with the Workload Identities Premium licence, Conditional Access can also apply to service principals, for example to restrict their sign-ins to known IP addresses.