CISSP: Identity and Access Design

Identity architecture determines who or what can act, how strongly that identity is established, what it may access, and how those rights change over time. CISSP Domain 5 treats identity as more than login technology. It includes physical and logical access, authentication strategy, federation, authorization models, provisioning, privilege changes, service accounts, and authentication systems across people, devices, applications, and services.

The current CISSP gives Identity and Access Management 13 percent. The design challenge is to make identity trustworthy enough for the risk while keeping authorization understandable, reviewable, and removable. A strong architecture does not rely on one authentication event to carry trust forever; it manages identity and access through the full lifecycle.

The most useful starting question is not ‘which IAM product should we buy?’ It is which subjects exist, which resources matter, what assurance is required, which relationships cross organizational boundaries, and how access should change when context or business role changes.

Identity proofing establishes the subject behind the account

Before authentication can mean much, the system must have confidence about who or what the identity represents. Human proofing may rely on employment, enrollment, identity documents, or trusted organizational processes. Devices and workloads may rely on registration, certificates, platform identities, or attestation. The required strength should reflect the risk of misidentification.

Weak proofing creates a permanent weakness because strong MFA on the wrong identity still authenticates the wrong subject. Enrollment, recovery, and credential reset processes deserve the same scrutiny as normal sign-in because attackers often target the weaker lifecycle path.

Authentication strength should match the access risk

Passwords, MFA, passwordless methods, certificates, biometrics, hardware-backed credentials, and contextual controls provide different assurance and operational characteristics. The design should consider phishing resistance, recovery, device trust, usability, offline scenarios, and the consequences of credential theft.

Session management matters after authentication. Long-lived sessions can preserve access after risk changes, while overly aggressive reauthentication can damage usability and push users toward workarounds. Risk-based access and continuous evaluation can help balance those concerns when implemented with understandable policies and reliable signals.

Authorization models encode business policy

Role-based access control is effective when permissions map cleanly to stable job functions. Attribute-based access can incorporate subject, resource, action, or environmental properties when roles would explode in number. Mandatory, discretionary, rule-based, and risk-based models each express different governance assumptions.

Architecture should avoid solving every edge case with a new role. Role explosion makes reviews difficult and can hide excessive privilege. Where attributes or policy rules are appropriate, they should be governed with the same discipline as roles: clear ownership, testable conditions, change control, and traceable decisions.

Federation extends trust beyond one identity store

Federated identity lets an organization rely on an external identity provider or cross-domain trust relationship. That reduces duplicate accounts and can centralize lifecycle management, but it also creates dependency on claims, token configuration, signing keys, metadata, federation agreements, and the partner’s identity assurance.

Designers should define which claims are trusted, how they map to local authorization, how compromised federation is contained, and what happens when the external relationship ends. Federation simplifies user experience only when trust boundaries and failure behavior are explicit.

Provisioning and deprovisioning are core security controls

Access should appear when a legitimate need begins and disappear when that need ends. Joiner, mover, and leaver processes connect HR or business events to accounts, groups, roles, licenses, entitlements, and physical access. Transfers are especially risky because users can accumulate old and new privileges if access changes only add rights.

Automation can improve timeliness, but automated provisioning still needs authoritative source data and exception handling. Access that cannot be mapped to an owner or business purpose should be challenged. Deprovisioning should include tokens, sessions, keys, delegated access, shared resources, and other forms of persistence beyond the primary account.

Privileged access needs stronger lifecycle and monitoring

Administrative access can change controls, identities, configurations, and evidence, so standing privilege should be minimized. Just-in-time access, separate administrator identities, approval, strong authentication, session recording, command or change logging, and rapid revocation can reduce exposure depending on the environment.

Separation of duties also matters. The same person should not be able to request, approve, execute, and conceal a sensitive action without independent evidence or compensating control. Privileged-access design is strongest when it makes exceptional power temporary and observable rather than merely protected by a stronger password.

Service accounts and non-human identities require ownership

Applications, automation, APIs, agents, and devices need identities too. Non-human accounts often become high-risk because they are long-lived, poorly inventoried, exempt from normal user reviews, or backed by static secrets. Architecture should prefer short-lived credentials or managed identity mechanisms where appropriate and track ownership throughout the workload lifecycle.

