CISSP Domain 5: Identity and Access Management

Domain 5 accounts for 13 percent of the current CISSP exam outline. It asks how an organization decides who or what is requesting access, how that identity is verified, what it may do, and how access changes over time.

Identity and Access Management (IAM) applies to more than employees signing in to applications. It also covers contractors, customers, administrators, devices, services, application programming interfaces, automation, cloud workloads, suppliers, and physical entry to facilities.

The strongest answer usually follows the complete identity lifecycle. An account that was approved correctly can still become dangerous if it is not reviewed after a transfer, disabled after termination, protected during privileged use, or removed when a service is retired.

1. Domain 5 map

The official outline divides Identity and Access Management into six objectives:

These objectives work as one process. Identity proofing connects an account to a person or entity. Authentication checks that the claimant controls an approved authenticator. Authorization applies policy to the requested action. Accounting records what happened. Lifecycle management keeps the identity, privileges, and evidence current.

2. Use the right decision order

A password, biometric reader, role, or federation protocol is not an IAM strategy by itself. Begin with the asset and business need.

A practical decision sequence is:

1. Identify the asset and owner. Determine who is responsible for approving access to the information, system, device, facility, application, or service.
2. Define the allowed work. State what the requester needs to do and why. Avoid granting a broad role when a narrower task is enough.
3. Classify the identity. Determine whether it represents a person, device, service, workload, supplier, customer, or automated agent.
4. Establish the identity. Register the subject, verify required evidence, and create a unique identity record.
5. Choose authentication strength. Match authenticators and assurance to the possible harm from impersonation or account takeover.
6. Apply authorization policy. Use roles, rules, attributes, labels, ownership, or changing conditions to decide what is allowed.
7. Enforce the decision. Ensure the application, gateway, operating system, facility control, or other enforcement point actually blocks disallowed actions.
8. Protect the session and credentials. Limit session duration, protect tokens and secrets, and require stronger checks for sensitive changes.
9. Record meaningful activity. Log approvals, authentication events, privilege use, policy decisions, and account changes.
10. Review and remove access. Recheck access after transfers, contract changes, inactivity, incidents, and termination.

When a question asks for the first action, identify the owner, requirement, and subject before choosing technology. When it asks for the best control, consider the complete lifecycle rather than only the login screen.

3. Separate identity, authentication, authorization, and accounting

These terms describe different steps:

Authentication, Authorization, and Accounting (AAA) is a common way to group the last three functions. AAA does not establish that the original identity record was trustworthy. Registration and identity proofing happen earlier.

A subject requests access. A subject may be a person, process, device, or service. An object is the information or resource being accessed. The requested operation may be read, write, approve, execute, enter, configure, or another defined action.

4. Control physical and logical access to assets

Access should be tied to the asset's owner, classification, business purpose, and approved method of use.

Domain 5 explicitly includes access to:

• Information: files, records, messages, datasets, secrets, models, and intellectual property
• Systems: servers, endpoints, cloud platforms, network devices, and industrial systems
• Devices: laptops, phones, removable media, sensors, consoles, and specialized equipment
• Facilities: buildings, rooms, cages, laboratories, wiring closets, and storage areas
• Applications: business applications, administrative consoles, software tools, and interfaces
• Services: databases, directories, cloud services, application programming interfaces, automation, and managed services

Physical and logical access should support the same policy. A person who is not approved to administer a server should not gain that ability merely by entering the server room. A remote administrator who is authorized logically may still require separate approval for physical entry.

Useful physical controls include badges, guards, locks, turnstiles, visitor procedures, alarms, cameras, and mantraps. Useful logical controls include accounts, device identity, network admission, application roles, encryption keys, and policy enforcement.

Tailgating occurs when an unauthorized person follows an authorized person through a controlled entrance. Piggybacking is often used for the same event, although some organizations use it when the authorized person knowingly allows the entry. The practical control is to require each person to authenticate and to train staff not to bypass the process for convenience.

Access paths matter. A user may be blocked by the application but still reach the database directly. An administrator may use a protected management portal but retain an unmonitored local account. Review every path to the asset, including recovery, vendor, service, and emergency access.

