Identity and Access Management Guide

What identity and access management is

Identity and access management (IAM) is the framework of policies, processes, and technologies that ensures the right individuals and machines access the right resources at the right times for the right reasons. It answers two fundamental questions for every access request: "Who are you?" (authentication) and "What are you allowed to do?" (authorization).

IAM is not a single product. It is a discipline that spans the entire identity lifecycle — from onboarding a new employee and granting initial access, through role changes and access reviews, to deprovisioning every account and credential when that person leaves the organization. It covers human users, service accounts, API keys, machine identities, and increasingly, AI agents that act on behalf of users or systems.

The scope of IAM has expanded significantly over the past decade. Traditional IAM focused on employees accessing on-premises applications through a corporate directory. Modern identity and access management must handle cloud-native workloads, SaaS applications, partner federations, customer-facing identities (CIAM), microservice-to-microservice authentication, and hybrid environments where resources span data centers, multiple cloud providers, and edge locations. Tools like Theodolite consolidate visibility across these environments so that IAM gaps — orphaned accounts, excessive permissions, missing MFA — surface in a single risk view rather than hiding in provider-specific consoles.

Every major security breach of the last five years involved an identity failure: stolen credentials, excessive privileges, unrevoked access, or a service account with more permissions than it needed. IAM is not a supporting function — it is the control plane that determines whether the rest of the security stack has anything meaningful to protect.

Core IAM components

A functioning IAM program consists of five interdependent components. Weakness in any one creates gaps that attackers reliably exploit.

Authentication

Authentication verifies the claimed identity of a user or system. It answers the question "Are you really who you say you are?" The strength of authentication determines the trustworthiness of every subsequent access decision.

• Single-factor authentication (passwords) — still the most common method and the most exploited. Credential stuffing, phishing, and password reuse make standalone passwords insufficient for any system that handles sensitive data.
• Multi-factor authentication (MFA) — combines something the user knows (password), something they have (hardware key, authenticator app), or something they are (biometrics). MFA blocks over 99% of automated credential-based attacks according to Microsoft's published data.
• Passwordless authentication — eliminates passwords entirely using FIDO2/WebAuthn security keys, platform authenticators (Windows Hello, Apple Touch ID/Face ID), or certificate-based authentication. Removes the phishing vector that MFA mitigates but does not eliminate.
• Single sign-on (SSO) — allows users to authenticate once and access multiple applications without re-entering credentials. Implemented via SAML 2.0, OpenID Connect (OIDC), or proprietary protocols. SSO reduces password fatigue and consolidates authentication policy enforcement.

The authentication method should match the risk level of what is being accessed. Email may warrant SSO with MFA. Production infrastructure access should require phishing-resistant MFA (FIDO2 keys) or certificate-based authentication. The security risk assessment process determines these thresholds.

Authorization

Authorization determines what an authenticated identity is permitted to do. Authentication without authorization is an unlocked door with a security camera — you know who walked in, but you did not control where they went.

• Role-based access control (RBAC) — assigns permissions through predefined roles (e.g., "Developer," "Finance Analyst," "SOC Operator"). Simple to implement and audit. Scales poorly in complex environments due to role explosion — organizations with hundreds of applications can accumulate thousands of roles.
• Attribute-based access control (ABAC) — evaluates access decisions against dynamic attributes: user department, data classification level, device compliance status, time of day, IP reputation, geographic location. More flexible than RBAC but harder to audit because decisions depend on runtime context.
• Policy-based access control (PBAC) — defines authorization rules as machine-readable policies (e.g., Cedar, OPA/Rego, AWS IAM policies). Enables fine-grained, auditable authorization that can be version-controlled and tested like code.
• Just-in-time (JIT) access — grants elevated privileges only when needed, for a limited duration, with approval workflows. Eliminates standing privileges that attackers exploit during credential compromise.

The principle of least privilege — granting only the minimum access required to perform a specific function — is the governing principle for all authorization models. In practice, governance frameworks enforce least privilege through periodic access reviews, automated deprovisioning, and segregation of duties policies.

Provisioning and deprovisioning

Provisioning creates user accounts and assigns appropriate access when someone joins the organization or changes roles. Deprovisioning removes all access when someone leaves. The gap between these two processes — where accounts exist with access they should not have — is one of the most exploited vulnerabilities in enterprise security.

Automated provisioning uses SCIM (System for Cross-domain Identity Management) or proprietary APIs to synchronize identity data between the authoritative directory and downstream applications. When HR marks an employee as terminated, automated deprovisioning should disable all accounts across every connected system within minutes — not days, not "when IT gets to the ticket."

