Back to Domain 4 · Communication & Network Security

CISSP Mastery

CISSP Mastery · Module 5 / 8

Domain 5: Identity & Access Management

The perimeter is dead; Identity is the new firewall. Master the AAA framework and access control models.

Your progress

Domain 5 of 8 63%

Module 5

13%

Exam weight

AAA

Foundation

5 / 8

Domain focus

PDP/PEP

Policy engine

Open preview · Domain overview

Why Domain 5 is the new perimeter

Every breach narrative eventually lands on a credential, a role, or a broken authorization path. Domain 5 trains you to engineer identity as a system: AAA, policy engines (PDP/PEP), access models from MAC to ABAC, modern authentication, and lifecycle discipline from joiner to leaver.

Domain 5 turns identity into an engineering discipline: AAA, access models, modern authentication, and lifecycle governance. Pair it with Domain 4 (where traffic flows) and Domain 6–7 (how you verify and operate controls).

AAA is the spine

Identification, authentication, authorization, and accounting — if one link is weak, the rest are theatre.
Models map to risk

MAC, DAC, RBAC, and ABAC each trade flexibility for assurance. The exam tests which model fits which regulatory reality.
Authentication ≠ authorization

Strong MFA with sloppy RBAC still loses. Most real-world failures are authorization and governance gaps, not password guessing.
Lifecycle is governance

Provisioning, periodic access review, and de-provisioning are where least privilege lives or dies in production.

Module 1 · IAM fundamentals

The AAA framework — plus accounting

CISSP expects you to separate who (identification), proof (authentication), permission (authorization), and evidence (accounting). Confuse authentication with authorization and you will miss scenario questions.

Identification

Claiming an identity (username, UPN, certificate subject). Identification alone proves nothing — it is only a label until verified.
Authentication

Proving the claim: something you know, have, or are. MFA stacks factors so a stolen password is not sufficient.
Authorization

Deciding what an authenticated subject may do on which objects. Policy-driven (RBAC/ABAC) and enforced at the PEP after PDP evaluation.
Accounting

Logging and monitoring of access decisions and sessions — audit trails, SIEM correlation, and non-repudiation for investigations.

The diagram below maps a typical authorization decision in policy-driven architectures: the subject issues a request, the PDP evaluates policy, the PEP enforces the decision at the resource boundary.

Premium diagram

IAM authorization flow — PDP & PEP

How a request becomes a decision, then enforcement. Hover, tap, or Tab each block — the panel below explains SOC-style focus and exam cues.

Authorization path

Role

Hover, tap, or Tab on each block for IAM focus and an exam cue.

PDP and PEP sit inside one policy plane; the path is Subject → Request → decision / enforcement → Resource.

Module 2 · Access control models

MAC, DAC, RBAC & ABAC — pick the right control model

Exam questions often describe an environment and ask which model fits. Anchor on who assigns permissions (owner vs central authority) and what drives the decision (static role vs dynamic attributes).

Model	Type	Mechanism	Trade-off	Typical use
MAC	Mandatory	Central authority assigns labels; subjects/objects carry clearance / classification.	Strong assurance · least user flexibility	Government MLS, highly regulated data enclaves
DAC	Discretionary	Object owner grants/revokes access at their discretion (ACLs).	Flexible · integrity depends on owner discipline	Default Unix/Linux file permissions, many SMB shares
RBAC	Role-based	Permissions bundled into roles; users receive role memberships.	Scales in enterprises · role explosion if poorly governed	Active Directory groups, cloud IAM roles, SoD matrices
ABAC	Attribute-based	Policies evaluate attributes (user, resource, environment, action).	Fine-grained · policy complexity & testability	Zero Trust, dynamic cloud authorization (e.g. XACML-style engines)

Module 3 · Authentication mechanisms

MFA, biometrics, passwordless & federation workflows

Authentication proves identity to a relying party. Know the shape of each protocol family: tickets vs assertions vs tokens — the exam tests boundaries (what each protocol does not guarantee).

MFA & step-up

Combine independent factors (TOTP, WebAuthn/FIDO2, push approval). Step-up authentication re-challenges when risk signals rise (new device, impossible travel).

Biometrics

Presentation attack detection (PAD) matters: liveness checks, template protection (never store raw images), fallback paths when sensors fail.

