CISSP IAM questions are sneaky. The concepts look simple — you've probably configured access controls on a hundred systems — and that familiarity is the trap. The exam doesn't test whether you can set up RBAC in Active Directory. It tests whether you can read a four-sentence scenario and instantly tell which model the architects chose, why they chose it, and what they got wrong. That's a different skill, and it's the one Domain 5 is built around.
Domain 5 is roughly 13% of the exam. It's also where almost every other domain leans for context — software security, network security, and operations all assume you understand IAM. So the time pays back across the whole test. This post covers the concepts that actually move the needle: the IAA distinction, factor categories, the four access control models, federation, and the lifecycle stuff people forget about until a deprovisioning question shows up.
The IAA distinction (and why people lose easy points here)
I've watched experienced engineers throw away points on questions that hinge on the difference between authentication and authorization. They know both terms cold. They use them at work. But under exam pressure, with a scenario about a user "logging in and accessing the executive SharePoint," they conflate the two and pick a control that solves the wrong problem.
The cleanest way to keep these straight:
- Identification is the claim ("I'm Alice")
- Authentication is the proof ("here's my password / token / fingerprint")
- Authorization is the decision ("Alice is allowed to read this, not edit it")
Authentication answers "who are you?" Authorization answers "what are you allowed to do?" If a question describes someone who logged in successfully but couldn't reach a resource, you're in authorization territory, not authentication. Picking an MFA-related answer there is wrong even though MFA is "more secure."
Accountability is the fourth piece, often slipped in: the ability to trace an action back to an authenticated identity. Logging, audit trails, and non-repudiation all roll up here. You don't get accountability without strong authentication and shared accounts kill it on contact.
The five factor categories
Authentication factors fall into five buckets. You need to know the buckets, and you need to know what does not count as multi-factor when two things from the same bucket are combined.
Something you know — passwords, PINs, security questions. Cheap, weak by itself, still everywhere.
Something you have — hardware tokens, smart cards, phone-based authenticator apps. Possession-based.
Something you are — fingerprints, face, iris, voice. Reliable in the right conditions but introduces FAR/FRR tradeoffs and privacy headaches.
Something you do — typing cadence, mouse patterns, gait. Mostly used in continuous authentication and behavioral analytics.
Somewhere you are — geolocation, IP, Wi-Fi triangulation. Almost always supplemental, rarely a primary factor.
Multi-factor authentication means combining factors from different categories. Password + PIN is not MFA — both are something you know. Password + token is. This is one of those places where the exam writes a question that looks like it's about MFA strength and is actually about whether you can count categories. If you see two "knowledge" things and the answer choices include "this is true MFA," it isn't.
Beyond factors, there are a handful of authentication patterns CISSP expects you to recognize. Single sign-on reduces password fatigue but concentrates blast radius — when the IdP goes down, everything goes down with it. Passwordless authentication (FIDO2/WebAuthn is the standard worth knowing by name) replaces shared secrets with cryptographic device-bound keys. Continuous authentication and risk-based authentication both adjust trust dynamically based on signals; the difference is mostly that risk-based usually triggers a step-up challenge while continuous quietly re-evaluates in the background.
Access control models — the part you cannot fake
This is the most heavily tested topic in Domain 5. If you only have time to drill one IAM area, drill this. The exam will hand you a scenario that describes how access is granted, and you need to identify the model fast — sometimes inside a question that's nominally about something else.
The four models are DAC, MAC, RBAC, and ABAC. Memorizing definitions doesn't work as well as memorizing the signal in a question that points to each one.
DAC is "the owner decides." Unix file permissions are the canonical example. You created the file, so you decide who reads it. DAC is flexible and easy to use, but it's almost impossible to govern at scale because owners give away access inconsistently and there's no central policy to fall back on. If a question describes a file owner choosing who else can access something, that's DAC.
MAC is "central policy decides, based on labels." Subjects have clearances, objects have classifications, and access depends on both matching the policy. The classic example is government classified data — a Secret-cleared user can read Confidential and Secret documents but not Top Secret, regardless of what the document's owner thinks. The two MAC models worth knowing by name are Bell-LaPadula (confidentiality, "no read up, no write down") and Biba (integrity, the inverse). If clearances and classifications appear in the scenario, the answer is MAC.
RBAC is "permissions follow the role, not the person." This is what most enterprises actually run on. New hire in Accounting? Assign the Accountant role and they inherit the permission set. Promote them to manager? Swap the role. RBAC scales much better than DAC and is much simpler to govern than ABAC, which is why it dominates ERP and most business systems. Watch for "role explosion" as a distractor — when an org defines so many overlapping roles that the model collapses under its own weight.
ABAC is "evaluate attributes at request time." Access is decided by rules over attributes of the user, the resource, the action, and the environment. "Allow if user.department == Finance AND resource.classification == Internal AND time == business_hours AND source_ip in corporate_range." It's the most expressive model and the right answer for modern cloud and zero-trust scenarios, but it's also the hardest to design, audit, and reason about. If a question describes context-aware decisions made dynamically at request time — especially if multiple attributes are evaluated together — it's ABAC.
A reference table for fast pattern matching:
| Signal in the question | Model |
|---|---|
| Object owner decides who gets access | DAC |
| Clearances, classifications, labels, "no read up" | MAC |
| Permissions assigned to a job function, inherited by people | RBAC |
| Decisions evaluated at request time using user/resource/environment attributes | ABAC |
One pattern I've noticed: candidates who consistently miss model-identification questions are usually picking the model they'd architect if they were building the system, not the one the scenario actually describes. The exam isn't asking what you'd choose. It's asking what's there.
Federation, in the form the exam tests it
Federation lets a user authenticated in one system access resources in another without separate credentials. The mechanics matter less than the standards, because the exam will absolutely write a question that mixes them up to see if you can untangle them.
SAML is XML-based, mature, and used heavily for enterprise SSO. The user authenticates at their Identity Provider, which sends a signed assertion to the Service Provider. SAML is for authentication.
OAuth 2.0 is for authorization. It hands out access tokens that let one service act on behalf of a user against another service's API. "Login with Google" is technically not what OAuth was designed for — it's been bolted on. Plain OAuth doesn't give you a verified identity.
OpenID Connect (OIDC) is the layer that does. It's authentication built on top of OAuth 2.0, adding identity claims to the access token flow. Most modern web authentication you'll see in the wild is OIDC, even when people call it "OAuth login."
The exam trap to watch for: OAuth being presented as an authentication solution. It isn't, by itself. If a scenario calls for verifying user identity across systems and the only OAuth answer doesn't mention OIDC, that answer is incomplete.
The identity lifecycle and why deprovisioning is where audits go bad
The lifecycle covers everything from the day a user gets created to the day their access is fully removed. Provisioning, maintenance, periodic review, deprovisioning. None of this is conceptually hard. What the exam tests is whether you understand which stages tend to fail in practice.
The answer is almost always deprovisioning. Orphaned accounts — credentials that stay active after someone leaves or moves teams — are one of the most common audit findings in real environments. SOX, PCI DSS, and HIPAA all care about this. If a scenario describes a former employee whose account was still active months after departure, the failure point is deprovisioning, and the corrective control is usually some combination of automated deprovisioning tied to HR systems plus periodic access reviews.
Privileged Access Management (PAM) sits adjacent to all of this. It's the umbrella for the controls you wrap around admin and service accounts: just-in-time elevation, session recording, credential vaulting, automated rotation. Expect at least one question that asks for the right control to apply to a high-privilege account, and PAM-flavored answers usually win.
Other failure patterns the exam likes to test: privilege creep (users accumulating permissions across role changes without ever losing the old ones — violates least privilege), shared accounts (kill accountability, never the right answer for any production scenario), and MFA fatigue / push bombing (mitigated by number-matching MFA and rate-limited push prompts). When you see a scenario that describes a user accumulating permissions over years of role changes, the diagnosis is privilege creep and the control is access reviews.
How to actually study this domain
If you're already comfortable with one or two of these areas — say, you've worked in IAM at an enterprise and RBAC is second nature — don't waste time re-reading what you already know. The leverage is in the models you don't use day to day. For most engineering-background candidates, that's MAC and the formal models (Bell-LaPadula, Biba). For most governance-background candidates, it's the federation standards.
The best preparation is question-driven. Read a scenario, identify the model or control, check the explanation. Repeat until pattern recognition is automatic. Reading definitions over and over feels productive but plateaus quickly — what you actually need is reps on scenarios where the right answer hinges on a subtle distinction.
If you want a baseline before you start drilling, the LearnZapp CISSP diagnostic gives you a per-domain breakdown in about 30 minutes — free, no signup. You'll see whether IAM is actually one of your weak areas or whether your time is better spent elsewhere. Domain 5 pairs naturally with Domain 3 cryptography (most authentication mechanisms rely on it) and the overall domain breakdown is worth a skim if you haven't mapped the eight domains to your study plan yet.