The most dangerous provisioning gap is the "mover" scenario — an employee who changes roles but retains their previous access. Over time, movers accumulate permissions from every role they have held, creating excessive access that violates least privilege. Periodic access certification campaigns catch this drift, but only if managers actually review and revoke rather than rubber-stamping approvals.

Directory services

Directory services are the authoritative data stores for identity attributes: usernames, group memberships, organizational hierarchy, email addresses, authentication credentials, and policy assignments. They are the foundation on which authentication and authorization decisions are made.

• Microsoft Entra ID (formerly Azure AD) — the dominant cloud directory for organizations using Microsoft 365. Handles SSO, MFA, conditional access, and application integration.
• On-premises Active Directory (AD) — legacy directory still present in most enterprises. Often federated with cloud directories for hybrid environments.
• Okta / Google Workspace Identity — cloud-native identity providers used as primary directories by organizations that are not Microsoft-centric.
• LDAP directories — lightweight directory access protocol implementations used by Linux-based environments and legacy applications.

In hybrid environments, directory synchronization between on-premises AD and cloud identity providers creates a single source of truth for identity data — or it introduces conflicts and stale data when synchronization breaks. Directory health monitoring is an underinvested area that has outsized impact on IAM reliability.

Audit and monitoring

The audit layer records every authentication attempt, authorization decision, privilege escalation, and administrative change. Without audit logs, IAM is unverifiable — compliance frameworks cannot be satisfied, incidents cannot be investigated, and access reviews have no evidence basis.

Effective IAM audit includes: failed authentication attempt correlation (detecting brute force and credential stuffing), privilege escalation monitoring (who elevated to admin and why), access anomaly detection (a finance user accessing engineering repositories), dormant account identification (accounts that have not authenticated in 90+ days), and third-party access tracking (vendor accounts with persistent access to production systems).

IAM vs PAM vs IGA

Three related disciplines cover the full identity security landscape. They overlap but serve different purposes, and confusing them leads to coverage gaps.

Identity and access management (IAM)

IAM is the broadest category. It covers the full identity lifecycle for all users and systems: authentication, authorization, provisioning, directory services, SSO, MFA, and federation. When security professionals say "IAM," they typically mean the platform-level infrastructure that manages who can access what — Microsoft Entra ID, Okta, Ping Identity, or equivalent.

Privileged access management (PAM)

PAM narrows the focus to accounts with elevated permissions: domain admins, root users, database administrators, cloud infrastructure operators, service accounts with broad API access, and break-glass emergency accounts. PAM solutions (CyberArk, BeyondTrust, Delinea, HashiCorp Vault) provide credential vaulting, session recording, just-in-time privilege elevation, and standing privilege elimination.

The distinction matters because privileged accounts represent disproportionate risk. A compromised standard user account gives an attacker access to that user's data and applications. A compromised admin account gives an attacker access to every system that admin manages — and often the ability to create new accounts, disable security controls, and move laterally without detection.

Identity governance and administration (IGA)

IGA focuses on the governance layer: access certification campaigns, segregation of duties (SoD) enforcement, access request and approval workflows, policy-based provisioning rules, and compliance reporting. IGA platforms (SailPoint, Saviynt, ConductorOne, Opal) answer governance questions that IAM platforms do not: "Does this person's access comply with our policies?" "When was this access last reviewed?" "Who approved this exception?"

In practice, most organizations need all three. IAM provides the platform, PAM secures the highest-risk accounts, and IGA provides the governance and compliance evidence. The question is sequencing — organizations typically deploy IAM first (directory, SSO, MFA), add PAM when regulatory or risk requirements demand it, and layer IGA as the compliance program matures. A fractional CISO can help determine the right sequence based on the organization's risk profile and compliance obligations.

IAM for cloud and hybrid environments

Cloud environments fundamentally change the IAM challenge. On-premises, a single Active Directory domain could manage most access decisions. In cloud and hybrid environments, identity is fragmented across cloud providers, SaaS applications, containers, serverless functions, and APIs — each with its own identity model and permission structure.

Cloud provider IAM

Each major cloud provider has its own IAM system with different semantics:

• AWS IAM — policy-based with JSON policy documents attached to users, groups, and roles. IAM roles enable cross-account access and workload identity federation. AWS Organizations SCPs provide guardrails across accounts.
• Azure RBAC — built on Entra ID with role assignments scoped to management groups, subscriptions, resource groups, or individual resources. Privileged Identity Management (PIM) provides JIT elevation.
• Google Cloud IAM — resource-hierarchy-based with allow and deny policies. Workload Identity Federation eliminates service account keys for external workloads.

The cross-cloud challenge is real: an organization using AWS for compute, Azure for identity, and Google for data analytics has three separate permission models, three sets of audit logs, and three places where excessive permissions can hide. Cloud infrastructure entitlement management (CIEM) tools — and platforms like Theodolite that include CIEM capabilities alongside CSPM — aggregate this visibility so that an overprivileged service account in AWS does not go unnoticed while the security team focuses on Azure.

