# CISSP Domain 5 — prove who, grant least, revoke on time

Source: https://ai.techclick.in/blog_cissp_d5_iam
Markdown: https://ai.techclick.in/blog_cissp_d5_iam.md
Publisher: Techclick Infosec Pvt Ltd

CISSP Domain 5 (13%): walk IAAA, pick SSO vs federation, choose SAML/OIDC/OAuth/SCIM, enforce least privilege, and prove privileged access with JIT and reviews. Official ISC2 outline.

Quick answer

    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.

   Say this out loud

   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.

   Hero · who talks to whom

   Notice: the user never authenticates to every app. They authenticate to the IdP. The app trusts an assertion. Break that chain at any hop and you get a loop, an orphan, or a standing admin.

#### 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.

   Official outline (what this page covers)

    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.

   Journey · identify, authenticate, authorize, account

   Read left to right. Login is panel two. Most Domain 5 damage lives in panel three (too much grant) and after exit (panel one never got deleted downstream).

   Flow 1 · IAAA, then the lifecycle

       IAAA steps mapped onto the identity lifecycle

- Session path (IAAA) sits on the lifecycle Identify claim · username Authenticate prove · MFA / passkey Authorize permit · least privilege Account log · one actor Proof + provision hire · HR source Use + session SSO · timeout Review + move recertify · transfer Deprovision everywhere directory + SaaS + vault + agent Same four letters for humans, devices, services, and AI agents Outline 5.2 names people, devices, and services. ISC2 now also calls out non-human / agent identities. A shared long-lived admin token has no unique identification and no accountability. Read left → right, then the second row. A successful password is only Authenticate. Orphan SaaS admin is a lifecycle miss, not an MFA miss. Hard words before the runbook 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). Say this out loud 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. Classic miss 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. Feel · two paths from one decision Path A is one company, many apps (SSO). Path B is a signed handshake across an org boundary (federation). Caption, not the art, carries the meaning. Flow 2 · What job does this protocol have? Decision flow from trust boundary to SAML, OIDC, OAuth, or SCIM Does trust cross an organization? Cross-org? SSO inside one org one login · many apps Federation (FIM) IdP vouches · SP trusts What is the job? Prove a person SAML or OIDC Delegate an API OAuth 2.0 token Create / delete account SCIM (not a login protocol) Trap “OAuth to log users in” SAML = signed XML assertion (browser / enterprise SaaS). OIDC = ID token on OAuth (mobile / API-first). SCIM syncs the lifecycle. JIT login ≠ SCIM delete. Outline 5.3: same federation pattern on-prem, cloud, or hybrid — the trust document changes, the verbs do not. 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 is not federation 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.” Exam trap “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.

   Pilot evidence — fields a reviewer should see
   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)

   Green path — you finished Domain 5 work when

   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.

   Proof · access review and vault checkout are the care

   Notice: a green dashboard without a recertification signature and a vault log is decoration. Proof is the file plus the deny on the leaver test.

   Flow 3 · SAML/OIDC login, then the privilege clock

       Runtime path from user to IdP assertion to SP to time-boxed privilege

- User → SP opens the app Redirect IdP AuthN + MFA Assertion / ID token signed attributes SP + PDP map groups → rights PEP grants session timeout · step-up If the task is privileged: vault checkout → recorded broker → auto-revoke SSO got them in. JIT is a second, shorter clock. Outline 5.2 session management + JIT. Break it: IdP disabled, SP local account still admin, no SCIM delete AuthN still succeeds at the SaaS. That is the contractor ticket. Fix deprovision, then re-test. 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 Pilot / interview proof checklist 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.

   Interview angle

    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.

       Q1
       An auditor finds three accounts of resigned staff still active in a cloud HR app. Their Active Directory accounts were disabled on the last day. What failed FIRST, and what do you fix?

           MFA on the cloud app — force a new factor
           Password complexity — the leftover accounts are too guessable
           Deprovisioning across federated / downstream systems — push SCIM disable and recertify
           Identity proofing at hire — they should never have been created

       Correct:  c . AD died; the SP kept a local account. That is outline 5.5 / 5.3, not MFA or proofing. Re-read  Side A and Side C  and the contractor ticket in  Why it matters .

       Q2
       An engineer enables “MFA” on the admin portal by requiring a password plus a 6-digit PIN at login. Why does this fail Domain 5?

           A PIN is too short unless it is 8 digits
           Admin portals must be biometric-only
           Password and PIN are both something you know — still single-factor
           PINs are not allowed under any NIST assurance level

       Correct:  c . MFA is two  categories , not two secrets. Add a have or are factor; for privileged access prefer phishing-resistant. Re-read factors under  Mental model .

       Q3
       A third-party budgeting app must pull transaction history through an API. It must never see the customer’s banking password or become the login IdP. Which protocol is the BEST fit?

           SAML 2.0, because it is the enterprise SSO standard
           OAuth 2.0, because it grants scoped, delegated API access
           OpenID Connect alone, because the app must prove who the customer is
           Kerberos, because tickets avoid sending passwords

       Correct:  b . The job is authorization of an API, not authentication of a person. SAML/OIDC prove identity; Kerberos is intra-realm. Re-read  Decision flow  and the protocol table.

       Q4
       Access must depend on department, data classification, device patch status,  and  time of day, evaluated in one decision. Which model fits BEST?

           DAC — the file owner will tick four boxes
           MAC — labels alone decide
           RBAC — assign a “daytime-patched-finance” role
           ABAC — attributes of subject, object, and environment in one policy

       Correct:  d . Several attributes together is ABAC (outline 5.4). RBAC would explode into custom roles. MAC is labels only. DAC is owner discretion. Re-read  How to choose .

       Q5
       Leadership wants no standing domain-admin rights so a stolen admin session is useless tomorrow. Which control do you implement FIRST?

           Just-in-time elevation with automatic revocation (zero standing privilege)
           Assign every admin a permanent RBAC “Domain Admin” role
           Increase password length on the shared admin account
           Enable DAC on the SYSVOL share

       Correct:  a . Outline 5.2 names JIT next to SSO. Permanent roles and longer shared passwords leave standing privilege. Re-read privileged access in  How to choose  and Side B.

       Q6
       An architect says “we already have SSO, so partner employees can use our SaaS and we are federated.” What is the Domain 5 judgment?

           Correct — SSO and federation are the same control with two names
           Wrong — SSO is one-login convenience; federation is a signed IdP/SP trust plus attribute release and deprovision across the boundary
           Wrong — partners must always use Kerberos, never SAML or OIDC
           Correct if the SSO portal uses OAuth 2.0 without an ID token

       Correct:  b . Outline 5.2 lists SSO and FIM as separate bullets. 5.3 is the third-party trust (on-prem, cloud, hybrid). OAuth without OIDC does not even authenticate. Re-read  Decision flow .

       Check answers
       Reset

## 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

---
Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees.
Browse all lessons: https://ai.techclick.in/blogs
AI index: https://ai.techclick.in/llms.txt