CISSP Domain 5 Revision: Identity and Access Management

Domain 5 has a reputation for being the most approachable domain on the exam, largely because identity and access concepts map closely onto systems most candidates use every day. That familiarity is worth treating with some caution. The exam draws fine distinctions between terms that sound almost interchangeable in casual use, and those distinctions are exactly what gets tested.

Controlling access to assets

The domain opens with a reminder that access control isn't limited to systems and data. It applies equally to information, systems, devices, facilities, applications and services, and a security programme that only controls access to one of those categories while leaving the others loosely governed has a gap an assessor will find quickly.

The underlying principle across all six categories is the same one introduced in earlier domains: access should be granted based on need, verified consistently, and reviewed on a schedule rather than assumed to remain correct indefinitely.

Designing an identification and authentication strategy

This objective covers a lot of ground, and it helps to separate the pieces by what problem each one solves.

Groups and roles organise access at scale. Assigning permissions to a role rather than an individual makes access easier to audit and easier to revoke cleanly when someone leaves or changes position.

Authentication, Authorisation and Accounting (AAA) is worth being able to define cleanly and distinctly: authentication proves who you are, authorisation determines what you're allowed to do once identity is established, and accounting records what was actually done. Multi-factor authentication strengthens the first of these by requiring more than one category of evidence, something you know, something you have, something you are, rather than relying on a single factor. Passwordless authentication removes the knowledge factor entirely, typically substituting a hardware token, biometric, or cryptographic key pair, on the reasoning that passwords are the weakest and most frequently compromised factor in the traditional model.

Session management governs what happens after authentication succeeds: session timeouts, token expiry, and protection against session hijacking, where an attacker steals a valid session rather than bothering to authenticate at all.

Registration, proofing and establishment of identity happens before any credential is issued. Identity proofing verifies that a person claiming an identity actually is who they say they are, using government identification, in-person verification, or increasingly, remote identity verification services. Weak identity proofing at account creation undermines every control built on top of it afterwards, since a strong authentication system protecting a falsely established identity is protecting the wrong thing.

Federated Identity Management (FIM) allows a user to authenticate once with an identity provider and use that identity across multiple, separately operated systems, removing the need for each system to manage its own credential store.

Credential management systems, password vaults among them, centralise the storage and issuance of credentials, reducing the number of places sensitive secrets are held in plaintext or duplicated across systems.

Single Sign-On (SSO) builds on federation, letting a user authenticate once and gain access to multiple applications without repeated logins. The trade-off worth remembering for the exam: SSO improves usability and reduces password fatigue, but it also concentrates risk, since a single compromised SSO credential can grant access to everything behind it.

Just-In-Time (JIT) access grants elevated or specific permissions only for the duration they're actually needed, rather than leaving standing privilege active indefinitely. This has become one of the more heavily tested newer concepts, reflecting a broader industry shift away from permanent privileged accounts toward temporary, audited elevation.

Federated identity with a third party

This objective extends federation specifically into scenarios involving an external identity provider, and the exam expects awareness of how the architecture differs across deployment models.

On-premise federation typically involves an internally hosted identity provider issuing assertions to internal or partner applications, often using SAML. Cloud federation shifts that identity provider role to a cloud-hosted service, common with providers offering identity as a service. Hybrid federation combines both, an on-premise directory synchronised with or trusted by a cloud identity provider, which is the pattern most large organisations actually run in practice given how few have fully abandoned on-premise directory services.

The security consideration that spans all three models is trust boundary management: federating identity with a third party means trusting that party's authentication process as if it were your own, which makes due diligence on a federation partner's security posture a genuine access control decision rather than a purely contractual one.

Implementing and managing authorisation mechanisms

This is one of the most reliably tested objectives in the domain, and the models are worth learning by comparison rather than in isolation.

