Identity and access management defines how an organization creates, grants, changes, and removes access as people move through their employment lifecycle. For CISSP Domain 5, the core security question is which identity should exist, which access should be granted, which privileges should change, and how quickly everything should be removed.
CISSP Domain 5, Identity and Access Management, is about answering those questions in a controlled, auditable way. It covers the lifecycle of digital identities, authentication, authorization, identity governance, access control models, privileged access, federation, and the operational controls that help ensure the right entities access the right resources for the right reasons.
Identity remains a common path into security incidents because attackers can misuse credentials, social engineering, privilege, or human error rather than exploiting a software flaw directly. One external summary of breach research notes that the human element is frequently involved in breaches, which is why CISSP candidates need to understand IAM as both a technical discipline and a governance discipline.
Where Domain 5 fits in the CISSP exam
The Certified Information Systems Security Professional certification expects candidates to reason across security architecture, operations, risk, and governance. Domain 5 focuses that reasoning on identity: how subjects are identified, how their claims are verified, how access is granted, how privileges are reviewed, and how accountability is preserved through logging and audit trails.
Exam questions often test whether the candidate can identify the identity problem hiding inside a scenario. A prompt about a new hire receiving access late is usually about provisioning and lifecycle management. A prompt about an authenticated user being unable to view a sensitive report is about authorization, not authentication. A prompt about a former contractor retaining VPN access points toward deprovisioning, access reviews, and governance failure.
Readers who want a structured route through all CISSP domains may choose a formal CISSP training programme, but Domain 5 itself is best studied by linking each concept to a practical access decision. The exam rarely rewards memorising terms in isolation; it tends to reward understanding which control solves which risk.
IAM, IGA, IDM, and directories are related but different
A common mistake is to treat IAM, identity governance and administration, identity management, and directory services as interchangeable labels. They overlap in real environments, but they answer different questions. IAM is the broad discipline of controlling identity, authentication, authorization, sessions, and access decisions. Identity governance and administration, often shortened to IGA, deals with lifecycle governance, access requests, segregation of duties, approvals, certifications, and access reviews.
Identity management, or IDM, is usually concerned with creating, updating, synchronising, and retiring identities across systems. Directory services provide identity stores and lookup mechanisms, such as Active Directory Domain Services, LDAP directories, or cloud identity platforms such as Microsoft Entra ID. From an exam perspective, this distinction matters because a lifecycle failure is not automatically an authentication failure, and a directory is not the same as a governance process.
In practice, these capabilities work together. A human resources system may trigger a joiner event, an IDM process may create the account, a directory may store the identity, IAM controls may enforce sign-in and access decisions, IGA workflows may approve sensitive entitlements, and PAM may control administrator elevation. If one layer is weak, the whole access model becomes harder to defend.
The identity lifecycle: joiner, mover, leaver
The joiner, mover, leaver pattern is one of the clearest ways to understand Domain 5. When an employee joins, the organisation must establish identity proofing requirements, create the account, assign baseline access, and apply least privilege. Birthright access should be limited to what the role genuinely needs, such as email, collaboration tools, and department applications.
When the same employee moves into a treasury role, the risk changes. The new role may require access to payment systems, financial reporting, or approval workflows. The previous access should be reviewed rather than carried forward automatically, because accumulated permissions create excessive privilege. This is where role engineering, segregation of duties, manager approval, and access certification become relevant.
When the employee leaves, speed and completeness matter. Accounts should be disabled or removed according to policy, active sessions should be revoked where feasible, tokens and devices should be handled, and privileged access should receive particular scrutiny. The exam angle is straightforward: leaver scenarios usually test deprovisioning, accountability, and the risk of orphaned accounts.
Privileged access adds another layer. Administrative accounts, service accounts, emergency accounts, and break-glass accounts need controls such as vaulting, just-in-time elevation, strong authentication, monitoring, and regular review. A break-glass account should exist for resilience, but it should be tightly protected, documented, excluded from fragile dependencies where appropriate, and audited after use.
Authentication: proving an identity claim
Authentication verifies that a subject is who or what it claims to be. In CISSP terms, a subject may be a human user, service account, workload, device, or process. The traditional factors are something known, something possessed, and something inherent, with modern implementations also considering context such as device health, network location, impossible travel, or risk signals.
Passwords remain common, but Domain 5 increasingly intersects with passwordless authentication. FIDO2, WebAuthn, and passkeys can reduce phishing risk by using cryptographic credentials bound to a domain and protected by a device or authenticator. The trade-off is operational rather than theoretical: organisations must plan account recovery, device loss, enrolment, accessibility, and support processes, because a strong authentication method can still fail as a programme if recovery workflows are weak.
Multi-factor authentication improves assurance when the factors are independent and resistant to common attacks. SMS codes, authenticator apps, hardware security keys, biometrics, and platform credentials do not all provide the same resistance to phishing or interception. CISSP candidates should focus less on vendor features and more on assurance, usability, enrolment, recovery, and the threat model.
Authorization: deciding what the identity may do
Authorization begins after authentication. It determines which resources a subject can access and which actions are permitted. A user may sign in successfully and still be blocked from a database, a file share, a cloud subscription, or an administrative console because authentication answers “who are you?” while authorization answers “what are you allowed to do?”
CISSP Domain 5 includes discretionary access control, mandatory access control, role-based access control, and attribute-based access control. In real environments, organisations often combine models. A cloud administrator may receive permissions through RBAC, a sensitive document may be protected by labels resembling MAC concepts, an application owner may manage a limited access list using DAC, and a conditional access policy may evaluate attributes such as device compliance or location.
- Use RBAC when access maps cleanly to job roles and the organisation needs repeatable administration at scale.
- Use ABAC when decisions depend on attributes such as department, data classification, location, device state, time, or transaction risk.
- Use MAC when centrally enforced labels and high-assurance separation are more important than user discretion.
- Use DAC when resource owners need flexibility, while recognising that consistency and auditability can suffer.
- Use policy-based controls when several signals must be evaluated together, especially in Zero Trust and cloud access scenarios.
The exam often presents authorization indirectly. If a scenario mentions excessive access caused by broad job roles, RBAC design may be the issue. If it mentions access that should vary by sensitivity, user attribute, or environmental condition, ABAC or policy-based access is likely relevant. If the concern is conflict of interest, segregation of duties and governance controls matter as much as the access model itself.
Federation, SSO, and modern identity protocols
Single sign-on improves usability by allowing a user to authenticate once and access multiple services without repeated sign-ins. Federation extends trust across organisational or application boundaries, allowing one identity provider to assert identity information to another service. These ideas are central to cloud and SaaS adoption because few organisations can afford to manage separate identities manually across every application.
The protocol details are commonly misunderstood. OAuth is primarily an authorization framework for delegated access to APIs; it is not, by itself, an authentication protocol. OpenID Connect adds an identity layer on top of OAuth flows so applications can receive information about the authenticated user. SAML is an XML-based federation protocol still common in enterprise SaaS and older web SSO integrations. SCIM supports automated user provisioning and deprovisioning between identity systems and applications.
Modern estates are rarely tidy. Legacy applications may lack federation support, older systems may depend on brittle custom SSO, and business applications may expose coarse entitlements that do not match least privilege. Practical mitigation starts with application inventory, federation where supported, compensating controls where it is not, entitlement rationalisation, and clear ownership for access reviews. For the exam, these scenarios usually test whether the candidate can balance security, usability, compatibility, and operational risk.
Zero Trust makes identity a primary control plane
Zero Trust principles have pushed identity decisions closer to every access request. Instead of assuming that network location is enough, modern access control evaluates identity, device posture, session risk, data sensitivity, and behaviour. Conditional access policies in platforms such as Microsoft Entra ID reflect this shift by combining user, device, application, and risk signals before granting access.
This does not remove the need for network controls, logging, endpoint security, or data protection. It changes the emphasis. Domain 5 concepts become part of a wider decision system in which authentication strength, authorization model, privileged access, and monitoring all contribute to whether access should be granted, challenged, limited, or blocked.
Identity threat defence also depends on detection and response. Suspicious sign-in patterns, impossible travel alerts, repeated MFA prompts, privilege escalation, dormant account use, and unusual service account behaviour should feed investigation and response processes. CISSP candidates should connect IAM to security operations rather than treating it as an administrative back-office function.
Access reviews, segregation of duties, and PAM
Governance controls help maintain access quality after the initial provisioning decision. Access reviews ask whether current entitlements remain appropriate. Segregation of duties prevents risky combinations, such as the ability to both create a supplier and approve payment to that supplier. Recertification gives managers or data owners a formal opportunity to confirm or remove access.
These processes are imperfect when entitlement data is unclear. Many organisations struggle because application permissions are named poorly, roles are too broad, or business owners do not understand what a technical permission allows. A defensible programme translates technical entitlements into business meaning, assigns ownership, and records decisions for audit.
PAM focuses on accounts and sessions with elevated impact. It includes controls for administrator accounts, root accounts, domain administrators, cloud subscription owners, database administrators, service accounts, and emergency access. Strong PAM programmes reduce standing privilege, monitor privileged sessions, rotate or protect secrets, and require stronger approval for high-risk actions.
How to study Domain 5 without memorising acronyms
Domain 5 is easier to study when each term is tied to a decision. Authentication decisions concern proof of identity. Authorization decisions concern permitted actions. Provisioning decisions concern account creation and changes. Governance decisions concern approval, review, policy, and evidence. Privileged access decisions concern elevated impact and abuse potential.
Practice scenarios should be original and situational rather than copied from exam dumps. For example, a question about a SaaS application that keeps active accounts after employees leave should lead the candidate toward lifecycle automation, SCIM, deprovisioning, and access reviews. A question about an API needing delegated access to a user's calendar should point toward OAuth concepts, while a question about signing the user into an application should bring OIDC or SAML into view depending on the architecture.
Standards and frameworks can help organise study, but they should not become a substitute for reasoning. NIST SP 800-63 is useful for digital identity and authenticator assurance concepts. NIST SP 800-53 includes access control and identification and authentication control families. ISO/IEC 27001 and ISO/IEC 27002 frame IAM within an information security management system. OWASP ASVS is helpful for application authentication and session management concepts. CISSP candidates should use these as reference points, then practise choosing controls under constraints.
Applying Domain 5 beyond the exam
The value of Domain 5 is that it connects security architecture to daily operational reality. Identity programmes fail when they rely on perfect processes that people cannot follow, or when access models look elegant on paper but do not match business roles, application limitations, or incident response needs. A strong answer, whether in an exam scenario or a design review, recognises those trade-offs.
A practical way to apply the material is to trace one sensitive business process from joiner access through privileged administration and eventual deprovisioning. That exercise exposes where authentication is strong, where authorization is too broad, where governance evidence is weak, and where emergency access may bypass normal controls. Readynez can support CISSP candidates who want guided preparation, but the lasting skill is the ability to analyse identity risk clearly and choose controls that fit the scenario.