5. Register and prove an identity before relying on it

Registration creates an identity record. Identity proofing checks evidence that the applicant is the person or entity claimed. Enrollment connects approved authenticators and attributes to that identity.

The amount of proof should match the possible harm from a false identity. A public newsletter account needs less assurance than access to financial records, privileged administration, or a regulated service.

A sound process may include:

• Collecting only the information needed for the stated purpose
• Checking documents, records, devices, sponsors, or trusted sources
• Detecting duplicate, synthetic, or stolen identities
• Recording who approved the identity and which evidence was used
• Protecting proofing data because it can enable fraud if exposed
• Providing recovery and dispute processes
• Rechecking identity when important attributes change

A sponsor confirms that an identity has a valid organizational relationship, such as an employee, contractor, student, partner, or guest. Sponsorship does not replace proofing. It supplies business context and responsibility.

People, devices, and services require different evidence. A person may present documents and complete a live check. A managed device may be enrolled through inventory, configuration, and a device certificate. A service may be established through an approved deployment pipeline, owner, workload identity, and protected key.

Do not collect stronger identity evidence than the use case requires. Extra identity data increases privacy impact, storage obligations, and the damage caused by a breach.

6. Design authentication for the possible harm

Authentication checks whether the claimant controls one or more approved authenticators linked to an identity.

Authentication factors are commonly grouped as:

• Something you know: password, passphrase, or personal identification number
• Something you have: smart card, hardware token, phone, device-bound key, or authenticator application
• Something you are: fingerprint, face, iris, voice, or another biometric characteristic

Some systems also consider location, behavior, device condition, or time. These signals can strengthen a decision, but they are often better treated as context than as independent factors.

Multi-factor authentication (MFA) uses authenticators from at least two different factor categories. A password and two security questions are still one factor because both are things the user knows.

The goal is not to maximize the number of prompts. The goal is to make impersonation difficult without creating a recovery process that is easier to attack than the normal login.

Phishing resistance and passwordless authentication

A phishing-resistant authenticator does not simply reveal a reusable secret to any page that asks for it. It uses cryptography and the identity of the legitimate service so a fake site cannot replay the same proof elsewhere.

Passwordless authentication means the user does not enter a traditional password for that account. A passkey, smart card, or certificate can provide passwordless authentication. Passwordless does not automatically mean strong. The enrollment, device protection, recovery process, and verifier still matter.

Web Authentication (WebAuthn) allows a website to use public-key credentials stored by an authenticator. Passkeys are WebAuthn credentials designed for easier use across supported devices or accounts. The private key is not sent to the website.

Biometrics

Biometrics compare a measured characteristic with an enrolled reference. They are convenient, but they are not secrets. A person cannot simply replace a face or fingerprint after compromise.

Common performance measures include:

• False acceptance rate: how often an unauthorized person is accepted
• False rejection rate: how often an authorized person is rejected
• Crossover error rate: the point where false acceptance and false rejection rates are equal

Lowering one error rate can raise the other. The correct threshold depends on the use case. A high-security facility may accept more false rejections to reduce false acceptance, while a consumer device may prioritize usability.

Biometric systems need liveness detection, protected templates, fallback procedures, and another way to recover access. Privacy, accessibility, environmental conditions, and demographic performance should be considered before deployment.

Adaptive and risk-based authentication

Adaptive authentication changes the required proof when the context changes. A familiar managed device on a normal network may receive a standard check. A new device, unusual location, impossible travel pattern, sensitive action, or suspicious behavior may trigger stronger authentication or denial.

The decision should use reliable signals, explainable policy, and tested thresholds. A model that silently blocks legitimate users or learns from manipulated data can create security and operational problems.

7. Protect sessions, credentials, and recovery

Authentication creates or strengthens a session. The session then carries the identity between requests so the user does not repeat the full login for every action.

Session controls should address:

• Idle and maximum lifetime
• Renewal and reauthentication
• Protection of cookies, tickets, and tokens
• Binding to appropriate device or channel information
• Revocation after termination, password reset, compromise, or privilege change
• Step-up authentication for sensitive actions
• Concurrent session limits when appropriate
• Detection of stolen or replayed session material

