Why do service principals with app-only permissions increase tenant risk?

Why This Matters for Security Teams

Service principals with app-only permissions are risky because they are designed to operate without a user present, which makes them durable, broadly trusted, and easy to overlook in routine access review. That combination turns a single mis-scoped application into a tenant-wide control plane issue. Current guidance from OWASP Non-Human Identity Top 10 and NHI Management Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now both point to the same operational problem: non-human identities often accumulate excess privilege faster than teams can inventory them.

NHI Mgmt Group research notes that only 5.7% of organisations have full visibility into their service accounts, which means many app-only principals are never assessed with the same scrutiny applied to humans. In practice, that invisibility makes app permissions attractive to attackers because they survive password resets, MFA changes, and even user offboarding. In practice, many security teams encounter tenant-wide abuse only after a privileged app has already been used to persist, enumerate, and expand access.

How It Works in Practice

An app-only service principal authenticates as the application itself, not as a delegated user. That matters because the effective trust boundary shifts from human workflow to workload identity. If the application is granted Microsoft Graph, directory, mailbox, or cloud resource permissions, the app can act with that authority whenever its token is valid. The risk is not just “more access”; it is unattended access that can be exercised from anywhere the token is accepted.

In mature environments, security teams should treat these principals as workload identities and govern them with the same discipline used for secrets, tokens, and certificates. That means:

• Assigning the smallest practical app role set and reviewing consent scope at creation time.
• Using short-lived credentials and NIST SP 800-53 Rev. 5-aligned access controls for approval, logging, and periodic recertification.
• Preferring workload identity controls over shared secrets so the app can be uniquely attested and rotated.
• Monitoring for abnormal directory writes, permission grants, new service principals, and consent changes.

This is where NHI governance becomes operationally important. The issue is not only that an app can read data. It is that a compromised app can chain actions, create additional identities, and quietly persist outside the lifecycle of the original human account. NHI Mgmt Group’s Top 10 NHI Issues and the 2024 ESG Report: Managing Non-Human Identities both show that excessive privilege and poor visibility are recurring failure patterns, not edge cases. These controls tend to break down when app consent is delegated to developers without central oversight because privilege creep becomes normalised across multiple projects.

Common Variations and Edge Cases

Tighter app-only controls often increase operational overhead, requiring organisations to balance faster delivery against stronger governance. That tradeoff becomes sharper in automation-heavy tenants where build systems, integrations, and background jobs depend on service principals to function continuously.

One common edge case is third-party SaaS apps that request broad directory permissions during onboarding. Another is internal automation that starts narrow but grows into a privileged “utility” principal used by multiple teams. Best practice is evolving here, but current guidance suggests separating human approval from machine execution, using just-in-time elevation where possible, and forcing time-bound consent for high-risk scopes. A service principal that can only call one API for 15 minutes is materially different from one that holds standing directory-wide permissions.

Another exception is legacy tenants that cannot yet support workload identity patterns such as certificate-based auth, federated identity, or policy-as-code enforcement. In those environments, teams should at least segment high-risk apps, monitor token issuance closely, and remove stale permissions aggressively. The main lesson is consistent: app-only access is not inherently unsafe, but once it is over-scoped, the tenant inherits the risk of a persistent non-human actor with autonomous reach. This becomes especially dangerous when long-lived secrets are embedded in CI/CD or when consent is granted to service principals that can later be reused across tenants.

Related resources from NHI Mgmt Group

• Why do service-level permissions increase cloud risk?
• Why do service accounts and IAM users with broad permissions increase persistence risk?
• Why do trusted service principals create more risk than ordinary app registrations?
• Why do ephemeral credentials still leave risk in machine access models?