What breaks when identity governance is bounded to Entra only?

Where bounded governance stops being governance

Once identity governance is limited to Entra, the control plane becomes platform-specific rather than enterprise-wide. That means the visible set of accounts, roles, certifications, and provisioning paths is only the portion Entra knows about, while other directories, SaaS admin layers, workloads, and app-local entitlement models continue to operate on their own terms. The result is not just incomplete reporting, but a fragmented governance model.

In practice, that fragmentation matters because governance decisions depend on complete inventory, consistent policy application, and revocation that actually reaches the authoritative source of access. A central dashboard can show strong hygiene inside Entra while other systems still carry stale access, duplicate roles, unmanaged service credentials, or local approval flows that never enter the review cycle. NHIMG’s IAM and IGA Basics is useful here because it separates access administration from governance and shows why those boundaries matter.

Bounded governance also distorts ownership. Teams assume a single tool is accountable for certification, role design, and lifecycle control, but applications outside the boundary may retain their own provisioning logic and exception handling. That can leave access decisions scattered across platform teams, application owners, and cloud administrators, with no single governance path that can prove who approved what, when, and against which policy.

What becomes invisible outside the platform boundary

The biggest breakage is blind spots. Anything not federated into Entra governance can escape access review, entitlement mapping, separation-of-duties checks, and joiner-mover-leaver enforcement. That includes legacy applications, partner-facing systems, workloads using local secrets or tokens, and subsidiary directories that mirror their own rules instead of inheriting Entra policy.

This is why platform-only governance often overstates control maturity. The enterprise may have strong evidence for a subset of identities, while the rest of the environment still accumulates privilege, stale access, and orphaned accounts. NHIMG’s Identity Visibility and Intelligence Platforms (IVIP) Guide helps explain the missing layer: you need visibility across the identity estate, not just the directory that happens to be best instrumented.

Entra-only governance also weakens exception handling. If a business-critical application sits outside the governed boundary, local admins often create compensating approvals, manual recertification, or ad hoc service-account ownership that never reconciles back to the central policy model. Over time, that creates an inconsistency problem, the policy looks uniform at the center, but enforcement is uneven at the edge.

NHIMG’s Access Reviews and Certification Guide is relevant because certification only works when the review scope reaches the systems that can actually grant access.

How to tell whether the model is already failing

The practical warning signs are easy to miss if you only inspect the central platform. Common indicators include applications with separate admin consoles, cloud resources whose permissions are granted outside Entra, service accounts that are never reviewed, and joiner-mover-leaver changes that require manual tickets in some teams but are automated in others. When those patterns exist, “governance” is really a patchwork of local controls.

The failure mode becomes more serious when role models diverge. One system may use Entra groups, another uses local entitlements, and a third assigns access by app-specific approval. That makes entitlement review difficult to compare, recertification inconsistent, and least privilege impossible to demonstrate across the full estate. NHIMG’s Role Mining and Role Design Guide is a good reference when the problem is not just missing scope, but incompatible role models.

When governance breaks this way, you should treat the dashboard as a partial telemetry source, not as proof of control. The right question is not whether Entra is well governed on its own, but whether every access path that can create, change, or retain privilege is reachable from the governance process.

Risk and Threat Considerations

Limiting identity governance to Entra creates a security exposure because attackers do not need the central control plane if they can abuse an unmanaged one. A stale app-local account, overprivileged service principal, or uncaptured third-party directory can provide a quieter route to persistence than the identities that are reviewed most often.

Failure mechanism: Access exists outside the governed boundary, so review, recertification, and offboarding do not reach the systems that actually authorize action. That allows privilege to accumulate, orphaned access to persist, and compromise paths to remain open even when the main platform looks clean.

Impact: The organisation gets a false sense of control, while real exposure accumulates in shadow directories, local admin planes, and unmanaged application entitlements. In an incident, that widens blast radius and makes containment slower because the revocation process is incomplete by design.

Practitioner Guidance

What to prioritise: Start with systems that can grant access independently of Entra, especially legacy applications, SaaS admin consoles, cloud platforms, and workload credentials. If a system can approve, persist, or revoke privilege without flowing through the same governance path, it needs explicit inclusion or a documented compensating control.

What to verify: Confirm that the scope includes every authoritative source of identity and entitlement, not just the most visible one. The test is simple: can you produce a complete list of where access is created, reviewed, and removed, and can you prove that each path is covered by the same governance logic?

Practitioner takeaway: Identity governance is only trustworthy when the control boundary matches the access boundary; if Entra is the whole model, then everything outside it is a governance exception waiting to become an incident.

Related resources from NHI Mgmt Group

• What breaks when administrative identity governance is weak?
• What breaks when identity governance depends on quarterly cycles?
• What breaks when identity governance stops at login events?
• What breaks when identity governance is treated as admin work instead of security work?