Why do Microsoft identity tools still need an IGA layer?

Why This Matters for Security Teams

Microsoft identity tooling can centralise authentication, conditional access, and directory state, but it does not by itself solve entitlement governance across SaaS, on-premises apps, cloud platforms, and privileged workflows. That gap is why IGA still matters: it adds access request, approval, certification, segregation-of-duties checks, and lifecycle enforcement where directory controls stop. NIST’s Cybersecurity Framework 2.0 is clear that access governance is broader than account creation and sign-in policy. The same issue shows up in NHI environments, where identities proliferate faster than teams can review them, and the Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises. When identity state and application entitlements are managed in different systems, drift becomes normal rather than exceptional.

The practical risk is not just excess access. It is failed review, stale privilege, and no reliable evidence trail when auditors ask who approved what, when, and why. Microsoft tools can enforce a strong front door, but IGA is still the control plane that keeps downstream access from silently expanding. In practice, many security teams encounter entitlement drift only after a privilege review, audit finding, or breach investigation has already exposed it, rather than through intentional governance.

How It Works in Practice

In a mature model, Microsoft identity services handle the directory and authentication layer, while IGA orchestrates governance across connected systems. That means joining, moving, and leaving events trigger reviews of access not just in Entra ID, but in business applications, databases, infrastructure consoles, and high-risk NHI estates. IGA also provides evidence that access was approved under policy, not merely assigned through a connector or inherited from an old group.

This is especially important where entitlements are not expressed cleanly in Microsoft-native constructs. A user may authenticate through Microsoft, but the actual risk resides in application roles, shared mailboxes, API permissions, service accounts, or delegated admin rights. IGA helps reconcile that spread by enforcing policy at lifecycle milestones and by running periodic access certifications. For NHI programmes, the same pattern applies to secrets, service principals, and machine accounts, which is why NHIMG research such as the Top 10 NHI Issues and the Microsoft Midnight Blizzard breach are relevant reading for teams trying to understand how identity sprawl turns into operational risk.

• Provisioning: create access only when a role, ticket, or policy condition is satisfied.
• Certification: force managers or app owners to reattest access on a schedule.
• SoD checks: prevent conflicting access combinations before they are granted.
• Deprovisioning: remove access across all connected systems when the identity changes or exits.
• Auditability: preserve who approved the access and what policy justified it.

Current guidance suggests using Microsoft identity for authentication and IGA for governance enforcement, rather than trying to stretch one platform to do both. These controls tend to break down in large hybrid environments with custom applications and shadow admin paths because the authoritative entitlement model is not fully represented in the directory.

Common Variations and Edge Cases

Tighter governance often increases administrative overhead, requiring organisations to balance approval friction against the cost of unchecked access. The tradeoff is most visible in hybrid estates, where some applications support native provisioning and others require API-based reconciliation or manual certification workflows. There is no universal standard for this yet, so best practice is evolving toward risk-based governance rather than treating every entitlement with the same review cadence.

Some teams assume Microsoft group management is enough if conditional access is strong. That works only when the application estate is simple and role mapping is tightly controlled. It fails when access is granted directly inside third-party apps, when privileged roles are delegated outside the directory, or when machine identities and secrets are involved. The 52 NHI Breaches Analysis and NIST’s identity guidance both point to the same operational lesson: governance must follow the entitlement, not just the login.

For Microsoft-centric environments, the most defensible model is usually layered control: directory controls for authentication, IGA for entitlement governance, PAM for privileged elevation, and separate lifecycle management for NHIs and secrets. That separation avoids overloading any single platform and gives security teams a clearer audit story when access spans people, apps, and automated workloads.

Related resources from NHI Mgmt Group

• Why do Microsoft identity and endpoint tools still leave governance gaps in large enterprises?
• What do security teams get wrong about automatic updates for identity tools?
• Why do collaboration tools create such a large secrets risk?
• When does a machine identity become a compliance problem?