Passwordless

FIDO2 security keys and platform authenticators remove shared secrets from the phishing surface. Pair with strong device enrollment and recovery policies.

Kerberos · SAML · OAuth 2.0 / OIDC

Kerberos: ticket-granting within a realm (TGT / service tickets). SAML: XML assertions for browser SSO (IdP → SP). OAuth 2.0 + OIDC: delegated authorization + identity layer for modern APIs and mobile.

Module 3b · OAuth 2.0 flow selection

Authorization Code + PKCE — and flows to avoid

OAuth answers delegated authorization (what an app may do on behalf of a user). OIDC adds an identity layer (who the user is). The exam tests which flow fits the client type — especially PKCE for public clients and why the implicit grant is deprecated.

Flow	Client type	Typical use	Exam note
Authorization Code + PKCE	Public / mobile / SPA (no client secret)	Modern delegated access for user-facing apps	Current best practice — token exchanged via back-channel; PKCE prevents interception
Authorization Code (confidential)	Server-side web app (holds client secret)	Traditional OAuth for backend-for-frontend patterns	Secret stored server-side; user never sees the access token directly
Client Credentials	Machine / service account	Service-to-service API calls with no end user	No user consent — not for delegated end-user authorization
Implicit grant (deprecated)	Legacy browser / mobile apps	Historically returned tokens in URL fragment	Exam trap: exposes tokens to browser history and referrers — reject for new designs

Exam cue

PKCE in one sentence

Proof Key for Code Exchange (PKCE) binds the authorization code to the requesting app via a one-time verifier, so even a public client (mobile/SPA) can safely use the Authorization Code flow without exposing tokens in the redirect URI.

Module 4 · Identity lifecycle

Provisioning, de-provisioning & least privilege

Identity is a lifecycle, not a ticket. Governance connects HR events to technical entitlements — and auditors read the gaps between them.

Provisioning (joiner / mover)

HR-driven birthright access, approval workflows, and service accounts created with least privilege. Movers need delta reviews — not a full new hire, but not silent either.
De-provisioning (leaver)

Immediate disable, session revocation, mailbox/legal hold, key rotation, and removal from groups / cloud role bindings. Latency here is breach latency.
Least privilege & periodic review

Standing access rots. Access certifications, just-in-time (JIT) elevation, and PAM for break-glass reduce the blast radius of compromised identities.

Exam-grade takeaways

CISSP Exam Pro-Tip — authorization is the usual failure point

Headlines blame “stolen passwords”, but post-mortems almost always reveal over-privileged accounts, stale group memberships, or missing enforcement at the resource (PEP). Authentication answered “who”; authorization failed to constrain “what they could do”. On the exam, when scenarios mix SSO success with data exfiltration, look for broken role mappings, implicit trust between tiers, or default-allow policies — not stronger passwords alone.

Trap

“We have MFA, so we are safe”

MFA stops credential stuffing — it does not stop a compromised admin role, a broad OAuth scope, or lateral movement after the first hop. Always ask: what does this subject still have access to after authentication succeeds?

Exam cue

PDP vs PEP

PDP decides (policy evaluation). PEP enforces (gateway, API proxy, app guard). Questions that mention “central policy engine” + “enforce at the API edge” are painting PDP + PEP split — not just a firewall rule.

Exam cue

Implicit grant vs Authorization Code + PKCE

When a mobile or SPA app cannot store a client secret, reject the implicit grant (tokens in URL fragment). Choose Authorization Code with PKCE — the access token is obtained via a back-channel exchange, not exposed in browser history.

Quick check

Domain 5 quiz

One question at a time — instant feedback. Pair it with the diagrams and Pro-Tip callouts above.

Quiz progress

Question 1 of 5 · 20%

Q 1

Question 1 of 5

1.Which protocol is primarily used for federated SSO assertions in many enterprises?

Ready for Domain 6?

Module 5 is the IAM core — AAA, federation, lifecycle, and access models that appear in nearly every vignette. Keep moving through the blueprint at your pace. Domain content is free throughout; the paywall only appears on the Final Mock Exam after your free trial questions.

Back to Domain 4 · Communication & Network Security Final Mock Exam Continue · Domain 6 · Security Assessment & Testing