A service account is both an authentication subject and an authorization target. Teams need to know what it can access, who can impersonate or modify it, how credentials are protected, and what happens when the application is retired. Orphaned machine identities can preserve hidden access long after the original business purpose disappears.

Access reviews test whether authorization still matches need

Periodic and event-driven reviews should compare entitlements with current roles, responsibilities, contracts, and risk. Reviewers need enough context to make a real decision; a list of cryptic group names encourages rubber-stamping. High-risk privileges, dormant accounts, external users, and unusual combinations of access deserve additional attention.

Reviews also expose design problems. If managers cannot understand why a permission exists, the access model may be too complex. Repeated re-approval of stale exceptions can indicate weak lifecycle control. Review evidence should feed role redesign, automation, and deprovisioning improvements rather than remain a compliance artifact.

IAM architecture should fail in a controlled way

Identity services can become critical dependencies. An outage in authentication, federation, directory, token issuance, privileged access, or DNS can prevent legitimate work across many systems. Architecture should define resilience, cached or emergency access where justified, break-glass controls, recovery of signing keys or identity infrastructure, and how emergency access is audited afterward.

The CISSP certification treats IAM as part of a wider security architecture. Identity design must therefore work with network, application, data, assessment, operations, and governance controls rather than assuming authentication alone establishes security.

Identity and access design is a lifecycle discipline: establish identity, authenticate at the right assurance, authorize according to policy, federate trust carefully, provision and remove access promptly, control privilege, manage machine identities, and review entitlements with meaningful context.

CISSP-level IAM decisions are strongest when they remain understandable under change. The organization should be able to explain who has access, why they have it, how that access is enforced, how it is reviewed, and how it disappears when the need ends.

Identity data itself needs protection. Directories, identity attributes, authentication logs, recovery factors, biometric templates, and privilege records can reveal sensitive information or provide attackers with a roadmap. IAM architecture should classify that data, limit administrative access, protect synchronization channels, and retain evidence long enough for investigations without keeping unnecessary sensitive detail indefinitely.

Identity systems also need anti-abuse controls. Rate limiting, anomaly detection, impossible-travel or device signals, lockout logic, bot resistance, and monitoring for credential-stuffing or token theft can complement authentication strength. These controls should be tuned so attackers cannot cheaply exhaust accounts while legitimate users still have a recoverable path when authentication fails.

Mergers, acquisitions, divestitures, and contractor relationships expose the difficulty of identity lifecycle at scale. Temporary federation, duplicate identities, inconsistent role models, and unclear ownership can persist long after organizational change. Architecture should include an end state for trust consolidation or separation, not just a short-term connectivity plan that becomes permanent by inertia.

Identity governance should also address shared and generic accounts. Sometimes legacy systems or operational constraints make them difficult to eliminate, but shared credentials weaken accountability because actions cannot be reliably attributed to one individual. Where removal is not immediately possible, compensating controls such as credential vaulting, check-out, session recording, rapid rotation, and migration plans can reduce risk while preserving traceability.

Recovery is part of authentication design, not a help-desk afterthought. Lost devices, forgotten credentials, compromised factors, and emergency access all require recovery paths. If recovery is much weaker than normal authentication, attackers will target the recovery process instead. Strong IAM architecture therefore applies identity proofing, approval, logging, and rate limits to reset and recovery workflows with the same seriousness as primary sign-in.

Access architecture should also consider emergency and exceptional identities. Break-glass accounts, recovery administrators, vendor support identities, and temporary elevated roles can be necessary, but they should be few, strongly protected, monitored, and tested. An emergency account that has never been validated may fail when needed, while an emergency account used for convenience quietly becomes ordinary privileged access outside normal governance.

Identity architecture must also handle orphaned entitlements after applications are decommissioned or integrations are replaced. Old groups, federation trusts, service principals, API credentials, and privileged roles can outlive the system that justified them. Retirement checklists should therefore include entitlement cleanup, token/key revocation, audit-log preservation, and confirmation that no downstream dependency still relies on the identity path being removed.

That retirement step matters because identity is often the last hidden dependency to be removed.