SaaS application identity

The average mid-market company uses 100 to 300 SaaS applications. Each has its own user accounts, roles, permissions, and (often) local authentication. The identity sprawl creates three specific risks:

• Shadow accounts — users sign up for SaaS tools using corporate email without IT involvement. These accounts bypass SSO, MFA, and provisioning controls.
• Orphaned access — when an employee leaves, HR triggers deprovisioning in the identity provider — but SaaS applications not connected to SCIM retain the account with full access.
• OAuth token sprawl — users grant third-party applications access to corporate data (Google Drive, Slack, GitHub) through OAuth consent. These grants persist until explicitly revoked and are rarely reviewed.

SaaS security posture management (SSPM) tools monitor SaaS configurations and identity settings, but the foundational fix is SSO consolidation: connecting every SaaS application to the central identity provider and requiring SAML/OIDC authentication with MFA. Applications that do not support SSO should be evaluated for replacement or subjected to compensating controls.

Machine identity and workload IAM

Machine identities — service accounts, API keys, certificates, tokens, and workload identities — now outnumber human identities in most cloud environments by a ratio of 10:1 or higher. They authenticate microservices to databases, CI/CD pipelines to cloud providers, monitoring tools to production infrastructure, and AI models to data stores.

Machine identity management requires: an inventory of all non-human credentials (many organizations cannot produce one), ownership assignment for every service account, automated credential rotation (90-day maximums for keys that cannot be eliminated), workload identity federation where possible (eliminating static credentials entirely), and anomaly detection for machine-to-machine authentication patterns. The compliance services engagement typically reveals that machine identity gaps are the most common finding in cloud environments.

Identity and access management best practices

The following practices separate organizations with functioning IAM programs from those with IAM products deployed but not operationalized.

Enforce MFA universally

MFA should apply to every human account with no exceptions. Partial MFA deployment — covering 80% of users but exempting executives, service desks, or legacy system users — leaves the most attractive targets unprotected. Phishing-resistant MFA (FIDO2 hardware keys, platform authenticators) is the standard for any account with administrative privileges or access to sensitive data.

Eliminate standing privileges

No human user should have persistent administrative access. Just-in-time (JIT) access — where elevated privileges are requested, approved, granted for a limited duration, and automatically revoked — reduces the window of exposure from permanent to minutes or hours. PAM solutions and cloud-native JIT tools (Azure PIM, AWS IAM Access Analyzer with policy generation) make this operationally feasible.

Automate the joiner-mover-leaver lifecycle

Manual provisioning does not scale and introduces errors — access that should have been revoked persists, and access that should have been granted is delayed. Connect HR systems (Workday, BambooHR, Rippling) to the identity provider via SCIM or API integrations so that employment status changes trigger immediate provisioning and deprovisioning actions. Mover workflows are the hardest to automate and the most important — they require both granting new access and revoking previous access simultaneously.

Conduct access reviews on a schedule

Periodic access certification — where managers review and confirm or revoke their direct reports' access — catches privilege accumulation, role drift, and orphaned accounts that automated deprovisioning missed. Quarterly reviews are the standard for privileged access; semi-annual reviews are typical for standard access. The reviews produce compliance evidence for SOC 2, ISO 27001, and HIPAA audits.

Consolidate identity providers

Every additional identity provider increases complexity, creates synchronization risks, and expands the attack surface. The goal is a single authoritative directory (or a tightly federated pair in hybrid environments) that serves as the source of truth for all authentication and authorization decisions. Applications that bypass the central IdP should be inventoried, evaluated for SSO integration, and — if SSO is not supported — subjected to compensating controls (dedicated MFA, enhanced monitoring, periodic manual access reviews).

Monitor and baseline identity behavior

Identity threat detection and response (ITDR) applies behavioral analytics to identity signals: impossible travel (login from New York, then Singapore 20 minutes later), credential stuffing patterns, token replay attacks, privilege escalation sequences, and anomalous service account activity. ITDR capabilities are increasingly embedded in identity platforms (Entra ID Protection, Okta ThreatInsight) and in security platforms that correlate identity signals with broader telemetry.

Evaluating IAM solutions

IAM purchasing decisions tend to be sticky — migration costs are high and the operational disruption of switching identity providers is significant. Evaluation should prioritize long-term fit over feature checklists.

Categories of IAM solutions

