The review may certify human access while leaving the highest-risk automation untouched. That creates a false sense of control because the identities most likely to persist and inherit broad rights remain outside the governance loop. Reviews should cover workload identities, their owners, and the scopes they can actually reach.
Why This Matters for Security Teams
When Azure access reviews exclude service principals, the review process can certify people while leaving automation, integrations, and application workloads untouched. That gap matters because service principals often hold the broadest and longest-lived permissions in the tenant, and they do not behave like human accounts. Their access can persist silently across subscriptions, resource groups, and control-plane operations, bypassing the assurance leaders think they are getting from periodic reviews. NHI Mgmt Group notes that Ultimate Guide to NHIs reports only 5.7% of organisations have full visibility into their service accounts, which makes excluded reviews especially dangerous.
This is not a paperwork issue. It is an access governance failure that leaves the highest-risk identities outside the human review cycle. In practice, teams often discover the problem only after a stale application credential or over-permissioned service principal is used to move laterally, export data, or alter security controls. That pattern is consistent with the broader NHI risk landscape described in 52 NHI Breaches Analysis and with the exposure patterns documented in the OWASP Non-Human Identity Top 10.
How It Works in Practice
Azure access reviews are only useful when they cover the full identity surface: users, groups, service principals, managed identities, and the owners who can approve or ignore changes. If service principals are omitted, the review may still close with a clean status while the actual blast radius remains unchanged. The control failure is usually in three places: the identity inventory is incomplete, ownership is unclear, and the permissions bound to workloads are never revalidated against current business need.
A sound review process should map each service principal to an accountable owner, the apps or pipelines that depend on it, and the specific scopes it can reach. That means reviewing Microsoft Graph permissions, Azure RBAC role assignments, directory roles, and any privileged application consent. The objective is not just to ask whether the principal exists, but whether it still needs access at the level it has been granted. NIST guidance on access control in NIST SP 800-53 Rev 5 Security and Privacy Controls supports periodic reassessment of authorisation, while Ultimate Guide to NHIs shows why NHI visibility and lifecycle discipline are foundational.
- Include service principals in the same review cadence as human identities.
- Require a named business and technical owner for each principal.
- Validate scopes against actual workload use, not just historical assignment.
- Remove stale, unused, or duplicated principals instead of recertifying them.
- Pair reviews with secret rotation and credential expiry checks.
Where teams do this well, access reviews become a real control instead of a compliance ritual. These controls tend to break down in highly automated Azure environments with many app registrations, shared pipelines, and undocumented service ownership because reviewers cannot reliably distinguish essential workload access from abandoned privilege.
Common Variations and Edge Cases
Tighter review coverage often increases operational overhead, requiring organisations to balance stronger assurance against application downtime and approval friction. That tradeoff is especially visible in legacy Azure estates, where a single service principal may support multiple workloads, or where managed identities and app registrations are mixed together without clean ownership boundaries. In those environments, best practice is evolving rather than settled, and current guidance suggests treating each identity class separately rather than forcing one review template across all of them.
There are also edge cases where a service principal looks low risk but is not. A principal used only for CI/CD can still deploy privileged infrastructure, and a principal used for reporting can still read sensitive data across subscriptions. Conversely, some principals are ephemeral and tightly scoped, so a full manual review every cycle may add noise without improving security. The better approach is risk-based: use higher review frequency for principals with tenant-wide consent, privileged RBAC roles, or access to security tooling, and automate the low-risk cases where policy allows. This aligns with the patterns surfaced in Azure Key Vault privilege escalation exposure and the broader workload-identity risks described in the OWASP Non-Human Identity Top 10.
The key exception is not technical, but organisational: when ownership cannot be assigned, the review has already failed. In those cases, the correct response is not recertification, but suspension, replacement, or retirement of the principal.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Service principals are non-human identities that need review and lifecycle control. |
| CSA MAESTRO | GOV-02 | Agent and workload governance requires ownership and visibility over non-human access. |
| NIST AI RMF | GOVERN | Governance must cover autonomous and automated access paths, not only human users. |
| NIST CSF 2.0 | PR.AC-1 | Access management fails when review scope excludes privileged non-human identities. |
| NIST Zero Trust (SP 800-207) | SA, J-031 | Zero trust requires continuous verification of workload identities and their access. |
Treat every service principal as a distinct workload identity and verify access at request time.
