What is Identity and Access Management (IAM)?

Every company eventually hits the moment where someone asks "who approved that access?" and nobody has a good answer.

Maybe an auditor found 200 active accounts belonging to people who left the company six months ago. Maybe a contractor still has write access to the production database. Maybe someone in marketing can approve their own purchase orders because they accumulated permissions across three role changes and nobody cleaned them up.

That is the moment identity and access management stops being a background IT task and becomes someone's full-time job.

IAM is the discipline, the tooling, and the organizational practice of answering three questions at scale: who should have access, how do they get it, and how fast does it get removed when they should not have it anymore.

Why IAM Exists

IAM does not exist because someone invented a product category. It exists because three forces converge once an organization reaches a certain size.

Regulatory pressure. SOX Section 404 requires public companies to prove they control access to financial systems. HIPAA demands audit trails showing who accessed patient data and when. PCI-DSS Requirement 7 mandates that cardholder data access is restricted by business need-to-know. These are not suggestions. Auditors show up, ask for evidence, and the company either has it or it does not.

Credential-based attacks. The Verizon Data Breach Investigations Report has found, year after year, that stolen or misused credentials are involved in roughly half of all breaches. That pattern holds because attackers follow the path of least resistance, and over-provisioned accounts with stale permissions are the easiest doors to walk through.

Scale. A mid-size company with 5,000 employees, each using 10 to 30 applications, is managing somewhere between 50,000 and 150,000 individual access relationships. People join, transfer, go on leave, come back, change roles, take on project work, and eventually leave. Every one of those events should trigger an access change. At that volume, spreadsheets and hallway approvals do not work.

The combination of these three forces is why IAM is a discipline with its own teams, budgets, tooling, and career paths. It is not a feature inside a security product. It is an entire operational function.

The Three Questions Every IAM Program Answers

Strip away the vendor marketing and the acronyms, and every IAM program is organized around three questions.

1. Who should have access?

This is the authentication and identity verification layer. Before anything else, the system has to confirm you are who you claim to be.

In practice, this means directories that store identity records (Active Directory, Microsoft Entra ID), single sign-on platforms that centralize login across applications (Okta, Ping Identity), and multi-factor authentication that adds a second proof of identity beyond a password.

If you have ever logged into a work application through a company SSO page and then been prompted for a push notification on your phone, you have interacted with this layer. The platforms behind it, Okta and Microsoft Entra ID being the two largest, handle billions of authentication events per day across their customer bases.

2. How do they get it?

Once the system knows who you are, it has to determine what you are allowed to do. This is the authorization and provisioning layer.

In most enterprises, access is granted through some combination of role-based access control (you get permissions because of the role you hold), birthright access (you automatically receive baseline access when you join a department), and request-based access (you submit a ticket for something beyond your default entitlements).

Identity governance and administration platforms like SailPoint and Saviynt automate these workflows. When HR records a new hire in Workday, the IGA platform reads the department, title, and location, maps them to a set of roles, and provisions access to the appropriate applications without anyone filing a ticket. The same logic should run in reverse when someone transfers or leaves.

3. How fast does it get removed?

This is the question most organizations answer worst.

Provisioning gets attention because people complain loudly when they cannot access their tools on day one. Deprovisioning gets neglected because nobody complains when a former employee still has access to Salesforce.

The result is orphaned accounts, accumulated permissions, and entitlement creep: the slow buildup of access that someone once needed but no longer should have. Access reviews are the standard control for catching this, though in practice they often fail because reviewers rubber-stamp approvals on entitlements they do not understand.

This third question is where most audit findings land, most compliance gaps live, and most breach exposure accumulates.

The Five Domains of IAM

IAM is not one thing. It is a family of related disciplines, each with its own tools, roles, and career tracks.

Workforce Identity and Access Management

This is the domain most people picture when they hear "IAM." It covers how employees and contractors authenticate and access internal applications.

The core capabilities are SSO, MFA, directory management, conditional access policies, and federation. The major platforms are Okta, Microsoft Entra ID, and Ping Identity. If you have ever configured a conditional access policy that blocks login from unmanaged devices or enforced MFA for admin accounts, you have done workforce identity work.

Identity Governance and Administration (IGA)

IGA is the plumbing layer. It handles user lifecycle management (joiner-mover-leaver), access request workflows, role management, access certifications, and segregation of duties enforcement.

The dominant platforms are SailPoint (IdentityIQ for on-premises, Identity Security Cloud for SaaS) and Saviynt. Oracle Identity Governance is still present in large enterprises. The work is process-heavy: designing role models, building approval workflows, cleaning up toxic combinations of access, and generating evidence for auditors.

Privileged Access Management (PAM)

PAM is focused on the accounts that can do the most damage: domain admins, root accounts, database administrators, service accounts with elevated permissions.