• Identity providers (IdPs) — Microsoft Entra ID, Okta, Google Workspace Identity, Ping Identity, JumpCloud. The core platform that stores identities, authenticates users, and federates access to applications.
• Privileged access management — CyberArk, BeyondTrust, Delinea (Thycotic + Centrify), HashiCorp Vault. Credential vaulting, session recording, JIT elevation.
• Identity governance — SailPoint, Saviynt, ConductorOne, Opal, Cerby. Access reviews, SoD enforcement, compliance reporting, access request workflows.
• Cloud infrastructure entitlement management — Ermetic (acquired by Tenable), CloudKnox (acquired by Microsoft), Wiz CIEM. Cross-cloud permission analysis, least-privilege recommendations, unused permission detection.
• Customer identity (CIAM) — Auth0 (Okta), Amazon Cognito, Firebase Auth, FusionAuth. Consumer/customer-facing authentication with social login, progressive profiling, and self-service account management.

Evaluation criteria

The following dimensions matter more than feature-list comparisons:

• Protocol support and integration depth. SAML 2.0 and OIDC coverage across the application portfolio. The number of pre-built SCIM connectors. API quality for custom integrations. Legacy protocol support (LDAP, Kerberos, RADIUS) for applications that cannot modernize.
• Automation capabilities. Lifecycle automation quality — how well joiner/mover/leaver workflows handle complex organizational structures, matrix reporting, and temporary project-based access. Policy-as-code support for version-controlled access rules.
• Hybrid and multi-cloud support. Native integration with AWS IAM, Azure RBAC, and GCP IAM. Ability to analyze and right-size cloud permissions. Support for hybrid Active Directory environments.
• Reporting and compliance. Out-of-box reports for SOC 2, ISO 27001, HIPAA, and PCI-DSS access control requirements. Access review campaign management. Audit trail completeness and retention.
• Total cost of ownership. Per-user pricing, minimum commitments, add-on costs for MFA methods and advanced features, professional services for implementation, and ongoing administration burden. IAM platforms with low license costs but high integration complexity can cost more in practice than premium platforms with strong automation.
• Vendor trajectory and ecosystem. Acquisition risk, roadmap alignment with zero-trust and AI-driven access management, community size, third-party ecosystem. The consolidation wave in identity (Okta acquiring Auth0, Thales acquiring OneSpan, CyberArk acquiring Venafi) makes vendor stability a legitimate evaluation factor.

A security risk assessment should inform the IAM solution selection by identifying which identity risks are most material to the organization — the tool selection follows from the risk profile, not the other way around.

IAM and compliance

Identity and access management is not a compliance requirement in itself — it is the operational foundation that makes compliance with access control requirements achievable. Every framework listed below mandates controls that are impossible to implement without functioning IAM.

SOC 2

The SOC 2 Trust Services Criteria include multiple access control requirements under the Common Criteria (CC6 series). CC6.1 requires logical and physical access controls. CC6.2 requires user registration and authorization. CC6.3 requires access removal upon termination or role change. The SOC 2 compliance checklist maps these to specific IAM capabilities: centralized authentication, role-based authorization, automated deprovisioning, and periodic access reviews with documented evidence.

ISO 27001

Annex A.9 of ISO 27001 covers access control comprehensively: business requirements for access control (A.9.1), user access management (A.9.2), user responsibilities (A.9.3), and system and application access control (A.9.4). The 2022 revision added A.5.16 (identity management) and A.8.5 (secure authentication) as standalone controls. ISO 27001 certification requires not just that controls exist but that they are documented, measured, reviewed, and improved — which maps directly to the IGA layer's access review and reporting capabilities.

HIPAA

The HIPAA Security Rule (45 CFR 164.312) requires access controls (unique user identification, emergency access procedures, automatic logoff, encryption), audit controls (recording and examining access to ePHI), and person or entity authentication. The Minimum Necessary Standard requires that access to protected health information be limited to the minimum necessary for the intended purpose — a direct mandate for least-privilege enforcement through IAM. Healthcare organizations that cannot demonstrate user-level access audit trails for ePHI systems face regulatory exposure.

PCI-DSS

PCI-DSS Requirements 7 and 8 address access control directly. Requirement 7 mandates restricting access to cardholder data by business need-to-know. Requirement 8 mandates unique user IDs, MFA for administrative access, strong password policies, and access revocation upon termination. PCI-DSS v4.0 (mandatory March 2025) added requirements for MFA on all access to the cardholder data environment, not just administrative access — expanding the IAM scope significantly.

Cross-framework alignment

The access control requirements across SOC 2, ISO 27001, HIPAA, PCI-DSS, NIST CSF, and CMMC overlap substantially. Rather than building separate IAM controls for each framework, mature organizations map a single set of IAM controls to multiple frameworks and produce framework-specific evidence from the same underlying system. This control-mapping approach — part of a broader compliance services engagement — reduces duplication, lowers audit costs, and ensures that improving one control improves compliance posture across all applicable frameworks.