It fails where the directory is not also the authority for every application role, entitlement, and certification point. Once governance depends on Azure AD alone, external systems such as SaaS platforms, on-prem applications, and separate directories can fall outside the control plane. That creates coverage gaps even when authentication controls are strong.
Where directory-centric governance breaks down in mixed enterprise estates
Directory-centric governance works when the directory is the system of record for every application role, entitlement, and review point. In mixed estates, that assumption often breaks. SaaS platforms, legacy on-prem systems, and separately managed directories can retain their own authorization logic, so the governance model sees the user but not the full access surface.
The practical failure is not authentication, it is coverage. A directory can prove who signed in, while a separate application or directory still decides what that identity can do. The result is partial governance, fragmented certification, and blind spots around effective access.
That is why identity governance has to be treated as a control-plane problem, not just a directory-sync problem. Where entitlements are created, approved, and reviewed outside the central directory, the governance program becomes dependent on connector quality, app inventory completeness, and whether the target system exposes usable entitlement data at all.
Which systems escape the central control plane?
The systems that escape first are usually the ones with their own mature permission model: SaaS applications, on-prem business systems, database-level roles, and secondary directories that were never fully harmonized. These systems may authenticate through the enterprise directory, but their authorization state lives elsewhere. When that happens, a central IAM and IGA Basics model is only as complete as the least-connected application in the estate.
Mixed environments also expose a lifecycle mismatch. A user can be provisioned centrally, yet remain entitled locally after a transfer, exception, or deprovisioning event. The directory may show a clean identity record while the business application still carries elevated access, inherited roles, or stale grants.
Another common gap is role translation. Directory roles are often too coarse to represent application-specific privileges, while application roles are too granular to be managed cleanly at the directory layer. That gap is where entitlement drift, duplicate roles, and hidden local admin paths tend to accumulate. A stronger Role Mining and Role Design Guide approach helps only if the role model is extended beyond the directory and into the applications that actually enforce access.
Why certification and recertification miss the real access picture
Certification fails when reviewers are asked to approve directory accounts instead of actual application entitlements. In that model, a manager may see that an account exists, but not whether it carries finance, customer data, admin, or workflow privileges inside each connected system. The review then becomes a proxy for access, not a review of access.
This is where disconnected apps create the most visible governance gap. If the certification process cannot ingest entitlements from a SaaS platform or legacy directory, those grants will either be excluded or manually summarized. Both outcomes reduce assurance, because the review no longer tests the true least-privilege state.
For mixed estates, the better question is whether the certification point is attached to the entitlement source of truth. If not, the program may still satisfy a calendar requirement while failing to detect privilege creep, shared access, or role sprawl. The same issue appears in SoD checks when conflicts are only enforced centrally but executed locally. Segregation of Duties (SoD) Guide material becomes most useful when it is applied to the applications that hold the real conflict, not just to the directory record.
Risk and Threat Considerations
Mixed environments increase exposure because the control plane becomes uneven. Attackers and insiders do not need to break the directory if they can abuse a less-governed application role, a stale local account, or an overlooked secondary directory. That is especially dangerous when the directory gives a false sense of completion while application-level privilege remains untouched.
Failure mechanism: entitlements drift away from the central identity record, certifications review incomplete data, and deprovisioning does not propagate to every local authority source.
Impact: excess privilege persists, access removal is incomplete, and the enterprise loses confidence that access reviews, SoD enforcement, and offboarding actually cover the full environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Mixed estates need account governance across every authoritative system, not only the directory. |
| AC-6 — Least Privilege | Coverage gaps create excess access when local app roles escape central governance. | |
| IA-5 — Authenticator Management | Mixed environments often depend on credentials and authenticators that must be lifecycle-managed consistently. | |
| Recommendation — Ensure every application and directory account is inventoried, provisioned, reviewed, and removed through account management. Limit each entitlement to the minimum access required across directory and application layers. Rotate, protect, and revoke authenticators wherever they are used to obtain access. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The issue is incomplete access control coverage across connected enterprise systems. |
| Recommendation — Extend identity and access controls to every system that grants or reviews access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The problem is inconsistent access governance across directories, SaaS, and on-prem systems. |
| Recommendation — Define and enforce access control rules for each authoritative access source. | ||
Practitioner Guidance
What to verify: confirm whether each connected application exposes authoritative entitlement data, not just login status. If the answer is no, treat that system as a governance gap until the access model is remediated or a compensating review process is defined.
Decision rule: if a system can grant, retain, or approve access outside the directory, it must be governed at that layer as well. Do not rely on directory synchronization alone to prove least privilege or completed revocation.
What good looks like: certifications are entitlement-based, deprovisioning reaches every authoritative access source, and exceptions are tracked where connectors or APIs cannot provide full coverage. In a mixed estate, completeness matters more than centralisation slogans.
Practitioner takeaway: directory-centric governance fails when the directory is only an identity registry, not the authority for actual access. The control objective is to govern every place where privilege is created, changed, or reviewed.
Related resources from NHI Mgmt Group
- Why do B2B environments create more identity governance risk than a single enterprise directory?
- Why is it important to integrate identity and data governance?
- Why is single-provider AI agent governance not enough for enterprise security?
- Why do mixed identity environments expose governance gaps so quickly?