Every Microsoft 365, Intune, and Entra ID tenant runs on two kinds of identities: the people you think about, and the applications you forget about. Those applications, the service principals behind app registrations and enterprise apps, sign in without a person, without multi-factor authentication, and without any of the friction that protects a human account. They are powerful, they are quiet, and they pile up. Attackers know this, which is why service principals have become one of the most reliable ways into a cloud tenant.
Here is what makes a service principal risky, why the risky ones are so easy to miss, and how to find them before someone else does.
What a service principal actually is
When you register an application in Entra ID, you create an app registration (the global definition) and a service principal (the local identity in your tenant that the app uses to sign in and hold permissions). Scripts, daemons, CI pipelines, SaaS integrations, and Microsoft Graph automations all authenticate as service principals. They hold credentials, a client secret or a certificate, and they are granted permissions, often to Microsoft Graph, sometimes to your whole directory.
That last part is the problem. A single over-permissioned service principal with a never-expiring secret can read every mailbox, reset roles, or export your directory, and nobody is watching it the way they watch the admins.
What makes a service principal risky
Not all service principals deserve the same scrutiny. These are the traits that move one up the list:
- Over-privileged application permissions. Application permissions (app roles) apply with no signed-in user, so they are the most dangerous. Watch for tenant-wide Graph grants like
Directory.ReadWrite.All,Application.ReadWrite.All,RoleManagement.ReadWrite.Directory,Mail.Read, and the Exchangefull_access_as_app.Application.ReadWrite.AllandRoleManagement.ReadWrite.Directoryare effectively a path to Global Administrator. - Long-lived or sloppy credentials. Secrets that never expire, certificates valid for years, multiple active secrets on one app, or expired credentials left in place. Each one is a key that can be copied and reused with no MFA prompt.
- Dormant service principals. Apps that have not signed in for months but still hold live permissions. They are pure attack surface with no business owner paying attention.
- Broad consent grants. Tenant-wide admin consent given to an app, or delegated scopes a user consented to during a consent-phishing attack. The grant outlives the moment it was given.
- Directory roles on the app itself. A service principal can be assigned Entra roles directly. A non-human identity holding Privileged Role Administrator or Global Administrator is a serious finding.
- No owner. Orphaned apps with no owner are the ones that never get reviewed, rotated, or retired.
- Externally owned or multi-tenant apps. Apps owned outside your tenant, or multi-tenant apps, widen who can influence the identity.
Why the risky ones slip through
Service principals are invisible to most of the controls you rely on. There is no human to require MFA from. There is no Conditional Access prompt on a daemon. Sign-in logs for workload identities live in a different place than user sign-ins, so they rarely reach the dashboards people actually watch. And most of these apps were created in a hurry by a developer or an admin solving a real problem, then left running long after the project ended.
The credential that breaches you is usually not new. It is the one created three years ago, granted more than it needed, and never rotated.
A practical way to find them
You do not need a product to start. You need an inventory and a few questions asked of every service principal:
- List every service principal and the application permissions and roles it holds. Sort by privilege, not by name.
- For each one, check credential type, count, and expiry. Flag never-expiring secrets, long certificate lifetimes, and multiple active credentials.
- Pull workload-identity sign-in activity and flag anything with no sign-ins in the last 90 days that still holds permissions.
- Review admin consent grants and delegated OAuth2 grants for broad or unexpected scopes.
- Find any service principal assigned an Entra directory role, especially a privileged one.
- Identify apps with no owner, and apps owned or published outside your tenant.
Do that once and you will almost certainly find at least one identity that can read everything and answers to no one.
How Siemserva finds and ranks them
Applications and service principals are a first-class part of what Siemserva by Senserva scans across Microsoft 365, Intune, and Entra ID. In a single scan it inventories every app registration and service principal, then flags the patterns above: risky application permissions, weak credential hygiene, dormant identities, broad consent grants, directory roles held by apps, and missing owners.
Every finding is ranked by Severity, mapped to the compliance controls your auditors ask about, and paired with a validated, ready-to-run fix, so you get a prioritized worklist instead of a raw export. Because configuration, identity, and risk live in one connected model, you can also ask plain-language questions through the Senserva MCP and have Claude reason across your service principals the way an analyst would. The next scan proves the gap is closed.
Run Siemserva against a free demo tenant and see your at-risk service principals ranked on the first scan. No agents, no cost to start.