Wide uses the full column for everything, text, diagrams, code, and exercises. Narrow keeps the standard reading width.
Text size
Scales the body text. Headings and code blocks keep their size.
In this section
▾
Microsoft 365 Identity and Access Management: Course Orientation
Module 0
MICROSOFT 365 IDENTITY AND ACCESS MANAGEMENT · MODULE 00
Stop managing accounts. Govern identity as a program.
Most organizations have identities; few have a governed identity program. This course teaches you to build one, where every identity, human and machine, has an owner, a lifecycle from join to leave, least-privilege access granted through entitlement management, recertified through access reviews, with compliance evidence at every step. You design it with Entra ID Governance, PIM, and the Graph, and you record the decisions as architecture you can defend. This module shows you what you'll build, the lifecycle you'll govern, and how the course gets you there.
17 modules
across 6 phases
20+ ADRs
architecture decisions you keep
A program
not a pile of settings
No prerequisites
every concept built up
Why this course exists
Identity is where breaches begin, but the deeper problem in most tenants is not a missing security control, it is that identity is ungoverned. Accounts accumulate access nobody reviews. Service principals and workload identities run with permissions nobody owns. Leavers keep working logins. Access is granted ad hoc and never recertified, and when the auditor asks who approved it and when it was last checked, there is no answer. That is not an attack, it is the absence of a program, and it is what turns a single compromised identity into a breach with nothing to stop it spreading.
This course teaches you to close that gap by governing identity as a program. Every identity, human and machine, gets three things: an owner who is accountable for it, a lifecycle that provisions it, grants least-privilege access, recertifies that access, and retires it, and compliance evidence that proves all of it happened. You build that with the real machinery, user and group architecture, authentication and Conditional Access, application and workload identity governance, privileged access, entitlement management, and access reviews, and you record each significant choice as an architecture decision record so the program is one you, and an auditor, can defend.
What you will be able to do
This course is built around the program you can run at the end, not the features you can name. Every module governs one part of the identity estate and produces a piece of the whole.
Architect users, groups, and roles
Build the user provisioning, group strategy, and role-based access that the rest of the program depends on.
Engineer authentication and access
Move to passwordless and design a Conditional Access architecture that enforces access decisions consistently.
Govern apps and workload identity
Bring OAuth consent, app registrations, service principals, and workload and AI-agent identities under ownership and control.
Architect privileged access
Design the admin model and delegation, and use PIM and just-in-time activation to replace standing privilege.
Operate the identity lifecycle
Run joiner, mover, and leaver operations, entitlement management, and access reviews and certification as standing processes.
Monitor, detect, and prove compliance
Stand up IAM monitoring and detection, generate compliance evidence, and assemble it all into a complete program in the capstone.
You also leave with things you keep: more than twenty architecture decision records documenting the choices behind the program, governed lifecycle and access-review processes, and a complete IAM program package from the capstone, where every identity, human and machine, has an owner, a lifecycle, and compliance evidence.
The lifecycle you will govern
A governed program treats every identity the same way, whether it is a human user or a machine or workload identity. The identity joins, is granted least-privilege access, is reviewed and recertified on a schedule, and eventually leaves, and at every stage it is tied to an owner who is accountable for it and a compliance record that proves the governance happened. That loop, not a one-time configuration, is what an audit asks about and what stops access quietly accumulating. This course builds and operates every stage of it.
You build this in Northgate Engineering's Entra tenant, which starts with 810 users and no formal program, using Entra ID Governance, entitlement management, access reviews, PIM, and the Graph and PowerShell to operationalize it, and a free M365 E5 developer tenant gives you a live environment to deploy and test every process. The discipline is what carries: ownership, lifecycle, least privilege, recertification, and evidence are how you govern identity on any platform, so the program you design here ports to SailPoint, Saviynt, Okta, and any identity governance suite. Entra is the implementation; identity governance is the skill.
How the course is built
Seventeen modules move through six phases, then a capstone and reference. You ground the foundations, govern user identities, then authentication and access, then applications and workload identities, then privileged access, then the lifecycle and governance itself, and assemble the complete program at the end.
What you need and who this is for
There are no prerequisites, and every concept is explained the first time it appears. This course is for anyone responsible for identity as more than account creation: identity and security architects designing the model, IAM and governance practitioners running the program, administrators moving from managing identities to governing them, and GRC and compliance people who need identity controls that actually produce evidence.
Transferable governance discipline
Ownership, lifecycle, least privilege, recertification, and evidence govern identity anywhere. Entra is the implementation; the program ports to SailPoint, Saviynt, Okta, and beyond.
A live tenant to build in
A free M365 E5 developer tenant gives you a real Entra environment to deploy and test every process, review, and policy against an 810-user estate.
How to get the most
Build each part of the program in your own tenant, and write the decision down as an ADR. Keep the ADRs and processes that work, that is how your governed program gets assembled.
Do I already know this material?
Six quick scenarios across the full range of this course, from role-based access to running IAM as an ongoing program. Answer them to find out where you sit, and whether this course fits or it will sharpen knowledge you already have.
You are granting access to a growing team. What scales better than assigning permissions to each user individually?
Give everyone admin to avoid repeated requests.
Role-based access through groups, so access is granted by role and membership, and changes propagate consistently as people join or change roles.
Per-user grants drift and do not scale. Role-based access through groups ties entitlements to a role, so onboarding, moves, and changes flow through membership instead of being rebuilt by hand for every person.
Assign permissions one user at a time.
Share a single account across the team.
An employee changes departments and accumulates access from both their old and new roles. What does good IAM require?
Access should follow the current role: as part of the mover process, access tied to the old role is removed, so entitlements match what the person actually needs now.
The mover stage of the joiner-mover-leaver lifecycle exists precisely for this. Access tracks the current role, so the old entitlements come off as the new ones go on, preventing the slow accumulation that becomes excess privilege.
Leave the old access in place; removing it is risky.
Grant even more access to be safe.
Wait until they leave the company to clean up.
Users in your tenant can consent to any third-party application, and you have seen consent-phishing attempts. What governance control addresses this?
Tell users to be careful.
Block all third-party applications forever.
Restrict user consent and route application permissions through an admin consent workflow, so risky or over-privileged applications are reviewed before they gain access.
Open user consent is exactly what consent phishing abuses. Restricting it and requiring admin review puts a governance gate in front of app access, blocking the over-privileged grant without banning legitimate apps outright.
Allow all consent to keep users productive.
A review finds many users hold access far beyond their needs, accumulated over years. What principle should the IAM program enforce?
Access is fine as long as nothing has gone wrong.
Least privilege: grant only the access a role requires, and treat accumulated, unused access as risk to be removed, since every extra entitlement widens the attack surface.
Every entitlement is something an attacker could use if that account is compromised. Least privilege keeps access matched to need and actively removes the build-up, shrinking the blast radius of any single compromise.
Grant broad access to reduce help-desk tickets.
Only restrict access for new hires.
How does a mature IAM program keep entitlements correct over time rather than drifting?
Set access once at onboarding and never revisit it.
Trust that managers will report changes.
Audit access only after an incident.
Periodic access reviews and certification, where owners reconfirm who should retain access and stale entitlements are removed, so access does not silently accumulate.
Access drifts upward unless something pulls it back. Scheduled reviews put a named owner on the question of who still needs what, and revoke the rest, which is how entitlements stay correct rather than only growing.
What best describes mature identity and access management?
A one-time project to configure roles and policies.
Whatever the identity vendor enables by default.
An ongoing governed lifecycle, provisioning, entitlement, review, and deprovisioning, with monitoring and clear ownership, not a setup you finish once.
Identity changes every day as people and apps come and go, so IAM is a running program, not a project with an end date. Provisioning through deprovisioning, reviewed and owned, is what keeps access correct as the organisation moves.
A purely technical task with no business involvement.
This course is for you.
You will build identity and access management from the Entra ecosystem and user identities through roles, Conditional Access, app and workload governance, privileged access, and the full IAM lifecycle.
You have the fundamentals. The value here is the harder half.
You understand roles and lifecycle, so the payoff is the back half: OAuth consent and app governance, workload and AI-agent identity, privileged access, entitlement management, access reviews, and operating the complete IAM program.
You handled role-based access, the mover lifecycle, consent governance, least privilege, access certification, and IAM as an ongoing program, the senior end of the discipline. Take the course to sharpen what you have, close the gaps you did not expect, and turn strong instincts into a governed IAM program.
You are a student of this course now, so start by deciding what you want from it. Are you here to build a governed program from a tenant that has none, to close the governance gaps that keep failing audit, or to design an identity architecture you can defend to a reviewer? Name that outcome, then turn it into a study plan: which phases and parts of the estate matter most to your environment, how much time you will give it each week, and what you want to have governed by the time you finish.
The rest of Module 0 sets you up to do exactly that. Work through it to see what identity and access management really is, what identity governance means, the lifecycle in your own tenant, the access governance principles, how non-human identity differs, the Northgate scenario you will work in, the lab setup, and the IAM program package you are building toward. Then begin Module 1.
Stuck on this lesson?
Your question goes straight to the team and we'll reply by email. Sign in to ask.
