CISSP Domain 5, Identity and Access Management, covers the controls and processes that determine who can access which resources, a core knowledge area that has grown more important as organisations have moved from clearly bounded internal networks to cloud, SaaS and hybrid work.
Identity and Access Management, often shortened to IAM, is the discipline that ensures the right identities can access the right resources, under the right conditions, for the right reasons. In CISSP Domain 5, the focus is less on configuring a specific product and more on understanding how identity decisions reduce risk, support compliance and protect business processes.
The domain covers identification, authentication, identity proofing, authorisation, access control models, identity lifecycle management and accountability. It also connects directly to modern Zero Trust thinking, where identity, device state, context and continuous evaluation carry much of the security burden that older network perimeters once handled.
A commonly cited security finding is that 74 % av alla intrång include a human element, such as stolen credentials, social engineering, misuse of privileges or mistakes. The exact risk varies by organisation, but the lesson for CISSP candidates is stable: weak identity governance can undermine otherwise strong technical controls.
Varför Domain 5 är central i CISSP
CISSP is designed around security management judgement, not narrow tool operation. Domain 5 therefore tests whether a candidate can reason about identity as a control system: how accounts are created, how trust is established, how access is granted, how exceptions are governed and how misuse can be detected.
That makes IAM broader than login screens and password policies. A mature IAM programme links HR processes, directory services, cloud identity providers, privileged access management, application owners, audit evidence and incident response. If any part of that chain is weak, users may keep access after changing role, service accounts may become unowned, or administrators may hold standing privileges that exceed their operational need.
For candidates preparing for the CISSP-certifieringen, Domain 5 should be studied as a set of risk decisions. The exam is more likely to reward understanding of principles, policy choices and governance trade-offs than memorisation of vendor-specific menus.
IAM i praktiken: identitet som kontrollpunkt
IAM begins with identification, where a subject claims an identity, such as a username, employee ID, service principal or workload identity. Authentication then verifies that claim by using something the subject knows, has or is. Authorisation comes after authentication and determines what the authenticated identity may do.
This distinction matters because strong authentication does not automatically mean strong identity assurance. NIST SP 800-63 separates identity proofing from authentication strength: an organisation may require phishing-resistant MFA, yet still have weak assurance if the original enrolment process allowed the wrong person to obtain the account. CISSP scenarios often hinge on this kind of separation between related concepts.
In practice, a secure IAM design combines identity proofing, authentication, authorisation and accountability. A contractor may be identity-proofed through an onboarding process, authenticate with MFA, receive application access through a role, and have actions logged for review. If the contract ends, the same lifecycle must revoke access promptly and preserve records needed for audit.
Zero Trust och den nya rollen för IAM
Zero Trust makes IAM more visible because access is no longer treated as safe simply because a user is on a corporate network. The decision is based on identity, device posture, location, session risk, resource sensitivity and policy. In that model, IAM becomes a continuous control rather than a one-time gate.
A practical maturity path often starts with centralised identity, MFA for high-risk access and reduction of local accounts. The next stage is conditional access, stronger protection for administrators, device compliance checks and application integration through federation or single sign-on. More mature environments add risk-based policies, just-in-time privileged access, automated access reviews and signals from security monitoring.
This also explains why SSO alone is not a sufficient control. Single sign-on can improve usability and centralise enforcement, but without conditional access, MFA, logging and lifecycle controls it can also concentrate risk. A compromised identity may then become a convenient route into many connected services.
Moln, hybrid identitet och federation
Hybrid environments make Domain 5 more complex because identities often span on-premises directories, cloud identity platforms, SaaS applications and third-party federation relationships. A user may be created in HR, synchronised to Active Directory, represented in Microsoft Entra ID, assigned to SaaS groups and granted access through application-specific roles. Each step introduces possible delay, inconsistency or orphaned access.
Federation helps by allowing one identity provider to authenticate users for multiple services, but it also concentrates the need for strong governance. Trust relationships must be documented, claims must be controlled, and applications should receive only the attributes they need. When federation is loosely managed, old integrations and broad claims can become hidden access paths.
The Joiner-Mover-Leaver process is where these issues become tangible. Joiners need correct access quickly, movers need old access removed when their role changes, and leavers must be deprovisioned across all relevant systems. The difficult cases are often not normal employee accounts but shared mailboxes, service accounts, API tokens, emergency access accounts and SaaS identities that sit outside the main directory.
Autentisering, MFA och identitetsbevisning
Authentication methods vary in strength and operational risk. Password-only access is vulnerable to reuse, phishing and credential stuffing. MFA improves resistance by requiring an additional factor, but the quality of that factor matters. Push approvals can be abused through fatigue attacks, while phishing-resistant methods such as FIDO2/WebAuthn provide stronger protection against credential interception.
Even so, authentication is only one part of the assurance chain. If an identity was issued after poor verification, strong MFA may protect the wrong account very well. This is why onboarding, account recovery and credential reset processes deserve as much attention as login prompts.
For CISSP purposes, candidates should connect authentication choices to risk. A public information portal, a payroll system and a privileged administration console should not require the same controls. The more sensitive the resource and the more powerful the action, the stronger the authentication, monitoring and approval requirements should be.
Auktorisering: RBAC, ABAC, MAC och DAC
Authorisation determines what an authenticated subject can access and what actions are permitted. The classic models remain important because they help candidates reason about control design without being tied to one platform.
RBAC, or role-based access control, works well when job functions are stable and auditability matters. A finance analyst role, for example, can carry a standard set of permissions that is easy to review. Its weakness is role growth: if every exception becomes a new role, the model can expand into hundreds of poorly understood roles.
ABAC, or attribute-based access control, is better suited to dynamic environments where decisions depend on attributes such as department, data classification, device compliance, location or time. It can fit SaaS and cloud scenarios well, but it depends on clean attribute data. If attributes are inaccurate or unmanaged, ABAC policies can make confident but wrong decisions.
MAC and DAC are more specialised. Mandatory access control is appropriate where labels and centrally enforced policy dominate, such as highly regulated or classified environments. Discretionary access control gives resource owners more freedom, but that flexibility can weaken consistency unless ownership, review and logging are strong.
A useful decision rule is simple: use RBAC when roles are stable and reviewability is the main concern; use ABAC when context changes frequently and attributes are reliable; combine them when business roles provide the baseline and contextual policies refine access. Avoid choosing ABAC to escape poor role design, and avoid forcing RBAC onto highly dynamic SaaS access where attributes would express risk more accurately.
Åtkomstrecensioner, SoD och spårbarhet
Access reviews are often described as periodic certification of user access, but effective reviews are more than a spreadsheet sent to managers. They should give reviewers enough context to make a real decision: who the user is, what access they have, when it was last used, why it was granted, whether it conflicts with another permission, and whether the resource is sensitive.
Segregation of duties, or SoD, prevents combinations of access that create unacceptable risk. In a finance process, the same person should not be able to create a supplier and approve payment without compensating controls. In cloud administration, the same principle applies to roles that allow both policy weakening and evidence deletion.
Risk-based review is more practical than treating every permission equally. Privileged roles, sensitive applications, dormant accounts, external users and SoD conflicts deserve more frequent scrutiny. Lower-risk access can still be reviewed, but the review should not consume so much effort that high-risk decisions receive only superficial approval.
Ett kort exempel: JML, MFA och åtkomstrecensioner
Consider a company that hires a project manager for a regulated customer programme. HR creates the employment record, which triggers account creation in the directory and assigns a baseline role. The user receives access to collaboration tools, project documentation and a customer-specific SaaS portal through federation.
The initial access decision is only the first control point. Because the SaaS portal contains sensitive customer information, conditional access requires MFA and compliant device status. The project manager is not given administrator rights, and any request for elevated access must go through approval with a time limit.
Three months later the project manager moves to a different customer account. The mover process should remove the old project group, update attributes, revoke SaaS access tied to the previous customer and preserve audit logs. During the next access review, the application owner sees the role change, last-used data and remaining permissions, making it easier to remove residual access rather than approve it blindly.
This kind of scenario reflects the way Domain 5 is tested. The issue is not which button enables federation, but whether the candidate recognises lifecycle risk, least privilege, strong authentication, authorisation boundaries, review evidence and accountability.
Vanliga fallgropar i Domain 5
Some IAM weaknesses appear repeatedly in real implementations and in exam-style reasoning. They usually arise when convenience, legacy design or incomplete ownership displaces policy.
- SSO utan villkorlig åtkomst: centraliserar inloggning men lämnar riskbedömning, MFA och sessionskontroll för svaga.
- Roller som växer okontrollerat: skapar svårgranskade behörigheter och gör RBAC mindre begripligt.
- Manuella JML-flöden: leder lätt till försenad avprovisionering, särskilt i SaaS och externa konton.
- Servicekonton utan ägare: gör det svårt att rotera autentiseringsuppgifter, bedöma behov och upptäcka missbruk.
- Bristande loggning: försvagar ansvarsskyldighet, incidentutredning och revisionsbevis.
The countermeasures follow the same pattern: assign ownership, automate where the process is repeatable, apply least privilege, review access with context and protect privileged access separately. Standards and frameworks such as NIST SP 800-53, NIST SP 800-63, ISO/IEC 27001 and ISO/IEC 27002, and CIS Controls can help structure these controls, but the organisation still has to adapt them to its own risk profile.
Hur man studerar Domain 5 utan att fastna i verktyg
Effective preparation starts with the (ISC)² exam outline and then connects each topic to a business scenario. Candidates should be able to explain why a control is chosen, what risk it reduces, what trade-off it creates and what evidence would show that it works.
One common mistake is to study IAM as a vocabulary list. Terms such as RBAC, ABAC, federation, SAML, OIDC, PAM, MFA and SoD matter, but the exam often tests how they fit together. A question may describe a merger, a cloud migration, a privileged access problem or an audit failure, and the strongest answer will usually align with governance, least privilege and risk reduction.
A structured CISSP course from Readynez can help candidates place Domain 5 in context with the other domains, but the underlying study task remains the same: practise applying IAM principles to scenarios rather than memorising isolated definitions.
Att omsätta Domain 5 i säkerhetsarbete
Domain 5 is valuable because it sits close to everyday security operations. Identity decisions affect onboarding speed, user experience, audit readiness, breach containment, cloud adoption and third-party risk. Mature IAM therefore requires collaboration between security, IT operations, HR, application owners, compliance and business managers.
The key takeaway is that IAM should be treated as a living control environment. Accounts, roles, attributes, applications and business responsibilities change constantly, so policies must be reviewed and evidence must be maintained. Readers preparing for CISSP can use Readynez as one route for structured preparation, while practitioners can use the same Domain 5 concepts to strengthen Zero Trust, reduce standing privilege and make access decisions easier to defend.
