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.

What you'll build

Eight content subs covering the identity ecosystem from the governance perspective:

IAM1.1 — Identity Types as Governance Objects. Five identity categories (member, guest, service principal, managed identity, AI agent) examined through their governance properties — not admin properties. Full Graph API output per type with field-by-field annotation. Identity census with governance gap analysis per type. The governance coverage map: which controls exist for which types, and where the gaps are.

IAM1.2 — The Identity Data Model. Twelve governance-critical attributes across four categories: lifecycle (employeeHireDate, employeeLeaveDateTime, createdDateTime), organizational (department, manager, employeeType, employeeOrgData), activity (signInActivity, lastPasswordChangeDateTime), and extended (customSecurityAttributes). What each enables, what breaks when it's missing, and the attribute dependency map for every governance mechanism in the course.

IAM1.3 — Data Quality as a Governance Foundation. The "you can't govern what you can't see" problem. Attribute coverage audit with composite data quality score. What happens when lifecycle workflows run against incomplete data — the silent failures. Remediation strategies: HR system integration, CSV bulk import, Graph API enrichment scripts, and the minimum viable data quality threshold for each governance mechanism. NE data quality assessment and remediation plan.

IAM1.4 — Group Architecture for IAM. Security groups, M365 groups, dynamic groups, role-assignable groups — each as a governance mechanism with different characteristics. Group classification and sprawl diagnostic. Naming conventions that enable discoverability and automation. Ownership enforcement. Empty group identification. NE group audit: 214 groups, 31 empty, 67 ownerless, 89 undescribed.

IAM1.5 — Administrative Units and Delegation Boundaries. AUs as the delegation boundary for IAM. Graph API AU queries. Scoped role assignments — what roles support AU scoping and what roles don't. Restricted management AUs for protecting sensitive identities (executives, service accounts, break-glass). Who manages identity for which scope. NE delegation assessment: flat directory, no AUs, all admins global.

IAM1.6 — Licensing for Identity Governance. P1 vs P2 vs Governance add-on vs Entra Suite vs Workload ID Premium ($3/workload/month) vs Agent 365 ($15/user/month). Feature-by-feature mapping: what each license tier unlocks and what's gated. Graph API licensing queries against your own tenant. The E3 vs E5 trade-off for IAM. Budget callout: the cost of not having governance licensing vs the PowerShell workarounds. NE licensing analysis.

IAM1.7 — The Governance State Assessment. The capstone of M1. Comprehensive audit consolidating findings from IAM1.1–1.6 into a single governance posture document. Identity census summary, data quality score, group sprawl metrics, delegation gaps, licensing constraints, non-human identity inventory. First ADRs (IAM1-001: data quality remediation strategy, IAM1-002: group governance approach, IAM1-003: delegation model). First risk register entries. Reusable governance state assessment script.

IAM1.8 — Module Summary. Per-sub recap with specific findings and artifacts. What the reader has after M1. Module 2 prerequisites — specific M1 outputs required before building lifecycle workflows.

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.