The core capabilities are credential vaulting (storing privileged passwords in an encrypted vault instead of in someone's head), session recording, just-in-time elevation (granting temporary admin access with automatic expiration), and break-glass procedures. CyberArk is the largest vendor. Delinea and BeyondTrust are the other major players.

PAM roles tend to sit closer to infrastructure and security operations than to the governance side of IAM.

Customer Identity and Access Management (CIAM)

CIAM handles the identity layer for external users: customers, partners, and consumers. The problems are different from workforce identity. Scale is larger (millions of users instead of thousands), registration and consent flows matter, and the experience has to be frictionless or people leave.

Auth0 (now part of Okta as Okta Customer Identity Cloud) and ForgeRock (now part of Ping Identity) are two of the primary platforms. If you have logged into a consumer application using "Sign in with Google" or managed cookie consent banners, you have seen CIAM at work.

Non-Human Identity and Cloud Entitlements

This is the newest domain and the one growing fastest. Service accounts, API keys, machine credentials, workload identities, and cloud IAM roles now outnumber human identities in most enterprises by a wide margin. Some estimates put the ratio at 45 to 1.

Cloud Infrastructure Entitlement Management (CIEM) tools analyze and right-size cloud permissions across AWS, Azure, and GCP. The broader non-human identity governance space is still forming. Traditional IGA platforms built for human users are retrofitting support for machine identities, while startups are building purpose-built solutions.

What IAM Looks Like in Practice

Abstractions are useful, but it helps to trace an actual workflow.

A new hire joins the finance department. On their start date, the HR team marks them as active in Workday with a department code, job title, manager, and office location. That record syncs to the IGA platform, which evaluates the attributes against a set of provisioning rules.

Because the new hire is in finance, they receive birthright access: an Entra ID account, a Microsoft 365 license, membership in the Finance security group, an SAP role for general ledger access, and a NetSuite viewer role. The IGA platform provisions all of this automatically through connectors to each target system. The employee logs in on day one, hits the company SSO page, enrolls in MFA, and has access to their tools.

Six months later, they transfer to marketing. HR updates the department in Workday. The IGA platform should detect the change, remove the finance-specific entitlements, and provision marketing access instead.

In practice, this is where things often break. The mover event is the hardest lifecycle event to automate cleanly because people carry project access, shared drives, and one-off entitlements that do not map neatly to department-based roles. The finance access stays. Three months later, an access review lands in the new manager's queue. The manager sees "SAP GL Access" for someone on their marketing team, does not know what it means, and approves it because rejecting access they do not understand might break something.

Entitlement creep. This is the operational reality that IAM programs exist to prevent, and the reason the work never ends.

IAM as a Career

IAM is not just a technology category. It is a job market.

Demand for IAM professionals has outpaced supply for years, particularly in identity governance and privileged access management. These are specialized skills, and most universities do not teach them. The pipeline is mostly people who started in adjacent IT roles and moved toward identity work over time.

Salary ranges vary by specialization and seniority. Entry-level IAM analyst roles typically pay $70,000 to $95,000. Mid-level engineers with platform-specific experience in SailPoint, Okta, or CyberArk earn $105,000 to $150,000. Senior architects and program leads with broad IAM experience can command $160,000 to $220,000 or more. The SailPoint salary guide and IAM skills that increase pay have more detailed breakdowns.

Most people do not start in IAM directly. They get there from help desk, systems administration, cloud administration, security operations, or compliance. The entry ramps are well-documented in our guide to breaking into IAM, and the career path options are more varied than most people expect.

Certifications like the CISSP, Microsoft SC-300, and vendor-specific credentials from SailPoint and CyberArk can help, but they work best when they validate existing experience. The certification guide covers which ones are worth your time and which ones are not.

Where IAM Is Heading

Three shifts are actively reshaping the field.

Non-human identity governance is becoming a distinct discipline. Machine identities, service accounts, API keys, and workload credentials already outnumber human identities in most enterprises. Managing them with the same tools built for human lifecycle management does not scale. Startups like Astrix, Oasis Security, and Clutch are building purpose-built platforms. The established IGA vendors are extending their products to cover non-human identities, but the gap between marketing claims and production readiness is still wide.

AI agents need identity. Autonomous agents acting on behalf of users, like Microsoft Copilot, Salesforce Agentforce, and ServiceNow AI agents, introduce a new identity type that does not fit cleanly into existing models. An AI agent that can read, summarize, and act on data needs its own access policies, consent boundaries, and audit trail. This is genuinely new IAM work that barely existed two years ago.

Identity is the perimeter. Zero trust is not a product. It is the architectural pattern of treating identity as the primary security control instead of network location. Conditional access policies in Entra ID, adaptive MFA in Okta, and device trust enforcement in Zscaler are already operating this way. For IAM professionals, this means the field is moving closer to the center of the security program, not further from it.

Where to Go From Here

If you are exploring IAM as a possible career move, start with how to break into IAM as a career for a practical roadmap, and browse entry-level IAM jobs to see what the market actually looks for.

If you already work in IAM and want to see how the field is organized, the IAM job categories show how roles break down by specialization, and the vendor directory maps the platforms you are most likely to work with.

Either way, IAM is a field where the work is growing faster than the workforce. The problems are real, the pay is good, and the demand is not slowing down.