CISSP Domain 5, Identity and Access Management, is the domain where most modern breaches actually start. Stolen credentials, weak MFA, federated trust gone wrong, or an over-privileged service account: these are the failure modes behind the headlines. Domain 5 is weighted at 13% on the exam and rewards candidates who think about identity not as a single login event but as a lifecycle - from request to provisioning to authentication to authorisation to monitoring to deprovisioning.
This guide collects the 14 in-depth Domain 5 articles on Threat on the Wire into one structured reference. Use it as a study path or a topic index. Every article assumes you already know what a username and a password are, and want clarity on how identity systems actually work and break in the enterprise.
What Domain 5 is really testing
CISSP lens: the right answer treats identity as a lifecycle. Pick the option that strengthens the weakest stage - usually authentication or deprovisioning, not authorisation.
Domain 5 has three big themes. First, the foundational one: who is acting (authentication), what they are allowed to do (authorisation), and how you know what they did (accountability). Second, the architectural one: how to deploy identity at scale across cloud, on-premise, and federated environments. Third, the operational one: how to manage the identity lifecycle so credentials do not become tomorrow's incident.
You will be tested on:
- Identity management fundamentals: provisioning, deprovisioning, JML (joiner / mover / leaver).
- Authentication methods and factors: knowledge, possession, biometric, location, behaviour.
- Multi-factor authentication: TOTP, push, FIDO2, hardware tokens.
- Authorisation and least privilege: roles, attributes, policies.
- Access control models: DAC, MAC, RBAC, ABAC, RuBAC.
- Federation and single sign-on: SAML, OAuth 2.0, OpenID Connect.
- Directory services: LDAP, Active Directory, cloud directories.
- Identity governance and administration (IGA).
- Privileged access management (PAM).
- Zero Trust principles applied to identity.
- Biometric systems: accuracy, error rates, privacy.
- Identity attacks: credential stuffing, phishing, MFA fatigue, session hijack.
- Physical access control: badges, biometrics, mantraps.
- Accountability, monitoring, and session management.
How Domain 5 fits into the rest of the CBK
Domain 5 is the operational engine room of every other domain. The classification labels assigned in Domain 2 drive access control decisions here. The cryptography of Domain 3 protects the credentials and tokens here. The network access control in Domain 4 enforces identity at the network layer. The application access control inside Domain 8 applications is Domain 5 reasoning applied at the code level.
If a Domain 7 question is about insider threat detection, the underlying mechanics are Domain 5 - account anomalies, privilege escalation, session anomalies. Master Domain 5 and you make six other domains easier.
Core concepts at a glance
| Concept | What it is | Why it matters on the exam |
|---|---|---|
| Identification | Asserting who you are (username, ID) | Step 1; not security on its own |
| Authentication | Proving who you are (password, token, biometric) | Step 2; where most attacks succeed or fail |
| Authorisation | Deciding what you can do | Step 3; usually role- or attribute-based |
| Accountability | Recording what was done | Step 4; depends on identification + monitoring |
| Authentication factors | Something you know / have / are / where you are / what you do | MFA combines factor types, not just credentials |
| DAC | Discretionary Access Control: owner decides | Default in commercial systems; flexible but inconsistent |
| MAC | Mandatory Access Control: system enforces labels | Government / military; based on classification |
| RBAC | Role-Based Access Control | Most-tested model; pair role with permissions |
| ABAC | Attribute-Based Access Control | Modern, policy-driven; increasingly favoured |
| SAML | XML-based federated authentication | Common for enterprise SSO to web apps |
| OAuth 2.0 | Authorisation framework, not authentication | The exam will test this distinction |
| OpenID Connect | Authentication layer on top of OAuth 2.0 | Modern web/mobile SSO |
| JML | Joiner / Mover / Leaver lifecycle | Where most identity programs fail (Mover and Leaver) |
| PAM | Privileged Access Management | Vault, session record, just-in-time access |
Identity management fundamentals and the lifecycle
Identity is not a moment; it is a lifecycle. The exam tests joiner / mover / leaver scenarios because that is where real programs break. Joiners are easy - everyone wants the new hire to start working. Movers are harder - when someone changes role, their old access should disappear, but rarely does. Leavers are hardest - the day someone leaves is the day stale access becomes a real risk.
Start with Identity Management Fundamentals: The Foundation of Who Gets Access to What. Then read Access Control Administration: Managing Access at Enterprise Scale for how the lifecycle is actually run.
Authentication methods and technologies
Authentication is the single most-attacked layer of the identity stack. Authentication Methods and Technologies: Something You Know, Have, and Are covers passwords, OTP, push notifications, hardware tokens, certificates, and the modern phishing-resistant factors (FIDO2, passkeys).
Relative strength of authentication factors
| Factor | Strength | Typical attack |
|---|---|---|
| Password alone | Weak | Phishing, credential stuffing, password reuse |
| Password + SMS OTP | Moderate | SIM swap, SS7 interception |
| Password + TOTP (authenticator app) | Good | Phishing of the OTP; not phish-resistant |
| Password + push notification | Good | MFA fatigue (push spam) |
| FIDO2 / passkey + biometric | Strong | Phishing-resistant; key device theft is the attack |
| Certificate-based + smart card | Strong | Card theft; PIN compromise |
The exam favours phishing-resistant MFA (FIDO2, passkeys, smart cards) for high-value scenarios and tests the failure modes of weaker forms.
Biometric systems
Biometrics is unique on the exam because the maths is testable. Biometric Systems in Depth: Accuracy, Privacy, and Implementation Realities covers the FAR / FRR / CER vocabulary and the privacy and trade-off issues that matter for actual deployments.
Biometric error-rate vocabulary
- FAR (False Acceptance Rate): the system accepts an unauthorised user. The dangerous error.
- FRR (False Rejection Rate): the system rejects an authorised user. The annoying error.
- CER (Crossover Error Rate): the threshold where FAR equals FRR. Lower CER means a better system overall.
- Threshold tuning: moving the threshold trades FAR for FRR. High-security systems lower FAR (accepting more FRR); convenience-focused systems do the opposite.
Authorisation and access control models
Authorisation is what someone can do once they have authenticated. The exam tests the access control models heavily and expects you to recognise which model fits which situation.
Read Access Control Models: DAC, MAC, RBAC, ABAC, and Choosing the Right One for the model breakdown. Pair with Authorization and the Principle of Least Privilege for the policy-side reasoning - because in practice, the access control model is only as good as the access decisions baked into it.
IAM architecture: directories, SSO, federation
The exam tests three architectural patterns: centralised directory (LDAP, Active Directory), single sign-on within an organisation, and federated identity across organisations.
Read Directory Services and LDAP Security: Protecting the Source of Truth for Identity. Then Single Sign-On and Federated Identity: One Login to Rule Them All Safely, which covers SAML, OAuth 2.0, OpenID Connect, and the failure modes (broken assertions, replay, IdP compromise) that make federation dangerous when done badly.
Federation protocol decision table
| Protocol | Authentication or Authorisation | Typical use |
|---|---|---|
| SAML 2.0 | Authentication (with attribute assertions) | Enterprise web app SSO |
| OAuth 2.0 | Authorisation (delegated access) | API access on behalf of a user; not authentication on its own |
| OpenID Connect | Authentication built on OAuth 2.0 | Modern web/mobile SSO |
| WS-Federation | Authentication | Older Microsoft-stack federation; less common now |
| Kerberos | Authentication | On-premise, ticket-based; AD environments |
IGA and privileged access management
Identity governance and administration is the management layer that decides who gets access, reviews it periodically, and certifies it. Privileged access management is the specialised stack for the small set of accounts that can do significant damage.
Read Identity Governance and Administration: The Management Layer of IAM. Pair with the operational practices in Domain 7's operational IAM article.
Zero Trust applied to IAM
Zero Trust is not just a network concept; it reshapes how identity systems work. Zero Trust Architecture for IAM: Never Trust, Always Verify, Everywhere covers the principles - continuous verification, identity as the new perimeter, conditional access, device posture, behavioural analytics - and how they apply to authentication and authorisation decisions.
Identity attacks and defences
The exam tests the modern identity attack catalogue: credential stuffing, phishing, password spray, MFA fatigue, session hijack, token replay, golden ticket. Identity Attacks and Defenses: How Attackers Exploit Identity and How to Stop Them covers what each attack looks like and what stops it.
Once an attacker is in, the question becomes how quickly you detect the abnormal behaviour. Accountability, Monitoring, and Session Management: Knowing Who Did What and When covers session controls, audit logging, and the monitoring that turns "credentials stolen yesterday" into a contained incident rather than a breach.
Physical access control
Identity is not just digital. Physical Access Control Systems: Badges, Biometrics, and Barriers covers the controls that gate physical entry: card readers, mantraps, anti-passback, multi-factor physical access, and the integration with logical identity systems that prevents tailgating-style social engineering.
Real-world IAM scenarios
An IAM lead is told a senior engineer is leaving the company at end of week. The technical instinct is to disable the AD account on Friday at 5pm. The IAM lead instinct is broader. First, run a deprovisioning checklist that captures every system the engineer had access to - on-prem, cloud, SaaS, code repositories, signing keys, hardware tokens. Second, identify shared credentials they knew (vaults, service accounts) and rotate those before disabling personal access. Third, review what they did in the last 30 days for anything that needs reverting. Fourth, transfer ownership of artefacts (documents, scripts, dashboards) to peers. Fifth, the AD disable on Friday is just the visible step; the real work is the rest. Domain 5 questions reward this lifecycle-aware sequence.
A second example: a CISO learns a third-party SaaS vendor has been compromised, including their identity-provider integration with the company's SSO. The technical instinct is to revoke the SAML federation. The architect instinct is layered: first revoke trust at the federation level, second rotate any session tokens that may have been issued, third audit the apps that allowed the IdP to write attributes (privilege escalation risk), fourth check whether any service-account tokens are exposed, fifth communicate to users about session re-auth. The exam tests each of these steps as an option in scenario questions.
Common exam traps in Domain 5
- Treating OAuth 2.0 as authentication. OAuth 2.0 is authorisation. OpenID Connect is authentication built on top of OAuth. The exam will test this distinction with subtle wording.
- Picking RBAC for a federated cross-organisation scenario. RBAC works inside an organisation. ABAC and federation handle cross-organisation context (attributes can carry across trust boundaries).
- Confusing authentication factor types with vendor categories. "SMS" and "TOTP" are both possession-factor implementations of "something you have," not separate factor types.
- Calling biometric the strongest factor. Biometric is convenient but not necessarily strongest. FIDO2 + biometric is strong; biometric alone is roughly equivalent to a long password and is harder to replace if compromised.
- Ignoring deprovisioning. The exam will test "the user has left the company" scenarios where the wrong answer is to focus on the new hire backlog. Deprovisioning is the higher-priority question.
- Picking PAM as the answer to every privilege question. PAM is one tool; least privilege, role review, and just-in-time access are the broader strategies. The exam tests these as a system, not as a product.
- Forgetting accountability requires identification. Shared accounts break accountability. The exam tests this with shared-credential scenarios.
The full Domain 5 reading order
Identity fundamentals and lifecycle
Authentication
Authorisation and access models
IAM architecture
Governance and zero trust
Attacks, monitoring, accountability
Physical access
Exam scenario practice
Related CISSP domains
Threat on the Wire publishes a long-form pillar for every CISSP domain. The eight domains are interlocked - mastering any one of them is easier when you can see how it connects to the others. Here's how this domain relates to the other seven, with a one-line summary of the relationship and a link to the pillar.
| Pillar | How it relates to this domain |
|---|---|
| Domain 1: Security and Risk Management | Personnel security and ethics in Domain 1 frame the identity lifecycle. |
| Domain 2: Asset Security | Classification from Domain 2 drives access control decisions made here. |
| Domain 3: Security Architecture and Engineering | Authentication factors and PKI from Domain 3 underpin IAM mechanisms. |
| Domain 4: Communication and Network Security | Network access control bridges Domain 4 networking to identity decisions. |
| Domain 6: Security Assessment and Testing | Identity controls get audited in Domain 6 control testing. |
| Domain 7: Security Operations | IAM is operated daily as part of Domain 7 security operations. |
| Domain 8: Software Development Security | Application identity is Domain 5 reasoning applied at the code level in Domain 8. |
For the full CISSP overview, exam structure, and 12-week study plan, see the CISSP Study Hub.
Frequently asked questions
How much of the CISSP exam covers Domain 5?
Domain 5 is weighted at 13% of the exam. Out of roughly 100-150 items, expect 13-20 from Domain 5 directly. The reasoning shows up in many more questions across other domains because identity is the substrate for almost every security decision.
When does the exam want RBAC vs ABAC?
RBAC for environments where roles are stable and well-defined - HR, finance, fixed organisational structures. ABAC for environments where access decisions need richer context - cloud workloads, federation across organisations, dynamic data classifications. The exam favours ABAC for modern scenarios involving cloud, dynamic policy, or attribute-rich identity.
Is MFA always two factors?
Multi-factor authentication is two or more factors of different factor types. Two passwords are not MFA. Password plus SMS OTP is MFA (knowledge plus possession). Password, fingerprint, and hardware key is MFA (knowledge plus inherence plus possession). The exam will offer "two passwords" as a wrong answer to look like MFA.
When should I pick SAML over OpenID Connect?
SAML for enterprise web-app SSO, especially with legacy identity providers and corporate directories. OpenID Connect for modern web and mobile applications, especially when you also need authorisation flows (OAuth 2.0 underneath) for APIs. New deployments increasingly default to OIDC; SAML remains common in established enterprise stacks.
Why does the exam care so much about deprovisioning?
Because that is where most identity programs fail in the real world and where most insider-threat incidents start. Joiner provisioning has business pressure behind it; deprovisioning has none. Stale accounts, orphaned access, and forgotten service accounts are the breeding ground for credential theft. The exam tests the leaver scenario because the right answer there is the one that catches the systemic failure point of the program.
Key takeaways
- Domain 5 is identity as a lifecycle, not as a login event. Joiner / Mover / Leaver is the testable frame.
- Identification, authentication, authorisation, accountability are the four steps. Each has its own controls and its own failure modes.
- MFA combines factor types (knowledge, possession, inherence, location, behaviour). Two of the same type does not count.
- Access control models pair to scenarios: DAC for commercial flexibility, MAC for classified data, RBAC for stable enterprise roles, ABAC for dynamic context-rich decisions.
- OAuth 2.0 is authorisation; OpenID Connect is authentication on top of OAuth. SAML is authentication for enterprise web SSO.
- Federation extends identity across trust boundaries. The protocols are the mechanism; the trust agreement is the architecture.
- Identity governance and privileged access management are the operational programs that prevent identity sprawl. Zero Trust shifts the architectural frame from "trust the network" to "verify every request."
If you take one thing away from Domain 5, take this: most modern breaches are identity breaches in disguise. Build identity as a lifecycle, lean on phishing-resistant MFA, and the rest of the security program gets dramatically easier.