• Role-Based Access Control (RBAC): access tied to job role. Efficient at scale, but can suffer from role explosion if roles aren't well managed, or from privilege creep when users accumulate old roles alongside new ones.
• Rule-based access control: access determined by a defined set of rules, often applied automatically, such as a firewall rule set or time-of-day restrictions.
• Mandatory Access Control (MAC): access decisions made centrally, based on classification labels, and not something the resource owner or user can override. This is the model underpinning Bell-LaPadula in practice.
• Discretionary Access Control (DAC): the resource owner decides who gets access. Flexible, but harder to enforce consistently across an organisation since decisions are distributed rather than centrally governed.
• Attribute-Based Access Control (ABAC): access decisions based on a combination of attributes, user department, device type, location, time of day, evaluated dynamically rather than fixed at the point a role is assigned. This offers finer granularity than RBAC but at the cost of greater policy complexity.
• Risk-based access control: adjusts access decisions dynamically based on assessed risk at the time of the request, an unusual login location or device triggering additional authentication requirements, for example.

Access policy enforcement ties these models to a practical architecture: the Policy Decision Point evaluates whether a request should be granted based on policy, and the Policy Enforcement Point actually carries out that decision by permitting or blocking the request. This separation matters because it allows policy logic to be centralised and updated without having to touch every enforcement point individually.

Managing the identity and access provisioning lifecycle

This objective covers the operational discipline of keeping access aligned with actual need over time, which is where a well-designed authorisation model can quietly fail if it isn't maintained.

Account access reviews, covering user, system and service accounts, catch privilege that should have been revoked but wasn't. Reviews need to cover all three account types, since service accounts in particular are often created for a specific integration and then forgotten long after that integration is retired.

Provisioning and deprovisioning need to be tightly coupled to HR processes: onboarding, offboarding and transfers should trigger access changes automatically wherever possible, since manual processes are where delay and error creep in. Deprovisioning on termination is the single most time-sensitive access control action in the entire domain, and exam scenarios frequently test whether a candidate understands that it should happen immediately rather than at the next convenient administrative cycle.

Role definition and transition matters most when someone moves internally rather than leaving. A transfer without a corresponding review of prior access is one of the most common causes of privilege creep, since old permissions are rarely removed automatically just because new ones were added.

Privilege escalation, including the use of sudo and equivalent mechanisms, needs to be both controlled and audited. The concern isn't only whether escalation happened, but whether there's a reliable record of who escalated, when, and why.

Service account management deserves specific attention because service accounts often carry high privilege, rarely rotate credentials, and don't benefit from the same lifecycle triggers as human accounts, since there's no HR event marking when a service account should be reviewed or retired.

Implementing authentication systems

This final objective is broad by design, tying together the practical deployment of everything covered above: choosing and configuring authentication protocols, integrating multi-factor authentication across an environment, and ensuring the authentication architecture actually reflects the strategy designed earlier in the domain rather than diverging from it during implementation.

Where AI now sits in Domain 5

Identity and access management now has to account for identities that aren't human at all. AI agents and the automated service accounts that support them need the same rigour applied to human identity: least privilege enforced properly, so an AI system can't gain access to sensitive data it doesn't need during training or execution, and the same provisioning lifecycle discipline covered earlier in this domain, since an AI agent left with standing privilege after its task is complete carries exactly the same risk as a human account nobody remembered to deprovision.

The relationship runs the other way too. AI is increasingly used to strengthen IAM itself, through behavioural biometrics and adaptive authentication that watch login patterns and flag anomalies in something closer to real time than a static rule set ever could. Worth holding both sides of that in mind for the exam: AI as something IAM needs to govern, and AI as a tool IAM increasingly relies on.

Final thought for revision

Domain 5 rewards precision on paired terms more than almost any other domain. MAC versus DAC, authentication versus authorisation, provisioning versus deprovisioning, RBAC versus ABAC: each pair sounds close enough in casual conversation to blur together, and the exam exploits exactly that blur. Build your revision around the distinctions rather than the definitions in isolation, and this domain tends to reward the effort more reliably than most.