The Entra ID Identity Ecosystem

The ecosystem you govern — and the one you think you govern

Module 0 showed you the gap between administered identity and governed identity. You ran the census, traced the lifecycle, measured the permission creep, and inventoried the non-human identities. Those diagnostics revealed the symptoms. Module 1 examines the ecosystem that produces them.

Every governance mechanism in this course — lifecycle workflows, dynamic groups, access reviews, entitlement management, PIM, delegation, monitoring — operates on the identity ecosystem in your Entra ID tenant. That ecosystem isn't just user accounts. It's five identity types, each with different governance properties. It's a data model with twelve attributes that governance automation depends on, most of which are empty. It's 214 groups that assign access through membership, 67 of which have no owner. It's a flat directory with no administrative boundaries, where every admin has tenant-wide scope. It's a licensing model that gates the governance features you need behind add-on licenses your organization may not have.

If you build lifecycle workflows on a data model where 80% of identities are missing the attribute the workflow triggers on, the workflow works — for 20% of your workforce. If you build access reviews that route to managers when 25% of identities have no manager assigned, the review completes — with 25% of access unreviewed. If you build dynamic groups scoped by department when 23% of identities have no department value, the groups populate — and silently exclude nearly a quarter of your employees.

The ecosystem determines what governance is possible. This module maps it completely before you build anything on top of it.

The decisions that shape every downstream module

Identity ecosystem decisions form a dependency chain. Each choice in M1 constrains what's achievable in M2 through M14. Understanding these dependencies before you audit helps you see why this module exists.

Identity type awareness (IAM1.1) determines the scope of your governance program. Most organizations govern members and maybe guests. Service principals, managed identities, and AI agents are excluded — not deliberately, but because the governance tools they use (access reviews, lifecycle workflows) were designed for human identities. If you don't categorize identity types as governance objects, your governance program covers human identities and ignores the non-human identities that outnumber them. Modules 9–11 build the non-human governance framework — but IAM1.1 defines the scope.

Data model coverage (IAM1.2) determines which automation mechanisms work. Lifecycle workflows trigger on employeeHireDate. Dynamic groups evaluate department and employeeType. Access reviews route to manager. If the attributes are missing, the mechanisms fail silently. IAM1.2 maps every dependency, and IAM1.3 defines the remediation plan to close the gap before Module 2 builds the automation.

Data quality (IAM1.3) is the prerequisite that most governance programs skip. You can't govern what you can't see. An attribute that exists in the schema but is empty for 80% of identities isn't an attribute — it's a placeholder. IAM1.3 measures the gap, calculates the impact on downstream governance mechanisms, and produces the data quality remediation plan that must execute alongside the governance build.

Group architecture (IAM1.4) determines how access is assigned and therefore how access is reviewed. Groups are the primary access assignment mechanism in M365 — security groups grant SharePoint access, M365 groups grant Teams membership, role-assignable groups grant Entra directory roles. If the group architecture is sprawling, ownerless, and undocumented, then every governance mechanism that acts on groups (access reviews, entitlement management, lifecycle workflows) inherits that disorder. Module 3 builds the group architecture. IAM1.4 audits the current state.

Delegation boundaries (IAM1.5) determine who governs what. Without administrative units, every admin role has tenant-wide scope. The User Administrator for the Manchester office can modify accounts in Bristol, Edinburgh, and Rotterdam. With AUs, you scope administration to specific populations — enabling least-privilege delegation that Modules 7 and 8 depend on.

Licensing (IAM1.6) determines which governance features are available. Entra ID Governance — lifecycle workflows, entitlement management, advanced access reviews — requires the Governance add-on ($7/user/month) or Entra Suite ($12/user/month). Without it, you're limited to Graph API and PowerShell workarounds that cover approximately 70% of governance capability. The licensing analysis drives the "Without Governance Licensing" callouts throughout the course and informs the budget conversation in Module 13.

What NE's ecosystem looks like right now

Northgate Engineering's identity ecosystem is typical of organizations that have invested in security controls but not governance infrastructure. The security layer works — Conditional Access enforces MFA, Defender detects threats, Sentinel correlates alerts. The governance layer doesn't exist.

810 member accounts. 23 guests. 347 app registrations. 1,247 service principals. 214 groups, 67 ownerless, 89 undescribed, 12 dynamic. No lifecycle workflows. No entitlement management. No access reviews. No administrative units. No delegation boundaries. One annual group review with a 0.6% deny rate. No non-human identity governance. An IT Director with permanent Global Administrator who creates every account manually based on email requests from HR.

The data model is sparse. 80% of members missing employeeHireDate. 25% missing manager. 23% missing department. 100% missing employeeType. 100% missing employeeOrgData.division and employeeOrgData.costCenter. Zero custom security attributes defined.

This is the starting state. By the end of this module, every one of these gaps will be diagnosed, quantified, and documented — with ADRs for the design decisions, risk register entries for the gaps you can't close immediately, and a governance state assessment that becomes the baseline every subsequent module improves.

Before you start

Confirm you have:

• The M365 E5 developer tenant from IAM0.6 with the 15 NE personas, 13 groups, 7 app registrations, and 5 guest accounts
• The Entra ID Governance trial active (verify: Identity Governance menu in Entra admin center shows Entitlement management, Access reviews, and Lifecycle workflows)
• The program package folder structure from IAM0.7
• Microsoft Graph PowerShell connected with User.Read.All, Group.Read.All, Application.Read.All, Directory.Read.All, RoleManagement.Read.Directory, AuditLog.Read.All, User-LifeCycleInfo.Read.All scopes

If any of these are missing, return to IAM0.6 and complete the setup. Module 1 uses the NE lab environment extensively — the persona accounts, groups, and app registrations are the data the diagnostic queries evaluate.

Start here

Go to IAM1.1 — Identity Types as Governance Objects. It examines the five identity types in your tenant not as admin categories but as governance objects — each with different lifecycle characteristics, different governance controls, and different gaps. The governance coverage map you produce becomes the scope definition for the entire program.