Identification is the claim (username). Authentication proves it. Authorization decides what that proven subject may do. Accounting / accountability records the act so you can name one actor later. SSO is one login to many apps inside a trust domain. Federation is a signed assertion across organizations. OAuth 2.0 authorizes an API; OIDC and SAML authenticate a person. Least privilege is the floor for every account. PAM applies that floor to admin, root, service, and now AI-agent identities — vault, broker, record, elevate just in time, then revoke. If AD died and the SaaS login lived, deprovisioning across the federation failed. MFA on a dead account is not the first fix.
I do not stop at login. I prove the claim, grant the least right the job needs, log the act to one identity, and kill the account the same day the person or agent leaves — in the directory and in every federated app.
1. Why Domain 5 matters
ISC2 weights Identity and Access Management at 13% of the CISSP CAT (exam outline effective 15 April 2024). The official verbs are six: control physical and logical access, design identification and authentication, federate with a third party, implement authorization, manage the provisioning lifecycle, and implement authentication systems. The exam — and a real offboarding review — punish the same mistake: treating “they logged in once” as the whole of IAM.
That is the ticket in this lesson. HR closed the contractor. The directory disabled the human. The billing SaaS kept a local admin because nobody pushed deprovision across the trust. Authentication still succeeded. Authorization was still admin. Accounting could name the account — and nobody was watching it.
Manager lens
Who may exist, who may reach the crown jewel, who signs residual access, and how fast a leaver dies in every system — including partners, SaaS, and non-human identities.
Engineer lens
IdP, SP, assertion or token, group-to-role map, SCIM delete, vault checkout, session record. If you cannot show the field, you did not finish the control.
5.1 Physical and logical access to information, systems, devices, facilities, applications, services. 5.2 Groups and roles, AAA (MFA, password-less), session management, proofing, FIM, credential vaults, SSO, just-in-time. 5.3 Federation on-prem, cloud, hybrid. 5.4 RBAC, rule-based, MAC, DAC, ABAC, risk-based, PDP/PEP. 5.5 Access review, provision/deprovision, role transition, privilege escalation (sudo + audit), service accounts. 5.6 Authentication systems. ISC2 also threads AI-agent and non-human identities through this domain. Source: ISC2 CISSP Certification Exam Outline.
2. Mental model — IAAA and the lifecycle
Pre-train four words before the diagram. The 2024 outline writes AAA as Authentication, Authorization, and Accounting, with MFA and password-less as examples. Well-known CBK puts Identification in front so you do not confuse “I typed a name” with “I proved it.” Together that is the IAAA path this lesson uses. Shared accounts destroy the last A: you cannot hold one person accountable.
Read left → right, then the second row. A successful password is only Authenticate. Orphan SaaS admin is a lifecycle miss, not an MFA miss.
Identification — the claim of who you are (username, employee ID, workload ID).
Authentication — proof of that claim. MFA must mix different factor categories (know / have / are). Password + PIN is still one category.
Authorization — what the proven subject may do. Least privilege lives here.
Accounting / accountability — unique identity + tamper-resistant logs so one actor can be named. Shared “admin” kills this.
Proofing — establishing identity at registration (outline 5.2), before the first credential is issued.
IdP / SP — Identity Provider authenticates and asserts. Service Provider consumes the assertion and grants the app.
JIT — Just-in-Time. Outline 5.2 lists it next to SSO. Elevation exists only for the task, then dies.
PDP / PEP — Policy Decision Point decides; Policy Enforcement Point blocks or allows (outline 5.4).
Username is identification. MFA is authentication. The role or attribute policy is authorization. The log that names one person is accounting. Provision creates the subject. Recertification catches privilege creep. Deprovision must reach every federated app, or AAA still “works” for a ghost.
Authentication factors (outline 5.2, 5.6)
Something you know — password, PIN, passphrase. Something you have — hardware token, smart card, phone authenticator, passkey device. Something you are — biometric. Location and behavior can support a decision; they do not turn two “know” secrets into MFA. NIST SP 800-63-4 / 800-63B still grades authenticators by assurance level. Phishing-resistant authenticators (FIDO2 / WebAuthn passkeys) bind the private key to the device and the origin, so a fake login page cannot replay what it never received.
Biometric exam language: FAR (false accept, Type II) lets an impostor in — that is the security-critical error. FRR (false reject, Type I) locks a valid user out. CER is where FAR equals FRR; lower CER is the more accurate sensor. If the stem asks which error to minimize for high security, pick FAR.
Calling password + SMS OTP “phishing-resistant MFA.” It is two factors. A proxy can still relay the OTP in real time. Phishing-resistant means the authenticator will not answer a fake origin — passkeys, not “we added a second box.”
3. Decision flow — SSO, federation, protocol
Draw this before you buy an IdP or write “we have SSO” in a board pack. First decide whether trust stays inside one organization. Then decide whether you need to prove a person, delegate an API, or sync the account. Then pick the protocol that actually does that job.
Read top → down. Diamond one is the org boundary. Diamond two is the job. Magenta is the exam trap: OAuth is not an authentication protocol.
SSO means the user authenticates once and reaches many apps without retyping a password — usually inside one IdP domain. Federation (FIM, outline 5.2 / 5.3) is a trust relationship: their IdP signs an assertion; your SP accepts it. You can have SSO without federation (intranet portal). You can federate and still force a second factor at the SP. Writing “we deployed SSO” does not mean a partner’s users are governed, or that SaaS accounts die when AD dies.
4. How to choose models and protocols
ISC2 lists the authorization mechanisms by name in 5.4. The exam trick is almost always “who decides?” not “which acronym sounds modern.”
| If the stem says… | Model | Who decides | Watch for |
|---|---|---|---|
| Owner shares a file or mailbox | DAC | Resource owner | Flexible, easy to overshare. Not a classified-system answer. |
| Labels (Secret / Top Secret); even the owner cannot loosen | MAC | System / policy, via labels | Military / high-assurance. Need-to-know still applies. |
| Job title or “Accounts Payable Clerk” | RBAC | Role assignment | Role explosion; transfers that keep the old role (5.5). |
| Department + classification + device health + time | ABAC | Attributes + policy (PDP) | Powerful; needs clean attributes or it becomes un-auditable. |
| Same if-then for everyone (block after 21:00) | Rule-based | The rule, not the person | Firewall-like. Not a substitute for least privilege per job. |
| Step-up when risk score or impossible travel spikes | Risk-based | Risk engine + PDP | Adaptive / conditional access. Complements, does not replace, RBAC/ABAC. |
| Job | Prefer | Why | Do not pick |
|---|---|---|---|
| Browser SSO to enterprise SaaS | SAML 2.0 (or OIDC if the app is modern) | Signed assertion from IdP to SP | OAuth alone as “login” |
| Mobile / API-first app that must know who the user is | OIDC (ID token) + OAuth access token | OIDC is the identity layer on OAuth | Plain OAuth 2.0 for authentication |
| Third-party app reads an API; must never see the password | OAuth 2.0 scoped access token | Authorization / delegation, not identity | SAML or “share the bank password” |
| Create, update, disable accounts across apps | SCIM 2.0 | Provisioning protocol (RFC 7644) | Hoping JIT-on-login also deletes leavers |
| Intranet tickets inside one AD realm | Kerberos | TGT then service tickets; password not resent | Using Kerberos as a partner-federation protocol |
| High-value / admin login | Phishing-resistant MFA (FIDO2) + PAM | AAL3-class authenticator + no standing admin | Password + PIN, or SMS as the only second factor |
Least privilege and privileged access
Least privilege is not a PAM product. It is the rule that every subject — user, role, service account, AI agent — gets the minimum rights for the current task, then loses them. Outline 5.2 names just-in-time next to SSO. Outline 5.5 names privilege escalation (sudo and auditing its use) and service account management. Outline 7.4 will say the same words again in operations; Domain 5 is where you design the identity so operations has something to audit.
PAM is how you enforce that rule on the dangerous accounts: domain admin, root, break-glass, cloud owner, and high-privilege service or agent identities. Vault the secret so humans do not know it. Broker the session. Record keystrokes and video. Rotate on check-in. Grant elevation for a ticket, then revoke. That last sentence is zero standing privilege — the modern reading of JIT, not “we have a longer admin password.”
“We added logging, so the shared admin API key is fine.” Accounting without unique identification is a diary of a crowd. Least privilege failed first. A short-lived, scoped identity (human JIT checkout, or a per-workload credential) plus an auditable delegation chain is the Domain 5 answer. Logging a shared secret is not.
5. Runbook — lifecycle, least privilege, prove
This is not a vendor console path. It is the review-board sequence ISC2 wants when the stem says FIRST or BEST after an orphan account, a standing admin, or a partner federation. Each side cites one primary source.
Side A — HR / IdP (identification, proofing, provision)
Primary source: ISC2 outline 5.2 and 5.5, with assurance language from NIST SP 800-63-4 Digital Identity Guidelines.
-
Proof the identity before you issue a credential
Registration and proofing (5.2) happen first. A contractor packet, a device attestation, or a workload identity request — not “create the admin and we’ll verify later.”
-
Create one unique subject from an authoritative source
HR (or a CMDB for non-humans) is the source. Directory is the projection. Unique identity is what makes accountability possible. No shared “billing-admin.”
-
Assign groups and roles at birth, least privilege only
Outline 5.2 lists groups and roles next to AAA. Birthright access is the job, not last quarter’s project plus a domain-admin nested group.
-
Push the account to every relying system
SCIM (or an equivalent joiner feed) creates the SaaS account. JIT-on-first-login can create; it does not reliably delete. Federation without provisioning is how AD dies and SaaS lives.
Side B — Authorization and privileged access
Primary source: ISC2 outline 5.4 and 5.2 (JIT, credential management / password vault), plus NIST SP 800-207 Zero Trust Architecture (PDP/PEP, no implicit trust from location).
-
Name the model from who decides
Owner → DAC. Labels → MAC. Job → RBAC. Many attributes → ABAC. Same rule for all → rule-based. Risk score → risk-based / adaptive. Write the PDP rule; put the PEP on the resource, not only on the VPN.
-
Separate standard work from privileged work
Day-to-day identity uses SSO + phishing-resistant MFA. Admin work goes through the vault: checkout, broker, record, expire. Sudo and elevation are logged (5.5).
-
Kill standing privilege
JIT elevation for a ticket, then revoke. Service accounts and AI agents get unique, short-lived, scoped credentials — not one admin token reused across 40 jobs.
-
Handle movers, not only joiners
Role definition and transition (5.5) means the old role dies when the new one is granted. Privilege creep is a lifecycle failure that looks like “RBAC is working.”
Side C — Prove (review, deprovision, evidence)
Primary source: ISC2 outline 5.5 (account access review; provisioning and deprovisioning; service accounts) and the session / accounting half of 5.2.
-
Recertify on a calendar, not after a breach
User, system, and service accounts (the outline’s three). Owner attests. A stale “still needed” with no owner is a revoke.
-
Deprovision as a cascade, then test a leaver
Disable directory → revoke tokens and sessions → SCIM delete / disable on every SP → retrieve vault secrets → retire agent identities. Then attempt login on the SaaS that burned you last time. Expect deny + log.
-
Keep the fields a reviewer can read
Who was the subject, who approved, what role, when it expired, which PDP decision, which PEP enforced, which session recording exists. If those fields are empty, you have a story, not a control.
subject=contractor.jdoe source=hr.offboard.2026-05-12 directory=disabled saml_session=revoked scim_saas_billing=deactivated vault_checkout=none last_auth=denied pep=billing-admin-role missing reviewer=app-owner.finance next_recert=n/a (account gone)
Every subject is unique. Authentication uses two categories (phishing-resistant for privileged). Authorization is least privilege with a named model. Accounting can name one actor. Joiners, movers, and leavers hit every federated app. Privileged work is vaulted, recorded, and time-boxed. A leaver login fails on the app that used to linger.
6. Runtime path — assertion then session
Two pictures. First the federation hop at login. Then what must keep happening after the assertion is accepted — session, authorization, privilege, revoke.
Read left → right, then the privilege row. Examiners test order: SP → IdP → assertion → SP grant. Deprovision is a later arrow the diagram must not forget.
Physical access (outline 5.1) uses the same four letters: badge claim, reader proof, door authorization, CCTV/log accounting. A tailgate is an authorization and accountability miss, not “the firewall.” Logical access to applications and services is the exam’s usual setting; do not forget facilities and devices when the stem is a data centre or a laptop that never enrolled.
7. Traps and proof
| Stem pattern | What ISC2 is testing | Engineer trap | Manager move |
|---|---|---|---|
| Leaver still in SaaS; AD is off | Lifecycle / deprovision (5.5), federation (5.3) | Turn on MFA; reset passwords | Cascade deprovision (SCIM) and recertify remaining apps |
| Password + PIN as “MFA” | AAA / factor categories (5.2) | Accept two knowledge factors | Second category; phishing-resistant for privileged |
| “Use OAuth to authenticate users” | Protocol job (5.2, 5.3, 5.6) | OAuth is login | OIDC or SAML to prove identity; OAuth to delegate an API |
| We have SSO, so partners are covered | SSO vs FIM (5.2, 5.3) | Treat SSO as federation | Signed trust + attribute release + deprovision across the boundary |
| Department + device + time + label | Authorization model (5.4) | Call it RBAC because roles exist | ABAC (or risk-based if a score is the decider) |
| Standing domain admin / shared API key | Least privilege, JIT, service accounts (5.2, 5.5) | Longer password; more logs on the shared secret | Vault + JIT + unique identity; log the unique actor |
| AI agent with one admin token | Non-human identity in Domain 5 | Treat it as “just a script” | Unique subject, least privilege, short life, auditable delegation |
| Owner vs labels vs job | DAC vs MAC vs RBAC | Pick the newest acronym | Name who decides, then name the model |
- I can say IAAA in order and give one failure mode for each letter.
- I can tell SSO from federation in one sentence.
- I can pick SAML, OIDC, OAuth, or SCIM from a job description without mixing them.
- I can name DAC / MAC / RBAC / ABAC / rule-based / risk-based from who decides.
- I can describe PAM as vault + broker + record + JIT, not as “a password manager for admins.”
- I can walk a leaver test: directory off, token dead, SaaS deny, vault secret retrieved.
- I did not invent a Domain 5 subtopic percentage. The official weight is 13% of the whole exam — that is the only percentage this page uses.
Weak: “Domain 5 is MFA and RBAC.” Strong: “Identification is the claim, authentication proves it, authorization is least privilege, accounting names one actor. SSO is intra-org convenience. Federation is a signed trust — and useless if SCIM never deletes. Privileged access is a second, shorter clock: vault, record, JIT. If an agent or service shares one admin token, I do not have an identity to manage.”
Knowledge check
Six judgment items. Map each one to a FIRST/BEST stem, not a definition. Check answers, then reset and retry the misses.
Sources
- ISC2 — CISSP Certification Exam Outline (effective 15 April 2024). Domain 5 weight 13%. Objectives 5.1–5.6 are the spine of this lesson. No other exam percentages are claimed. English PDF: CISSP-Exam-Outline-April-2024-English.pdf.
- NIST — SP 800-63-4 Digital Identity Guidelines and SP 800-63B-4 Authentication and Authenticator Management (assurance levels, phishing-resistant authenticators, session management).
- NIST — SP 800-162 Guide to Attribute Based Access Control (ABAC).
- NIST — SP 800-207 Zero Trust Architecture (PDP / PEP, no implicit trust from location).
- IETF — RFC 6749 OAuth 2.0 Authorization Framework; RFC 7644 SCIM 2.0 Protocol.
- OpenID Foundation — OpenID Connect Core 1.0. OASIS — SAML 2.0 technical overview.
- Well-known CBK (not an ISC2 percentage claim): IAAA order; FAR vs FRR vs CER; Kerberos TGT / KRBTGT golden-ticket pattern; DAC / MAC / RBAC decision-maker test.
Related: CISSP overview (all 8 domains) · Domain 4: Communication and Network Security · Domain 6: Security Assessment and Testing · Domain 5 assessment · 8-week roadmap