Identity and Access Management (IAM) Reference

Identity and Access Management (IAM) is the discipline governing how digital identities are created, authenticated, authorized, and retired within information systems. Across US federal agencies, regulated industries, and private enterprises, IAM controls determine who can access which resources, under what conditions, and with what level of privilege. This reference describes the structural components, regulatory context, classification boundaries, and operational tradeoffs of the IAM sector as it functions across organizational and compliance environments.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• IAM implementation phases
• IAM component reference matrix

Definition and scope

IAM encompasses the policies, processes, and technologies that manage digital identities and control access to systems, data, and services. The scope extends across human users, service accounts, machine identities, and non-human entities such as APIs and automated workflows.

NIST Special Publication 800-63, the federal government's authoritative digital identity guideline, defines identity proofing, authentication, and federation as distinct functions — each requiring separate technical and procedural controls. The publication establishes three levels of assurance (IAL1, IAL2, IAL3 for identity; AAL1, AAL2, AAL3 for authentication) that calibrate rigor to risk.

IAM scope in practice covers five functional domains:

• Identity governance — lifecycle management of identities from provisioning through deprovisioning
• Authentication — verifying that a claimed identity is genuine
• Authorization — determining what an authenticated identity is permitted to do
• Privileged access management (PAM) — elevated controls for administrative and high-risk accounts
• Federation and single sign-on (SSO) — cross-boundary trust and credential sharing

The Zero Trust Architecture model, formalized by NIST SP 800-207, treats IAM as a primary policy enforcement mechanism rather than a perimeter boundary function, extending IAM scope to every access decision regardless of network location.

Core mechanics or structure

IAM systems operate through a chain of discrete technical functions that translate policy into enforcement.

Identity proofing and provisioning establishes the initial record. A user's claimed identity is verified against authoritative sources (government-issued ID, HR records, biometric data) before a digital identity account is created. NIST SP 800-63A defines three proofing levels tied to the risk profile of the target application.

Authentication verifies returning users. The four recognized factor categories are: something known (password, PIN), something possessed (hardware token, smart card), something inherent (biometric), and somewhere present (geolocation). Multi-factor authentication (MFA) combines at least 2 of these categories. CISA's MFA guidance designates phishing-resistant MFA — specifically FIDO2/WebAuthn and PIV/CAC — as the highest assurance tier.

Authorization is implemented through one of three primary models:

1. Role-Based Access Control (RBAC) — access granted by organizational role, standardized under NIST SP 800-207 and the earlier NIST Role-Based Access Control framework
2. Attribute-Based Access Control (ABAC) — access decisions evaluated against multiple attributes (user department, resource sensitivity, time of day, device posture)
3. Policy-Based Access Control (PBAC) — a superset of ABAC where access is governed by explicit machine-readable policies

Session management controls the duration and scope of authenticated sessions, including token expiration, session revocation, and continuous re-authentication triggers.

Privileged Access Management applies additional controls to accounts with administrative, root, or elevated permissions — including session recording, just-in-time (JIT) access grants, and approval workflows. PAM intersects directly with Insider Threat Programs because privileged accounts represent the highest-impact vector for both malicious insiders and compromised credentials.

Causal relationships or drivers

IAM investment and regulation are driven by four compounding factors.

Credential-based attacks dominate breach statistics. The Verizon 2023 Data Breach Investigations Report identified stolen credentials as the single most common breach entry point, involved in 49% of breaches analyzed in that cycle.

Regulatory mandates create compliance floors. The following frameworks impose specific IAM obligations:

• HIPAA Security Rule (45 CFR §164.312) requires unique user identification, automatic logoff, and audit controls — requirements that map directly to IAM provisioning and session management functions.
• CMMC 2.0 at Level 2 requires 110 practices from NIST SP 800-171, including access control (AC) and identification and authentication (IA) control families.
• PCI DSS v4.0 (Requirement 7 and 8) mandates least privilege access and MFA for all access into the cardholder data environment.
• FedRAMP requires cloud service providers serving federal agencies to implement NIST SP 800-53 control families AC (Access Control) and IA (Identification and Authentication) at the applicable impact level.

Cloud adoption expands the identity perimeter. Hybrid and multi-cloud environments dissolve the traditional network boundary, making identity the primary control point. This shift is documented in OMB Memorandum M-22-09, which mandated Zero Trust adoption across federal civilian agencies by fiscal year 2024, with IAM controls — specifically phishing-resistant MFA and enterprise-wide SSO — as Pillar 1 requirements.

Machine identity growth outpaces human identity management. Automated pipelines, microservices, and API integrations generate non-human identities that often carry elevated access without the governance controls applied to human accounts. The cybersecurity frameworks and standards landscape increasingly addresses machine identity as a first-class IAM object.

Classification boundaries

IAM is frequently conflated with adjacent disciplines. These boundaries define where IAM ends and adjacent domains begin.

PAM vs. IAM: Privileged Access Management is a sub-discipline of IAM, not a replacement for it. PAM focuses specifically on accounts with elevated system rights; IAM governs all identities including standard users, service accounts, and external parties.

Directory services vs. IAM: Microsoft Active Directory and LDAP-based directories are identity stores — they hold identity records and group memberships. IAM encompasses the policies, workflows, and enforcement mechanisms built atop directory data, not the directory itself.