A secure login followed by a weak session still exposes the account. Session identifiers should be hard to predict, protected in transit and storage, and invalidated when no longer needed.

Credential management covers creation, issuance, storage, use, rotation, recovery, revocation, and destruction. Credentials include passwords, keys, certificates, tokens, application secrets, and recovery codes.

A password vault stores secrets in a protected system and controls who or what may retrieve them. A vault is most useful when it also supports approval, rotation, checkout limits, logging, and removal of secrets from scripts and documents.

Recovery requires special attention. Help-desk resets, backup codes, alternate email, and device replacement can bypass strong normal authentication. The recovery path should provide assurance appropriate to the account and should produce useful alerts and records.

8. Use federation and single sign-on without confusing their purposes

Single sign-on (SSO) is the user experience of authenticating once and then reaching several authorized services without entering credentials again.

Federation is a trust arrangement in which one organization or service accepts identity information from another. Federated Identity Management (FIM) applies that trust across separate identity systems and administrative boundaries. Federation can provide SSO, but the two terms are not identical.

Common roles include:

• Identity provider (IdP): authenticates the subject and issues an assertion or token
• Service provider (SP) or relying party (RP): accepts the identity information and provides the application or service
• Credential service provider: registers subjects, binds authenticators, and manages credentials

The relying service must decide which issuer to trust, which claims to accept, how fresh the authentication must be, and what local access those claims should produce.

Common federation and delegated-access technologies

Do not use an access token as proof of identity unless the protocol and service explicitly define that use. Validate issuer, audience, signature, time limits, requested permissions, redirect locations, and token handling.

On-premises, cloud, and hybrid federation

• On-premises federation keeps identity services inside organization-controlled infrastructure.
• Cloud federation relies on provider-hosted identity services.
• Hybrid federation connects internal directories and applications with cloud identity and services.

The deployment location does not determine trust by itself. Review key protection, administrative roles, availability, privacy, logging, token validation, supplier access, recovery, and exit plans.

Federation can reduce password sprawl and centralize policy, but it also increases the effect of identity-provider failure or compromise. Strong protection and resilience are needed because one identity system may open many services.

9. Choose an authorization model that matches the policy

Authentication answers who or what is making the request. Authorization answers whether that identity may perform this action on this resource under these conditions.

Need to know limits access to information required for the task. Least privilege limits permissions and capabilities to the minimum needed. A user may hold a role but still lack need to know for a particular record.

Separation of duties divides a sensitive process among different people or roles so one person cannot complete every critical step alone. Dual control requires two authorized parties to act together. These controls reduce fraud, error, and misuse but need tested emergency procedures.

10. Separate policy decisions from policy enforcement

A policy must be translated into a decision and enforced at the point where the action occurs.

• A Policy Decision Point (PDP) evaluates policy and decides whether a request should be allowed.
• A Policy Enforcement Point (PEP) permits, blocks, redirects, or limits the requested action based on that decision.
• A Policy Information Point (PIP) supplies attributes or context used in the decision.
• A Policy Administration Point (PAP) is where authorized administrators create and manage policy.

For example, an access gateway may act as the enforcement point. It sends identity, device, resource, and context information to a policy engine. The engine makes the decision, and the gateway enforces it.

Do not assume enforcement is complete because a central engine made the correct decision. A bypass path, stale local cache, application defect, or direct database connection may ignore that decision.

Authorization should default to denial when no rule clearly permits the action. Policies should resolve conflicts predictably, record important decisions, and fail in a way that matches safety and business requirements.

11. Manage the complete identity and access lifecycle

The identity lifecycle is often described as joiner, mover, and leaver:

• Joiner: create the identity and grant approved starting access.
• Mover: update access when duties, location, project, employer, or contract change.
• Leaver: disable access promptly, recover assets, preserve required records, and remove credentials and sessions.

Transfers are a common source of excessive access. Adding the new role without removing the old one produces privilege accumulation.

A sound provisioning process includes:

• A unique identity for each subject
• An approved owner and business reason
• Role or entitlement selection based on defined policy
• Separation-of-duties checks
• Time limits for temporary access
• Independent approval for sensitive privileges
• Confirmation that provisioning completed correctly
• Notification to the owner and requester
• Records that support later review

Deprovisioning removes or disables access when the relationship or need ends. It may include accounts, sessions, tokens, keys, certificates, groups, application roles, physical badges, remote access, shared secrets, and supplier connections.

Access reviews and certification

An access review asks whether existing access is still appropriate. The reviewer needs enough context to make a real decision, including the identity, owner, role, entitlements, last use, risk, conflicts, and reason for access.

Review frequency should match the possible harm. Privileged, financial, regulated, supplier, and inactive accounts often need closer review than ordinary low-impact access.

A manager may know whether an employee still needs a business function, while an asset owner may better understand what a technical entitlement permits. High-quality reviews may need both perspectives.

A review that asks an approver to confirm hundreds of unexplained codes is not meaningful assurance. Improve the data and group decisions around understandable roles, resources, and actions.

Just-in-time access

Just-in-time (JIT) access grants privilege only when it is needed and removes it after a short period. The request may require approval, a ticket, strong authentication, a healthy device, and session recording.

Just-in-time provisioning creates or activates an account when the user first reaches a service, often based on a federation assertion. It reduces advance account creation, but it can also create unmanaged accounts if ownership, role mapping, and deprovisioning are not defined.

12. Control privileged access and non-human accounts

A privileged account can make high-impact changes, reach sensitive data, alter security controls, or manage other identities. Privileged work should use separate administrative identities rather than an everyday account.

Privileged Access Management (PAM) controls how privileged credentials and sessions are requested, approved, issued, monitored, rotated, and revoked.

Useful controls include:

• Separate named administrative accounts
• MFA and protected administrator workstations
• Time-limited elevation
• Approval and ticket linkage
• Credential vaulting and automatic rotation
• Command or session recording where appropriate
• Alerts for unusual privilege use
• Emergency accounts with strong storage and review
• Removal of standing privilege when JIT access is practical

The sudo command can allow approved users to run specific commands with elevated rights. Restrict allowed commands, record use, protect configuration, and review exceptions. Giving unrestricted sudo access is effectively giving full administrative power.

Service and workload accounts

A service account is used by an application, process, device, or automated task rather than by a person during normal interactive work.

Service accounts need:

• A named owner and purpose
• Minimum permissions
• Non-interactive use unless specifically required
• Secrets stored outside source code and scripts
• Rotation or short-lived credentials
• Monitoring that distinguishes expected automation from misuse
• Review after application, supplier, or architecture changes
• Removal when the service is retired

Shared service accounts can make accountability difficult. Prefer workload identities, certificates, managed identities, or other mechanisms that identify the specific system or instance.

13. Implement authentication systems as protected infrastructure

Authentication systems are high-value targets because compromise can open many other systems. Protect directories, identity providers, certificate authorities, domain controllers, token services, federation keys, recovery systems, and administrative consoles as critical infrastructure.

Common systems and protocols include:

Authentication infrastructure needs resilience. If the only identity provider fails, users may lose access to critical services. If emergency access is too easy, it becomes a bypass. Design redundant services, tested recovery, controlled emergency accounts, and clear procedures for degraded operation.

Log successful and failed authentication, enrollment, recovery, factor changes, federation changes, privilege elevation, token issuance, and administrative actions. Protect logs from alteration and send important events to independent monitoring.

14. Treat AI agents and automation as identities

An AI agent, robotic process, orchestration tool, or automated service can request data, call tools, change systems, and act on behalf of a user or application. It needs the same identity discipline as other non-human subjects.

Important controls include:

• Give each agent or workload a unique identity and owner.
• Grant only the tools, data, and actions required for its task.
• Separate development, testing, and production identities.
• Use short-lived credentials where practical.
• Require explicit delegation when an agent acts for a person.
• Record which user, agent, model, and tool performed each action.
• Prevent an agent from changing its own roles or credential policy.
• Recheck authorization before sensitive or irreversible actions.
• Remove access when the workflow, model, integration, or supplier is retired.

