The organisation certifies only part of the privilege picture and leaves root accounts, SaaS admins, and service principals outside the control loop. That creates false confidence in least privilege because the most powerful access paths often sit outside the familiar directory. A review programme is incomplete if it excludes the systems that carry the highest blast radius.
Why This Matters for Security Teams
Access reviews only work when they cover the full identity estate, not just the directory that is easiest to export. If non-Microsoft systems are excluded, the certification process misses root logins, SaaS administrators, cloud service principals, API keys, and other high-impact NHI paths. That creates a governance gap where least privilege is assumed, but not actually verified.
This is a common failure mode in environments that rely on Microsoft-centric reporting while operational access lives elsewhere. The OWASP Non-Human Identity Top 10 treats visibility and lifecycle control as core issues because unseen identities become unmanaged risk. NHIMG’s Ultimate Guide to NHIs shows the scale of the problem: 97% of NHIs carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts. In practice, many security teams encounter the breach after a forgotten SaaS admin or service principal is abused, rather than through intentional review failure.
How It Works in Practice
A complete access review programme needs an inventory that spans every control plane where privilege exists. That includes Entra ID or Active Directory, but also AWS IAM, Google Cloud, Okta, GitHub, Salesforce, ServiceNow, Snowflake, Kubernetes, and any platform where service accounts or automation tokens can act with authority. The review scope should map each identity to its owner, purpose, last use, credential type, and business criticality.
Practitioners usually need three things working together:
- Cross-platform discovery so the review list is not limited to Microsoft exports.
- Privilege classification that distinguishes human users, admin roles, service principals, API keys, and break-glass accounts.
- Remediation paths that can disable, rotate, or reassign access outside the directory where the review was performed.
From a control perspective, this aligns with NIST SP 800-53 Rev. 5 Security and Privacy Controls because access enforcement and account management must cover all in-scope systems, not just the primary identity provider. It also fits NHIMG’s Ultimate Guide to NHIs, which emphasizes that secrets and service accounts often live outside centralized oversight. The most effective programmes reconcile directory records with cloud IAM, SaaS admin consoles, and code repositories before certification begins, then feed removals into the owning platform rather than logging an unresolved exception. This guidance tends to break down when ownership is split across business units and platform teams because no single system has authoritative visibility into all privileged access.
Common Variations and Edge Cases
Tighter access review scope often increases operational overhead, requiring organisations to balance completeness against the effort needed to reconcile many platforms. That tradeoff becomes sharper in hybrid estates, acquisitions, and shadow IT environments where non-Microsoft systems are numerous and poorly documented.
Current guidance suggests treating excluded systems as a risk signal, not as a clean exception. A SaaS admin account with no Microsoft dependency can still control data, revoke users, or expose secrets. The same is true for cloud root credentials and CI/CD service principals. NHIMG’s 52 NHI Breaches Analysis reinforces that many incidents start with identities and secrets that were outside normal review routines. This is why review attestation should explicitly state which systems were included, which were excluded, and why.
Where consensus is still evolving is the minimum viable scope for very large estates. Some organisations prioritize the highest-blast-radius systems first, while others insist on enterprise-wide coverage before certification. Either approach is weaker than full coverage, but both are better than assuming Microsoft-only reporting is sufficient. In practice, the control fails when privileged access is federated into SaaS and cloud services that never appear in the directory used to run the review.
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 CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Full visibility is required to catch non-Microsoft privileged identities. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access governance must cover all in-scope systems. |
| NIST SP 800-63 | Identity proofing and lifecycle gaps arise when accounts are outside review scope. | |
| CSA MAESTRO | TR-4 | Cloud and SaaS privilege paths need continuous governance, not directory-only checks. |
| NIST AI RMF | GOVERN | Governance must define scope, ownership, and accountability for access review coverage. |
Set policy for cross-platform review scope and assign accountable owners for exclusions.
