Most engineers think…
"IAM is just login screens and passwords — once a user authenticates, the access part is basically done."
Authentication only proves who you are; CISSP Domain 5 is mostly about what happens after — authorization, accountability, lifecycle, and privileged access. The 2024 outline now even spans AI agents and non-human identities. Treating IAM as "just login" is exactly how over-provisioned accounts and orphaned admin credentials become the breach.
Identity and Access Management is the heart of practical security: deciding which people, services, devices, and now AI agents get to touch which resources, and proving it afterward. CISSP Domain 5 carries 13% of the exam and shows up constantly on the job — every breach post-mortem eventually points back to a credential that should not have worked. This deep-dive walks the four pillars: AAA and the identity lifecycle (provision → manage → deprovision), authentication factors and when MFA must be phishing-resistant, federation and SSO (SAML, OIDC/OAuth 2.0, SCIM), and access-control models plus PAM (RBAC/ABAC enforcing least privilege, privileged access vaulting and just-in-time elevation). An AI-angle section closes the loop on adaptive, behavior-aware identity.
Domain 5 at a glance
Flip each card for the one-line essence of each area before you dive in.
Identify, authenticate, authorize, then hold accountable; review and revoke access on time.
Real MFA mixes factor categories; FAR is the dangerous biometric error; protect KRBTGT.
OAuth authorizes API access; OIDC and SAML authenticate users — never confuse the two.
Identify the decision-maker to name the model; PAM = least privilege for admin accounts.
AAA & identity lifecycle
Think of a corporate office: the gate guard checks your face against an ID, the badge reader unlocks only your floor, and the CCTV logs every door you open. That is AAA in the physical world, and CISSP Domain 5 tests the digital version constantly.
The four pillars must never be blurred. Identification is the claim of identity, like entering a username or employee ID. Authentication proves that claim using something you know, have, or are. Authorization then decides what that proven identity may actually do. Accountability records the actions so you can trace them to one individual later. Accountability only works when identities are unique and logs are tamper-resistant, which is why shared accounts destroy it.
The identity lifecycle is the journey of an account from birth to death. Provisioning creates the account and grants least-privilege access, ideally driven by HR data. During employment, periodic access reviews (recertification) catch privilege creep, where people keep old rights after changing roles. De-provisioning promptly disables access when someone leaves or transfers. The 2024 outline also stresses identities for non-human entities like AI agents and service accounts, which need lifecycles too.
If a question describes orphaned accounts or a fired employee still logging in, the failed control is de-provisioning, not authentication.
SSO versus federation trips up many candidates. SSO lets a user log in once and reach many apps inside one organization. Federation extends that trust across organizational boundaries using standards like SAML assertions or OpenID Connect tokens, so a partner's identity provider vouches for your users.
Priya at Infosys faces this
A contractor who left three months ago still appears in the SaaS admin login report at 10.20.4.55.
De-provisioning fired in Active Directory but the federated SaaS app kept a stale local account.
Run an access recertification, enforce SCIM-based de-provisioning, and centralize identity through the federated IdP.
In the AAA model, which step decides what a successfully logged-in user is permitted to do?
Pause & Predict
In one line, what is the single most important idea in "AAA & identity lifecycle"? Type your guess.
Authentication factors
Think of authentication factors like checks at an airport gate: your boarding pass (something you have), your face on the ID (something you are), and your booking PIN (something you know). The more independent checks, the harder it is to fake your way through.
CISSP groups identity proof into three classic categories. Something you know is a password, passphrase, or PIN. Something you have is a token, smart card, or phone running an authenticator app. Something you are is a biometric like a fingerprint or iris. The 2024 outline also recognises somewhere you are (location) and something you do (behaviour like gait or typing rhythm) as supporting factors.
Multi-factor authentication (MFA) must combine two or more different categories. A password plus a PIN is still single-factor, because both are "something you know." A password plus a phone push is true MFA. The strongest, phishing-resistant MFA today is FIDO2/WebAuthn, the standard behind passkeys. A public-private key pair lives on your device; the private key signs a server challenge and never travels, so attackers cannot replay or phish it.
Biometrics carry measurable error. FRR (False Rejection Rate, Type I) wrongly blocks a valid user. FAR (False Acceptance Rate, Type II) wrongly admits an impostor, which is the security-critical error. The CER (Crossover Error Rate) is where FAR equals FRR, and a lower CER means a more accurate sensor.
Kerberos is the ticket-based protocol behind Active Directory logins. The KDC issues a Ticket-Granting Ticket (TGT), which you later exchange for service tickets, so your password is never resent. The grave risk is the golden ticket: if an attacker steals the KRBTGT account hash, they forge valid TGTs for any user, even after password resets, and logs will not flag them.
FAR (Type II, lets the impostor in) is the dangerous error. If a question asks which to minimise for high security, choose FAR, not FRR.
Priya at HDFC Bank faces this
Fraud spikes after attackers phish OTP codes from customers using fake bank pages.
SMS OTP is a shared secret that phishing proxies relay in real time, so it is not phishing-resistant.
Priya migrates high-value logins to FIDO2 passkeys, where the private key never leaves the device and cannot be relayed.
Aditya at Infosys must enable MFA on an admin portal. He proposes requiring a password plus a 6-digit PIN at login. Why does this fail to provide true multi-factor authentication?
▶ A SAML single sign-on login
Press Play to step through it, then Break it to see how it fails.
Federation & SSO
Think of federation like an airport visa-on-arrival deal: your home country vouches for you, so the foreign airport lets you in without re-verifying your whole life. Federation extends trust across organisational boundaries so one login works everywhere. The two starring roles are the Identity Provider (IdP) and the Service Provider (SP). The IdP proves who you are; the SP consumes that proof and grants access.
SAML 2.0 is the veteran. It is an XML-based standard that carries signed assertions between IdP and SP, and it powers most enterprise browser SSO to SaaS apps like Salesforce and Workday. SAML handles both authentication and some authorization attributes in one document.
OAuth 2.0 is where students get trapped. OAuth is an authorization framework, not authentication. It lets an app obtain a limited access token to call an API on your behalf (e.g. read your Google Drive) without sharing your password. It answers "what can this app do," never "who is this user."
OpenID Connect (OIDC) fixes that gap. OIDC is a thin identity layer on top of OAuth 2.0 that adds an ID token (a signed JWT) proving the user's identity. It is the modern choice for mobile, API-first, and cloud-native apps. SAML for legacy enterprise; OIDC for new builds.
Just-in-time (JIT) provisioning creates the SP-side account automatically on first successful login, using attributes from the assertion (email, name, group). No pre-loading thousands of users; the account appears when needed.
The exam loves "use OAuth to authenticate users." Wrong. OAuth authorizes API access; if the question is about proving identity, the answer is OIDC (or SAML for browser SSO).
Priya at Infosys faces this
A new contractor logs into the partner portal once and an account silently appears, but with no department or roles attached.
JIT provisioning fired correctly, but the IdP assertion omitted the group and department attributes the SP maps to roles.
Fix the IdP attribute release (claims mapping) so the SAML assertion carries authorization attributes, enforcing least privilege at provisioning time.
Aditya at HDFC must let a third-party budgeting app pull a customer's transaction history via API, without the app ever seeing the customer's banking password or login identity. Which protocol fits this need exactly?
Pause & Predict
Without scrolling up: name the biggest difference in "RBAC vs ABAC". Type your guess.
Access control models & PAM
Think of access control models as different doormen guarding the same building. Each doorman uses a different rulebook to decide who walks in. CISSP Domain 5 expects you to know five rulebooks cold, because the exam loves asking "who actually decides access here?"
Discretionary Access Control (DAC) lets the resource owner decide. When you share a Google Drive file and pick who can edit, that is DAC. It is flexible but risky, because owners make mistakes. Mandatory Access Control (MAC) removes that human discretion. The system enforces labels, and even a file's owner cannot loosen access. Military and defence systems use MAC. Role-Based Access Control (RBAC) grants permissions to a role (like "Accounts-Payable Clerk"), then assigns people to roles. Onboarding becomes one role assignment, not fifty individual grants. Attribute-Based Access Control (ABAC) evaluates many conditions together: user department, device health, data sensitivity, even time of day. Rule-Based (RuBAC) applies blanket "if-then" rules to everyone, like a firewall blocking all traffic after 9 PM regardless of role.
The principle of least privilege threads through all five models. Privileged Access Management (PAM) applies least privilege to the riskiest accounts: domain admins, root, service accounts. PAM vaults these credentials, rotates them, brokers each login through a gateway, and uses session recording to capture full video plus keystrokes as a forensic trail. The modern direction is just-in-time (JIT) access: no account holds standing admin rights; the system grants elevation only for a task, then revokes it automatically. The endgame is zero standing privilege.
Spot the decision-maker. Owner decides → DAC. System-enforced labels → MAC. Job role → RBAC. Many attributes evaluated together → ABAC. Same rule for everyone → Rule-Based.
Priya at HDFC faces this
A departed contractor's domain-admin password still works three weeks after offboarding, and nobody can say who used it last.
Admin credentials were standing and shared, never vaulted, never rotated, with no session trail.
Onboard those accounts into PAM: vault and rotate passwords, broker logins through a recorded gateway, and move to JIT elevation so no standing admin rights remain.
Karthik, a security architect at Infosys, must let access depend on the user's department, the data's classification, the device's patch status, AND the time of day, all evaluated in one decision. Which model fits best?
Domain 5 in the AI era (2026)
The identity you must now defend most often isn't human. In CISSP Domain 5 you learn to manage the identity lifecycle — provisioning, authentication, authorisation, de-provisioning. In 2026 that lifecycle is dominated by non-human identities (NHIs): service accounts, workload identities, API keys, and the fastest-growing class of all, autonomous AI agents. CyberArk's 2026 landscape report found machine identities outnumber humans by roughly 82-to-1, and ManageEngine's 2026 outlook saw some firms hit 500:1. Yet 88% of organisations still classify only humans as "privileged," and two-thirds have already suffered a breach through a compromised NHI.
AI agents are a subclass of NHI that needs stricter controls. Unlike a static API key, an agent decides at runtime, chains tool calls, and can be hijacked by prompt injection — making it a genuine 2026 insider-threat vector. The CSA-OASIS State of NHI and AI Security 2026 found 78% of organisations have no policy for creating or removing AI identities, and 51% cite over-permissioning as their top pain.
The emerging fix maps cleanly onto Domain 5 vocabulary. Give every agent a cryptographically verifiable identity — a SPIFFE/SPIRE SVID or OIDC-federated token, not a shared secret. For "act on behalf of a user" calls, use OAuth 2.0 Token Exchange (RFC 8693) with the act claim so the delegation chain stays auditable (delegation, not impersonation). NIST launched its AI Agent Standards Initiative in February 2026, and CSA's Agentic Identity Governance Framework is converging the field.
The AI-era angle, in four cards
What 2026 adds to this domain — flip to see why each matters.
Agents decide at runtime, chain tool calls, and can be prompt-injected. So what: they need per-task credentials and behavioural monitoring, not a static API key.
Machine identities outnumber humans ~82:1 (some firms 500:1), yet 88% treat only humans as privileged. So what: your biggest attack surface is ungoverned.
A short-lived, attested identity document (X.509/JWT) per workload from SPIRE. So what: kills the shared-secret leaks that cause two-thirds of NHI breaches.
Token Exchange records 'agent X acted for user Y' in the act claim. So what: turns risky impersonation into auditable, accountable delegation.
Pause & Predict
Name one thing AI changes about Domain 5 — and one fundamental it does NOT change. Type your guess.
🎯 Prove it — your Domain 5 practice exam
You have read the theory. Now do the reps. This is the free, timed Techclick assessment built for exactly this domain, with full reasoning on every question — plus the full-length mock for when you are close to your exam date.
Part of the 8-part series · start from the CISSP overview → · all assessments live on exam.techclick.in (sign in with your Techclick account).
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from ISC2 docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: Your company federates 40 SaaS apps. A contractor's project ends but their accounts stay live for weeks, and they retained admin rights to a billing tool. Using Domain 5 concepts, explain which IAM controls failed and how AAA, the identity lifecycle, SCIM, RBAC, and PAM each would have prevented or limited this. Then compare to the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Provisioning
- Creating an identity and granting it least-privilege access, ideally automated from an HR system.
- De-provisioning
- Promptly disabling or removing access when a user leaves or changes roles, preventing orphaned accounts.
- Federation
- A trust relationship that lets one organization's identity provider authenticate users for another's applications via SAML or OIDC.
- FIDO2/WebAuthn
- Open standard for passwordless, phishing-resistant login using a device-bound private key that signs a server challenge; the basis for passkeys.
- Crossover Error Rate (CER)
- The point where a biometric system's false-accept rate equals its false-reject rate; lower CER means a more accurate system.
- Golden ticket
- A forged Kerberos TGT created from a stolen KRBTGT hash that grants long-term, undetectable access to any account in the domain.
- SAML assertion
- A signed XML statement from the IdP telling the SP who the user is and, optionally, what they may access.
- ID token
- A signed JWT issued by OIDC that proves the user's identity — the piece OAuth alone never provides.
- JIT provisioning
- Auto-creating the service-provider account on first login using attributes carried in the federation assertion.
- Just-in-Time (JIT) access
- Granting privileged access only for the duration of a specific task, then auto-revoking it, so no account holds permanent admin rights.
- Credential vaulting
- Storing privileged passwords and keys in an encrypted central vault that rotates them and hides them from end users.
- Least privilege
- Giving every user, process, or account the minimum access required to do its job, and nothing more.
- Non-Human Identity (NHI)
- Any credentialed actor that isn't a person — service account, API key, workload, or AI agent. In 2026 these outnumber human identities by roughly 82:1 and are a top breach vector.
- SPIFFE / SPIRE
- An open standard (SPIFFE) and its runtime engine (SPIRE) that issue each workload a short-lived, cryptographically verifiable identity (an SVID) instead of a shared API key.
- OAuth 2.0 Token Exchange (RFC 8693)
- A standard letting a service swap one token for another to act on behalf of a user; its 'act' claim records the delegation chain, enabling auditable delegation rather than untraceable impersonation.
📚 Sources
- ISC2 — CISSP Certification Exam Outline (effective 2024, Domain 5 = 13%). isc2.org
- NIST — SP 800-63B-4 Digital Identity Guidelines: Authentication and Lifecycle Management (Rev. 4, 2025; AAL1–AAL3, phishing-resistant MFA, passkeys, SMS/email-OTP deprecation). nvlpubs.nist.gov
- NIST — SP 800-63-4 Digital Identity Guidelines (identity, authenticator, and federation assurance levels). pages.nist.gov/800-63-4
- NIST — SP 800-162 Guide to Attribute Based Access Control (ABAC) Definition and Considerations. csrc.nist.gov
- NIST — SP 800-207 Zero Trust Architecture (continuous verification, least privilege, policy decision/enforcement points). csrc.nist.gov
- IETF — RFC 6749 OAuth 2.0 Authorization Framework and RFC 7644 SCIM 2.0 Protocol (provisioning). ietf.org
- OASIS / OpenID Foundation — SAML 2.0 standard and OpenID Connect Core 1.0 specification (federation and token-based SSO). openid.net
- Ministry of Electronics and IT (India) — Digital Personal Data Protection Act 2023 + DPDP Rules 2025 (RBAC, least privilege, MFA, access logging, verifiable consent). meity.gov.in
What's next?
Domain 5 done. Keep the momentum — next is Domain 6: Assessment & Testing.