AI can also support adaptive authentication by identifying unusual behavior. That use still requires governed data, tested thresholds, human review, privacy safeguards, and a way to challenge incorrect decisions.

Do not allow a human user's broad session token to become a permanent agent credential. Delegated authority should be narrow, short-lived, auditable, and revocable.

15. Common CISSP exam traps

Choosing authentication before identity proofing

Strong MFA proves control of authenticators. It does not prove that the original identity record belongs to the correct person or entity. Establish the identity first.

Confusing authentication and authorization

A valid login does not decide which records, commands, or facilities the identity may use. Authentication verifies the claimant. Authorization applies access policy.

Calling OAuth an authentication protocol

OAuth 2.0 delegates limited access to an HTTP service. OpenID Connect adds an identity layer for authentication information.

Assuming SSO means one account has every permission

SSO reduces repeated authentication. Each service should still apply its own authorization policy and local controls.

Treating RBAC and rule-based access control as the same model

RBAC assigns permissions through roles. Rule-based control evaluates system rules and conditions.

Adding access after a transfer without removing old access

Mover events require both additions and removals. Otherwise privileges accumulate.

Protecting human accounts while ignoring services

Service accounts, workloads, devices, scripts, certificates, and API credentials can have broad access and long lifetimes. They need owners, lifecycle controls, and monitoring.

Using periodic reviews as a substitute for timely deprovisioning

A quarterly review is too late for a terminated administrator. Event-driven removal should happen when the relationship or need changes.

Assuming federation transfers responsibility

The relying service still decides which issuer and claims to trust, maps claims to local authorization, protects tokens, monitors activity, and plans for provider failure.

Making recovery weaker than normal authentication

An attacker will choose the easiest path. Help-desk resets, backup channels, and lost-device recovery need controls appropriate to the account's impact.

16. Domain 5 review checklist

You should be able to explain:

• [ ] The difference among identification, identity proofing, authentication, authorization, and accounting
• [ ] How physical and logical access should reinforce the same asset policy
• [ ] Why registration, sponsorship, proofing, enrollment, and recovery are separate activities
• [ ] The difference among knowledge, possession, and biometric factors
• [ ] Why two knowledge checks do not provide multi-factor authentication
• [ ] What phishing-resistant and passwordless authentication mean
• [ ] How biometric false acceptance and false rejection affect threshold decisions
• [ ] How session controls protect the period after authentication
• [ ] The difference between SSO and federation
• [ ] The different purposes of SAML, OAuth 2.0, OpenID Connect, and SCIM
• [ ] How RBAC, rule-based, MAC, DAC, ABAC, and risk-based access control differ
• [ ] The roles of policy decision, enforcement, information, and administration points
• [ ] Why least privilege, need to know, separation of duties, and dual control solve different problems
• [ ] How joiner, mover, and leaver events change access
• [ ] Why access reviews need understandable context and the correct owner
• [ ] The difference between just-in-time access and just-in-time provisioning
• [ ] How PAM controls privileged credentials and sessions
• [ ] Why service accounts and workload identities require named owners and lifecycle controls
• [ ] The purposes and main concerns of Kerberos, LDAP, RADIUS, TACACS+, and certificate authentication
• [ ] How identity controls apply to AI agents and delegated automation

17. Official references

• ISC2 CISSP Certification Exam Outline
• NIST SP 800-63-4: Digital Identity Guidelines
• NIST SP 800-63A-4: Identity Proofing and Enrollment
• NIST SP 800-63B-4: Authentication and Authenticator Management
• NIST SP 800-63C-4: Federation and Assertions
• NIST SP 800-162: Guide to Attribute Based Access Control
• NIST SP 800-53 Revision 5: Security and Privacy Controls
• NIST SP 800-207: Zero Trust Architecture
• RFC 4120: The Kerberos Network Authentication Service
• RFC 6749: The OAuth 2.0 Authorization Framework
• RFC 9700: Best Current Practice for OAuth 2.0 Security
• RFC 7644: System for Cross-domain Identity Management Protocol
• OpenID Connect Core 1.0
• W3C Web Authentication Level 3