CIAM vs. IAM: Customer Identity and Access Management (CIAM) addresses external user populations — consumers and business customers — with different UX, consent, and privacy requirements (notably CCPA and COPPA compliance) compared to workforce IAM.

Tradeoffs and tensions

IAM design involves structural tensions that cannot be fully resolved — only deliberately balanced.

Security vs. usability. Each additional authentication factor increases friction. Password complexity requirements demonstrably lead to credential reuse and insecure workarounds, as documented in NIST SP 800-63B's guidance explicitly discouraging periodic mandatory password resets in favor of breach-list checking.

Least privilege vs. operational efficiency. Strict least-privilege provisioning reduces blast radius from compromised accounts but increases provisioning overhead and creates access request backlogs. Just-in-time access models reduce standing permissions but require robust workflow tooling.

Centralized IAM vs. federated IAM. Centralized identity authorities (a single enterprise IdP) create a single point of failure. Federated architectures distribute trust but introduce complexity in token validation, revocation propagation, and audit trail reconstruction. The SIEM correlation of federated identity events presents a persistent operational challenge.

SSO convenience vs. blast radius. Single sign-on reduces password fatigue and enables centralized session control. A compromised SSO credential, however, grants access to every integrated application simultaneously — making SSO token protection critical.

Automation speed vs. governance rigor. DevOps pipelines generate service accounts and API keys programmatically, often outpacing IAM governance processes designed for human identity lifecycle management.

Common misconceptions

Misconception: MFA is sufficient protection against all credential-based attacks.
MFA defeats password spray and credential stuffing attacks but is vulnerable to adversary-in-the-middle (AiTM) phishing, SIM-swapping, and SS7 protocol attacks. CISA's phishing-resistant MFA advisory (2022) specifically distinguishes between phishing-resistant (FIDO2, PIV) and phishable (TOTP, SMS OTP) MFA implementations.

Misconception: Deprovisioning happens automatically when employees leave.
Automated deprovisioning requires integration between HR systems and IAM platforms through SCIM (System for Cross-domain Identity Management, defined in RFC 7644) or similar protocols. Without explicit integration, orphaned accounts persist — a condition that directly enables the threat category covered under insider threat programs.

Misconception: Active Directory is an IAM solution.
Active Directory is a directory service providing authentication (Kerberos, NTLM) and group policy enforcement. It does not inherently provide identity governance, access certification campaigns, SoD (Segregation of Duties) controls, or PAM workflow — components that constitute a full IAM program.

Misconception: Cloud identity and on-premises identity can be managed with identical tooling.
Cloud service providers operate proprietary identity planes (AWS IAM, Azure Entra ID, Google Cloud IAM) with distinct permission models, condition keys, and service control policies. Mapping on-premises RBAC roles to cloud entitlements requires explicit architecture decisions and is not automatic.

IAM implementation phases

The following sequence describes the discrete phases of an IAM program build or assessment, without prescribing specific vendor selection or organizational structure.

1. Identity inventory — Enumerate all identity types in scope: human users, service accounts, shared accounts, API keys, and machine identities across on-premises and cloud environments.
2. Authority source mapping — Identify the system of record for each identity attribute (HR system, Active Directory, LDAP, cloud IdP) and establish data ownership.
3. Access baseline documentation — Document existing access assignments, role definitions, and group memberships against the principle of least privilege.
4. Authentication assurance assessment — Evaluate current authentication mechanisms against NIST SP 800-63B assurance levels and identify gaps (e.g., SMS-based MFA where AAL2 phishing-resistant is required).
5. Authorization model selection — Define whether RBAC, ABAC, or PBAC is appropriate for each application tier based on data sensitivity and operational variability.
6. Lifecycle workflow design — Define joiner, mover, and leaver (JML) processes with integration points to HR, ticketing, and directory systems.
7. Privileged account governance — Inventory all privileged accounts, apply PAM controls (session recording, JIT, approval workflows), and schedule quarterly access reviews.
8. Federation and SSO configuration — Configure SAML 2.0 or OIDC-based federation for integrated applications, establish IdP trust relationships, and define token lifetime policies.
9. Audit and access certification — Implement periodic access review cycles (at minimum annually for standard access; quarterly for privileged access) with documented revocation workflows.
10. Continuous monitoring integration — Feed IAM events (failed authentications, privilege escalations, after-hours access) into the security operations center or SIEM platform for anomaly detection.

IAM component reference matrix

The information security fundamentals framework positions IAM as one of three foundational control categories alongside network security and data protection — reflecting the sector-wide consensus that identity controls represent the primary preventive layer in modern security architecture.

References

• NIST SP 800-63-3: Digital Identity Guidelines — National Institute of Standards and Technology
• NIST SP 800-207: Zero Trust Architecture — National Institute of Standards and Technology
• NIST SP 800-162: Guide to ABAC Definition and Considerations — National Institute of Standards and Technology
• NIST SP 800-53 Rev 5: Security and Privacy Controls — National Institute of Standards and Technology
• CISA: Implementing Phishing-Resistant MFA — Cybersecurity and Infrastructure Security Agency
• CISA: Multi-Factor Authentication Guidance — Cybersecurity and Infrastructure Security Agency
• OMB Memorandum M-22-09: Moving the U.S. Government Toward Zero Trust — Office of Management and Budget
• HIPAA Security Rule: 45 CFR Part 164 — U.S. Department of Health and Human Services
• FedRAMP Program Overview — General Services Administration