In this module
IAM1 Check My Knowledge
Scenario 1. Your data model audit from IAM1.2 shows employeeType coverage at 0% across all 810 member accounts. You plan to deploy a lifecycle workflow scoped to Employee identities only, so contractors receive a different onboarding sequence with time-limited access. What happens when the workflow runs?
The workflow processes all 810 members as Employee since employeeType defaults to Employee when empty. a
Empty attributes don't default to any value. An empty employeeType is null, not "Employee". A workflow scoped to employeeType equals Employee evaluates null against "Employee" and gets no match. The identity is excluded from the workflow scope entirely. IAM1.2 documented this: when the scoping attribute is empty, the identity doesn't match any scoping condition and silently falls outside every workflow that uses that attribute for targeting.
The workflow fires for zero identities because no member account has employeeType populated. The workflow execution log shows successful completion with zero identities processed. b
At 0% employeeType coverage, the scoping condition employeeType equals Employee matches nobody. The workflow runs on schedule, evaluates all 810 members, finds zero matches, completes successfully, and logs zero executions. This is the silent failure pattern from IAM1.3 — the mechanism works perfectly against empty data. The remediation from ADR IAM1-001 targets employeeType at 90% coverage within one week through CSV bulk enrichment before any employment-type-scoped workflow is deployed.
The workflow fails with an error because employeeType is a required field for scoped workflows and cannot be empty. c
EmployeeType is not a required field. Lifecycle workflows don't validate that scoping attributes are populated across the target population before running. They evaluate the condition per identity and process those that match. Identities that don't match are silently excluded. There's no "insufficient data" warning. IAM1.3 established the minimum viable thresholds specifically because the governance mechanisms don't enforce data quality — they just operate on whatever data exists.
The workflow ignores the employeeType scope condition and processes all members since the attribute is universally empty. d
Scoping conditions are not ignored when the attribute is empty. They're evaluated as written. If the condition says employeeType equals Employee, the workflow evaluates that condition for each identity. An identity with null employeeType doesn't match "Employee". The workflow doesn't adapt to data quality — it executes the logic as configured. IAM1.2's attribute dependency map showed this dependency: workflow scoping requires employeeType AND department to be populated for the mechanism to work.
Scenario 2. Your group architecture audit from IAM1.4 finds that 67 of 214 groups (31%) are ownerless. You need to deploy access reviews for these groups. A colleague suggests assigning Rachel Okafor as the owner of all 67 groups so the reviews can route to an owner. What is the governance concern with this approach?
A single owner for 67 groups can't meaningfully review the membership of 67 different access scopes. The reviews will route to Rachel, but she lacks the context to evaluate whether each member's access is justified — producing the same rubber-stamp pattern the reviews are designed to prevent. a
This is the IAM0.3 "Approve All" problem in a different form. Rachel would receive access review items for 67 groups she didn't create and doesn't manage. She can't evaluate whether the finance group's membership is correct because she doesn't know who needs finance access. She'd either approve everything (rubber-stamp) or spend weeks investigating each group (operationally unsustainable). ADR IAM1-002 rejected this approach: "Assign a single governance admin as owner of all ownerless groups — rejected because a single owner for 67 groups can't meaningfully review 67 sets of memberships." The correct approach assigns owners who actually know the group's purpose.
Rachel is the CISO and has the authority to review any access. The approach is valid as long as she has enough time in the review period to evaluate each membership. b
Authority isn't the bottleneck — context is. Rachel has the authority to approve or deny any access. She doesn't have the operational knowledge to determine whether Mark Taylor should be in SG-Finance-Readers or whether Ben Hughes should be in Team-Office-Migration-2023. Authority without context produces the same governance failure as the manager who approves 96 memberships in 47 seconds. The review needs an owner who understands the group's purpose and can evaluate membership against it.
The approach is fine as a temporary measure. Once the reviews generate data about membership patterns, Rachel can reassign ownership to the appropriate people based on who approved what. c
The first review cycle with Rachel as owner won't generate useful governance data because Rachel will either approve-all (no signal) or make uninformed decisions (wrong signal). You can't derive correct ownership from incorrect review decisions. The owner assignment should come first — find the person who knows what each group is for, assign them as owner, then run the review. IAM1.4 documented that the portal doesn't support bulk "find ownerless groups" filtering, which is why the PowerShell audit is necessary to identify the gaps before assigning owners.
Ownerless groups should be deleted rather than assigned owners. If nobody owns the group, nobody needs it. d
Ownerless doesn't mean unneeded. A group with 50 members and SharePoint site permissions is actively granting access — the absence of an owner means nobody manages it, not that nobody uses it. Deleting ownerless groups without dependency analysis risks breaking access for the members who rely on those groups. IAM1.4's remediation approach was: verify no downstream dependencies (CA policies, app assignments, SharePoint permissions), then delete empty groups, and assign owners to non-empty groups before running reviews.
Scenario 3. Your licensing audit from IAM1.6 shows your tenant has M365 E5 (P2 included) but no Governance add-on. The Governance trial from IAM0.6 is active. You need to build the business case for permanent Governance licensing. Which approach best demonstrates the value to justify the $38,880/year cost?
Present the feature comparison between P2 and Governance add-on, highlighting the additional capabilities the add-on provides. a
A feature comparison tells leadership what the license includes. It doesn't tell them why they need it. Leadership approves budgets based on business risk reduction and operational improvement, not on feature lists. The business case needs to connect the license cost to specific governance gaps that create measurable risk. IAM1.6 positioned the budget conversation around specific findings, not capabilities.
Compare the Governance licensing cost to the cost of a consulting firm engagement, showing that building internal capability is more cost-effective than outsourcing. b
The consulting cost comparison ($50,000–$150,000 vs $38,880/year) is a useful supporting point but doesn't demonstrate the specific governance value for your organization. Leadership will ask "what problem does this solve for us, specifically?" The comparison shows cost efficiency but not need. Use it as a supporting argument alongside the governance gap data from IAM1.7.
Deploy all governance features during the trial period and present usage statistics showing adoption across the organization. c
Deploying during the trial and showing usage demonstrates adoption but not governance value. High usage of access reviews that produce 99% approval rates (the IAM0.3 rubber-stamp pattern) shows activity, not effectiveness. The business case needs to show governance outcomes — access removed through reviews, lifecycle workflows that reduced manual provisioning time, compliance evidence generated automatically — not just feature usage.
During the trial, deploy lifecycle workflows and access reviews. Present the specific governance outcomes: number of stale memberships identified and removed, time saved on manual provisioning, access review deny rate with AI recommendations vs without, and the compliance evidence generated — tied to the IAM0.3 and IAM1.7 findings. d
This approach demonstrates measurable governance value tied to the organization's specific findings. The deny rate improvement (from 0.6% with basic reviews to a meaningful rate with AI recommendations and usage data) directly addresses the IAM0.3 rubber-stamp finding. The provisioning time reduction quantifies operational efficiency. The compliance evidence generation addresses the IAM1.7 finding that Elena produces manual audit responses. The business case converts the governance gap assessment into a before-and-after comparison that justifies the licensing investment with the organization's own data.
Scenario 4. Your administrative unit assessment from IAM1.5 shows zero AUs and all 12 role assignments at tenant-wide scope. A security incident occurs: a phishing email compromises the helpdesk operator's credentials. The attacker uses the compromised Helpdesk Administrator role. What is the blast radius, and how would administrative units have limited it?
The blast radius is limited to password resets only, since Helpdesk Administrator can only reset passwords. AUs wouldn't change the outcome because the role permissions are the same regardless of scope. a
Helpdesk Administrator can reset passwords and invalidate refresh tokens for non-admin users. Without AU scoping, the attacker can reset passwords for every non-admin user in the tenant — all 810 members. With AU scoping to the Manchester AU (50 users), the attacker can only reset passwords for 50 users. Same role, dramatically different blast radius. AUs don't change what the role can do — they change who it can do it to. IAM1.5 demonstrated this with the social engineering scenario.
The blast radius is the entire tenant because Helpdesk Administrator is a tenant-wide role. AUs can't scope Helpdesk Administrator, so the outcome would be the same with or without AUs. b
Helpdesk Administrator does support AU scoping — it's one of the most commonly AU-scoped roles. IAM1.5 listed it in the AU-compatible roles section. With the role assigned at the Manchester AU scope, the compromised credential can only reset passwords for Manchester users. The attacker can't reset the CISO's password, can't reset the break-glass account's password, and can't affect any user outside the Manchester AU. The role supports scoping. The tenant just doesn't have AUs configured to use it.
Without AUs, the attacker can reset passwords for every non-admin user across the entire tenant. With the helpdesk role scoped to the Manchester AU, the blast radius is limited to Manchester users only. A restricted management AU protecting executive and break-glass accounts would prevent the attacker from resetting those passwords even with tenant-wide scope. c
Two AU mechanisms limit the blast radius. Standard AUs scope the role — the helpdesk operator at Manchester AU scope can only affect Manchester users. Restricted management AUs protect specific identities — even a tenant-wide Helpdesk Administrator can't reset passwords for identities in a restricted AU without explicit scope assignment (which is an auditable event). Together, they convert a tenant-wide compromise into a site-specific incident. IAM1.5 described both mechanisms and the ADR IAM1-003 documented the delegation gap as risk DEL-001.
The blast radius is limited because Helpdesk Administrator can't reset passwords for Global Administrators or other admin roles, regardless of AU configuration. AUs provide no additional protection beyond what role hierarchy already enforces. d
It's true that Helpdesk Administrator can't reset admin passwords by default (role hierarchy protection). But the attacker can still reset passwords for 810 non-admin users — any of whom might have access to sensitive SharePoint sites, confidential Teams channels, or finance systems. The role hierarchy protects admin accounts. AUs protect the non-admin population by limiting which non-admin users the compromised role can target. Both protections matter, and they address different parts of the blast radius.
Scenario 5. Your identity type census from IAM1.1 found that service principals have no manager field, no employeeHireDate, and no employeeType. The governance mechanisms designed for members (lifecycle workflows, manager-based access reviews, dynamic groups) don't apply. What is the correct governance approach for service principals?
Assign a manager to each service principal using the notes or description field, then use that as the reviewer for access reviews targeting service principals. a
The notes and description fields are free-text strings — they're not evaluated by access review routing, lifecycle workflows, or any governance mechanism. Writing "Owner: Phil Greaves" in the description field doesn't route access reviews to Phil. It's documentation only. Service principal governance requires different mechanisms than member governance — owner-based attestation, credential expiry monitoring, and permission right-sizing. Module 9 builds these mechanisms specifically for non-human identities.
Use different governance mechanisms for service principals: owner-based attestation for lifecycle decisions, credential expiry monitoring with automated alerting, permission right-sizing based on sign-in logs and API access patterns, and Conditional Access for workload identities (requires Workload ID Premium). b
Service principals require a governance framework designed for non-human identity characteristics. Owner-based attestation replaces manager-based reviews — the application owner periodically confirms "this app still needs to exist and these permissions are still required." Credential monitoring replaces the hire-date lifecycle — secrets and certificates have expiry dates that serve as the lifecycle anchor. Permission right-sizing replaces access reviews — compare granted permissions to actual API usage and remove unused scopes. This is the framework Modules 9–11 build. IAM1.1 established that governance controls must match the identity type's characteristics.
Service principals don't need governance because they authenticate programmatically and their access is defined by code, not by human decisions. c
Service principal access is defined by API permissions and role assignments — which are human decisions made at registration time. Those decisions aren't reviewed, updated, or revoked when the application's purpose changes. IAM0.4 found the Data Migration Tool with 12 application permissions 11 months after the migration completed. The permissions were granted by a human. The human left. The permissions persist. Service principals need governance precisely because the human decisions that created them aren't revisited.
Wait for Entra Agent ID to reach general availability, since it provides a unified governance model for all non-human identities including service principals. d
Entra Agent ID is specifically for AI agent identities, not for all non-human identities. Service principals have their own governance tools (Workload ID Premium for CA, owner-based app reviews in Governance). Waiting for Agent ID doesn't address the 347 app registrations with 31 expired credentials and zero governance that IAM0.4 identified. Service principal governance is available now through existing mechanisms. Agent governance (Module 11) is a separate concern for a different identity type.
Scenario 6. Your governance state assessment from IAM1.7 produces a baseline score. Between Q1 and Q2, the score drops in the non-human identity domain because developers created 28 new app registrations for a product launch — none with ownership, credential policies, or permission reviews. Your assessment is quarterly. What does this gap tell you about the governance model?
The quarterly cadence is too infrequent. Switch to weekly assessments to catch app registration creation within 7 days. a
Weekly assessments detect the problem faster but don't prevent it. You'd still have 28 ungoverned app registrations — you'd just know about them within a week instead of within a quarter. Detection cadence isn't the root issue. IAM1.7 established that assessments are detective controls, not preventive ones. The problem is that app registrations can be created without governance controls at the point of creation.
The developers should have been trained on governance requirements before the product launch. Add a mandatory governance training module to the developer onboarding process. b
Training helps but doesn't enforce. Developers under product launch pressure will prioritize functionality over governance procedures they learned in training three months ago. Training creates awareness. Policy enforcement creates compliance. The gap here is that the platform allows ungoverned creation — training doesn't compensate for missing technical controls.
The governance model is detective, not preventive. The assessment caught the degradation after it happened. A preventive model would require admin consent for new app registrations, enforce ownership at creation time, and set credential expiry policies by default — so ungoverned registrations can't be created in the first place. c
This is the correct diagnosis. The quarterly assessment is valuable for trend tracking and reporting to leadership, but it operates after the fact. IAM1.7 positioned the assessment as a baseline and progress measurement tool — not as a governance enforcement mechanism. The preventive controls (admin consent, mandatory ownership, default credential policies) are what Module 7 builds. The assessment tells you the controls are working. The controls do the actual governing.
Restrict app registration creation to Global Administrators only. This prevents developers from creating ungoverned registrations. d
This prevents the problem but creates a bottleneck that slows development velocity. Global Administrators shouldn't be creating app registrations — that's an operational task, not a tenant-level decision. The right approach is scoped delegation: assign Application Developer or a custom role with app registration creation rights, require admin consent for permissions above a defined threshold, and enforce ownership at creation time. Restriction without delegation pushes developers to find workarounds — which creates a worse governance gap.
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
Thank you — your feedback has been received.
© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.
You're reading the free modules of Identity and Access Management in Microsoft 365
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.