1 Identity vs Account vs Entitlement
Three terms every IGA product is built around:
asmith in Active Directory, alice.smith@example.com in Salesforce, ASMITH8 in SAP.Sales_Manager in Salesforce, Finance_Read in SAP, VPN-Users in AD.IDENTITY
├─ Account → Entitlements
├─ Account → Entitlements
└─ Account → EntitlementsOne identity, several accounts, each with its own entitlements. This means applications may identify the same person with completely different fields — HR's employeeID = 72819, AD's sAMAccountName = jsmith, Entra's userPrincipalName = john.smith@example.com, Salesforce's username = john.smith@example.com, SAP's userID = JSMITH27. The IAM platform's job is to correlate every one of those back to one human identity — never trust a single identifier blindly, because none of them alone is guaranteed unique or stable across every system.
2 IAM vs Authentication vs SSO
A simplified model connects everything from Module 9 and this module:
Identity → Authentication → Authorization → AccessIAM manages the whole environment around those steps: HR says Alice is employee 12345; IAM says Alice should have Salesforce; provisioning says create Alice in Salesforce; authentication says Alice successfully proved her identity; authorisation says Alice is allowed to use the Sales dashboard. Each layer does a genuinely different job.
SSO is only one component of IAM — an organisation can have flawless SSO and terrible identity lifecycle management at the same time. An employee who leaves can no longer authenticate through corporate SSO, but their GitHub account, AWS access key, VPN certificate, or a local application password may still work perfectly well. SSO alone never solves identity lifecycle problems; that's what Lesson 4's Joiner-Mover-Leaver process is actually for.
3 Zero Trust and IAM
Modern Zero Trust approaches place identity at the centre. Traditional thinking: "inside the corporate network = trusted." Modern thinking evaluates identity, device, risk, location, authentication strength, the requested resource, and privilege level together, every time. Identity is one of the central control planes of Zero Trust security (Module 8, Section 13; Module 9, Lesson 2) — not a separate concern bolted onto it.
4 IAM Logs
IAM investigations routinely require correlating logs across several systems at once:
HR event → IAM lifecycle event → Provisioning request
→ SCIM request → Application response
→ Authentication log → Application auditUseful fields: timestamp, user ID, employee ID, application, action, source IP, target identity, HTTP response, role, entitlement, approver, provisioning status, and a correlation ID — particularly valuable for tracing one identity transaction as it moves across several distinct systems and logs.
5 Troubleshooting Methodically
Alice should have Salesforce but can't log in. Don't immediately assume Salesforce is broken — trace the identity from source to destination instead:
- HR — does Alice exist, with
employeeStatus = Active? - IAM — was the identity imported and a role calculated?
- Provisioning — was a request attempted, and did it succeed (
201 Created) or fail (400/401/403/429/500)? - Application — does Alice's account exist, and is it active, with the right username and licence?
- Federation — is Alice being redirected to the IdP successfully?
- Authentication — did MFA succeed?
- Claims — did the IdP send the expected claims?
- Authorisation — does the application map Alice's identity to the correct permission?
A simple support ticket becomes an end-to-end identity investigation — and knowing this eight-step order is usually the difference between resolving it in ten minutes and resetting the wrong thing three times first.
6 Common IAM Incidents & Security Risks
More broadly, poor IAM controls lead to excessive privileges, shared accounts, orphan and dormant accounts, weak service-account management, incorrect role assignment, missing access reviews, failed deprovisioning, excessive admin rights, compromised federation certificates, insecure provisioning APIs, exposed API tokens, poor privileged-account monitoring, weak contractor lifecycle management, and misconfigured guest access. Identity has increasingly become a primary security perimeter — protecting it is now just as important as protecting the network.
7 What an IAM Engineer Actually Does
IAM engineering work spans integrating applications with SSO, configuring SAML/OIDC, developing provisioning integrations, troubleshooting SCIM, managing directories, designing roles, implementing lifecycle workflows, configuring access requests, maintaining identity connectors, managing federation certificates, investigating failed provisioning, implementing MFA, reviewing privileged access, working with HR/app-owner/compliance teams, analysing logs, building APIs, writing PowerShell automation, supporting mergers and acquisitions, and improving JML workflows.
That's why it's one of the most multidisciplinary areas of cybersecurity — it draws on identity, networking, HTTP, APIs, JSON/XML, authentication, authorisation, directories, cloud, security, scripting, databases, and plain business-process understanding, all at once.
Skills worth building
A junior IAM engineer should gradually get comfortable with Active Directory, Entra ID, LDAP, SAML, OAuth, OpenID Connect, SCIM, REST APIs, JSON, XML, HTTP, JWT, PowerShell, Linux, SQL, certificates/PKI, MFA, RBAC, and access governance. You don't need to be an expert in every one of these — you need to understand how they all fit together, which is exactly what this module and Module 9 together were designed to build.
8 Interview Questions
Lab Lab 1 – Day-One Access Investigation
A user reports: "I started today and I can access Outlook, but I cannot access Salesforce."
🔮 Predict first
Using the 8-step trace from Section 5, write out your investigation order before reading on. Where's the most likely place this breaks on someone's actual first day?
Reveal a likely finding
On a genuine first day, the most common break point is provisioning itself — the SCIM request to Salesforce either never fired or failed, often because the Salesforce role hadn't finished calculating from the employee's department/job attributes yet. Outlook working while Salesforce doesn't is actually a useful clue: it tells you the HR → IAM → identity-creation steps clearly worked (since Outlook needed those too), which narrows the search to steps 3 onward rather than starting from zero.
Lab Lab 2 – Security Incident: Session Survives Termination
An employee is dismissed at 14:00. At 14:45, security discovers their Salesforce session is still active.
🔮 Predict first
List the questions you'd investigate, in order, to find out why the session survived.
Reveal the investigation path
Was HR actually updated at 14:00? Did IAM receive the termination event? Was Entra disabled? Were sessions specifically revoked (not just the account)? Did Salesforce receive a SCIM deactivation request? Did Salesforce actually terminate the existing session, or only block new logins? Were API tokens revoked separately? This demonstrates exactly why Lesson 4's point stands: identity lifecycle security extends well beyond disabling one directory account — a live session, once established, doesn't automatically die with the account that created it.
A Complete Lifecycle, Start to Finish
Sarah Patel joins as a SOC Analyst.
That's the entire Joiner → Mover → Leaver lifecycle, in one person's five-year story.
Module 10 Outcome
The core architecture worth remembering:
HR → Identity → IAM/IGA → AD / Entra / Apps → SSO
→ Authentication → Authorization → AccessSurrounded, at every stage, by Least Privilege, RBAC, Access Reviews, Audit, Provisioning, Deprovisioning, and Security Monitoring.
A mature IAM environment should ensure the right identity gets the right access to the right resource, for the right reason, at the right time — and loses that access the moment it's no longer required. The security question was never just "can the user log in?" It's should this identity exist, should it have this access, exactly what should it be able to do, who approved it, can we prove why it exists, and will it be automatically removed when it's no longer needed?
Across all 6 lessons, you should now be able to explain least privilege, RBAC and ABAC; provisioning and SCIM; SSO and federation; the full Joiner-Mover-Leaver lifecycle, including contractors, guests, service accounts and workload identities; how Directory/IdP/IGA/PAM differ and how a real global enterprise's IAM architecture is assembled from all of them; and how to investigate an IAM problem methodically instead of guessing.
This module also sets up Module 11 (Security Operations) directly: identity telemetry — suspicious logins, privilege changes, account creation, impossible access patterns, dormant-account usage, token abuse, and failed provisioning/deprovisioning events — is one of a SOC's most important detection sources, and you now have the IAM vocabulary to actually read it.