What Is Identity and Access Management (IAM)? A Plain-English Model

A new hire starts Monday and needs email, the CRM and the shared drive. A salesperson moves into management and needs payroll reports. A contractor’s project ends Friday. An employee quits on bad terms. Each of these moments raises the same question: who should have access to what, right now?

Identity and access management, or IAM, is how organizations answer that question consistently instead of by memory and spreadsheets. It sounds like an enterprise-only topic, but even a 15-person company has dozens of apps and hundreds of permissions to keep straight. Stolen and misused credentials are behind a large share of breaches, which is why IAM sits at the center of modern security.

This guide connects the pieces, identities, authentication, authorization and lifecycle, into one clear model, then shows where to start.

IAM in one sentence

IAM makes sure the right identities get the right access to the right resources, for the right reasons, and lose it when they no longer need it.

That breaks into 4 questions every IAM program answers:

1. Who are you? Identity.
2. Can you prove it? Authentication.
3. What are you allowed to do? Authorization.
4. Should you still have that access? Lifecycle and governance.

Key takeaway: IAM isn’t one product. It’s a model that links who someone is, how they prove it, what they can do and when that changes. Tools help, but the model comes first.

Part 1: Identities, human and non-human

An identity is a digital record that represents someone or something that needs access. Most companies have more kinds than they realize:

• Employees in different roles and departments
• Contractors, partners and vendors who need limited, time-bound access
• Customers using your app or portal, often managed separately as customer IAM
• Service accounts and machine identities such as applications, scripts, APIs, servers and cloud workloads
• AI agents acting on behalf of users, an increasingly common category that needs the same discipline

The goal is one authoritative source for each identity, usually your HR system for employees and a directory or identity provider that every app trusts. When identity data is scattered across apps, nobody can say with confidence who has access to what.

Part 2: Authentication, proving who you are

Authentication verifies the identity is who it claims to be. The main building blocks:

• Passwords, still common and still the weakest link on their own
• Multi-factor authentication (MFA), which adds something you have or are. Our explainer on multi-factor authentication compares the types
• Phishing-resistant methods such as passkeys and FIDO2 security keys. See our guide to passkeys
• Single sign-on (SSO), which lets people sign in once to a central identity provider that vouches for them to every connected app. Our guide to single sign-on covers how it works

NIST’s Digital Identity Guidelines, SP 800-63 Revision 4, finalized in 2025, are the US government’s reference for this area. They define assurance levels for identity proofing, authentication strength and federation, and many private companies use them as a benchmark.

Part 3: Authorization, deciding what you can do

Authentication says who you are. Authorization says what you can touch. The common models:

Whatever the model, the guiding principle is least privilege: give each identity only the access it needs to do its job, nothing more. Least privilege is also a core principle of zero trust security.

Privileged access deserves special care

Admin accounts, domain administrators, cloud root accounts and finance approvers can do the most damage if compromised. Privileged access management (PAM) adds controls such as separate admin accounts, password vaulting, session recording and time-limited elevation.

Part 4: Lifecycle, joiners, movers and leavers

This is where most real-world IAM problems live. Access is easy to grant and easy to forget.

Joiners

When someone starts, they should get a standard set of access based on their role, automatically if possible. Many identity platforms can create accounts in connected apps when HR adds a new employee, a process called provisioning, often through the SCIM standard.

Movers

When someone changes roles, they should gain new access and lose old access. Skipping the second part leads to “privilege creep,” where long-tenured employees quietly accumulate access to everything.

Leavers

When someone leaves, every account should be disabled promptly, including SaaS apps, shared passwords, VPN or remote access, and any API keys they created. Our employee offboarding checklist walks through it step by step.

Part 5: Governance, proving access is still right

Governance closes the loop. It answers, “Is everyone’s access still appropriate?”

• Access reviews: Managers or app owners confirm or remove users’ access on a schedule, often quarterly for sensitive systems.
• Separation of duties: No single person should be able to both create a vendor and approve payments to it, for example.
• Logging and monitoring: Track sign-ins and changes, and alert on unusual behavior such as impossible travel or mass downloads.
• Evidence: Auditors for SOC 2, ISO 27001, HIPAA and similar frameworks will ask to see your access review records.

CISA and the NSA’s IAM guidance for administrators groups the discipline into identity governance, environment hardening, identity federation and SSO, MFA, and IAM auditing and monitoring, which maps neatly onto this model.

The IAM tool landscape

You don’t need every category. Here’s what each does and who typically needs it.

Well-known identity providers include Microsoft Entra ID, Okta and Google Workspace, and many small businesses start with the identity tools included in the productivity suite they already pay for. If you use Microsoft 365, our Microsoft 365 security guide covers the identity settings to turn on first. For apps outside SSO, see how to choose a business password manager.

Where to start: a 6-step IAM plan for a small business

1. List your apps and who uses them. A spreadsheet of systems, owners and users is the foundation for everything else.
2. Pick one identity provider and connect your most important apps to it with SSO.
3. Require MFA everywhere, starting with email, admin accounts, finance systems and remote access. Use phishing-resistant methods for admins.
4. Define 5 to 10 standard roles and the access each one gets.
5. Write a joiner-mover-leaver process tied to HR events, and automate provisioning where your tools allow it.
6. Run your first access review. Have each app owner confirm who should still have access. Expect to find old accounts.

For remote teams, how people reach internal apps is also part of the picture. Our comparison of VPN vs ZTNA explains how identity-based remote access works.

Common IAM mistakes to avoid

• Shared accounts that make it impossible to know who did what
• Admin rights by default for everyday users
• No owner for each app’s access decisions
• Ignoring service accounts, which often have broad permissions and passwords that never change
• Offboarding by memory instead of a checklist tied to HR
• Turning on MFA but allowing easy exceptions that become permanent

The bottom line

Identity and access management is how you control who can get into your systems and what they can do once inside. Think of it as 4 linked parts: identities, authentication, authorization and lifecycle, held together by governance. Start with one identity provider, MFA everywhere, clear roles and a reliable offboarding process. Those few steps close many of the gaps attackers rely on.

Sources

• NIST: SP 800-63-4 Digital Identity Guidelines implementation resources — Revision 4 final in 2025 and assurance levels for proofing, authentication and federation
• CISA and NSA: Identity and Access Management Recommended Best Practices for Administrators — IAM areas: governance, hardening, federation and SSO, MFA, auditing and monitoring
• CISA: CISA and NSA release Enduring Security Framework guidance on IAM — publication details and audience