Identity and Access Management (IAM)

Identity and Access Management (IAM) is the area of cybersecurity that answers two simple questions: who or what is asking for access and what they are allowed to do. The first is authentication; the second is authorization. The goal of IAM is to make sure the right people, services and devices reach only the resources they actually need, and only when they need them. In other words, everyone gets exactly as much access as required and no more. This idea is known as the principle of least privilege.

How does authentication (AuthN) differ from authorization (AuthZ)?

These are two different steps that are easy to confuse. Authentication checks who you are. Authorization decides what you can do.

• Authentication (AuthN for short) confirms that someone is who they claim to be. It relies on three kinds of proof: something you know (a password or PIN), something you have (a hardware token, a FIDO2 key, a one-time TOTP code), and something you are (biometrics, such as a fingerprint). This is where SSO, MFA and identity federation operate.
• Authorization (AuthZ for short) grants a specific set of permissions, but only after successful authentication. This is where access control models (RBAC, ABAC) come in, along with the work of making sure no one has more access than they need.

An easy way to remember it: AuthN proves identity, AuthZ grants access. First you find out who is knocking, then you decide what they are allowed to do.

How does IAM work?

IAM manages an identity throughout its whole life, from creating an account to switching it off. A typical cycle looks like this:

1. Provisioning — creating an account and granting permissions, for example when a company hires an employee or registers a new service.
2. Authentication — checking the identity at sign-in, increasingly with an extra factor (MFA).
3. Authorization — setting the scope of access based on roles or attributes.
4. Session management and monitoring — tracking activity, logging events, re-checking for risky operations.
5. De-provisioning — removing access when someone changes role or leaves the company.

That last step is often neglected, and that is a common problem. When no one revokes access in time, you end up with orphaned accounts, and permissions pile up over time (privilege creep). Both make an attacker’s job easier.

What are the building blocks of IAM?

• Single Sign-On (SSO) — you log in once and reach many applications without typing your password again. It usually works through federation (SAML, OIDC).
• Multi-Factor Authentication (MFA) — requires at least two independent proofs of identity. The further you move from SMS and TOTP codes toward FIDO2/WebAuthn hardware keys, the harder it is to fool with phishing.
• Role-Based Access Control (RBAC) — permissions are assigned to a role tied to a job. It scales well, but the number of roles can grow quickly.
• Attribute-Based Access Control (ABAC) — decisions depend on attributes such as role, location, device type, time of day and resource sensitivity. It is more precise and flexible than RBAC.
• Provisioning and SCIM — automating account creation, updates and removal across systems using the SCIM (System for Cross-domain Identity Management) standard.
• Identity federation — accepting an identity from another, trusted organization without knowing its password. It works through a relationship between an identity provider (IdP) and a service provider (SP).
• Audit and reporting — a record of access events for regulatory compliance and security analysis.

Which federation protocols does IAM use (SAML, OIDC, OAuth)?

• SAML 2.0 — an XML-based standard for exchanging information about authentication and permissions between domains. It is the classic foundation of enterprise web SSO.
• OAuth 2.0 — a framework for authorization (not authentication). It lets an application get limited access to resources on a user’s behalf through tokens, without showing it the user’s password.
• OpenID Connect (OIDC) — an identity layer built on top of OAuth 2.0. It adds an ID token (in JWT format) that confirms who the user is. It dominates cloud and mobile applications.

A common mistake is treating OAuth 2.0 as a login protocol. OAuth only delegates access; the user’s identity is confirmed by OIDC built on top of it.

How does IAM differ from PAM and IGA?

• IAM is the broad discipline that covers all identities: employees, customers, partners, service accounts and machine identities.
• PAM (Privileged Access Management) is a narrow part of IAM focused on accounts with high privileges (administrators, root, service accounts). It includes a password vault, credential rotation, just-in-time access and session recording. Such accounts are a tempting target because they give broad control over infrastructure.
• IGA (Identity Governance and Administration) is the oversight layer: lifecycle management, periodic access reviews (recertification), access requests, separation of duties (SoD) and compliance reporting.

How does IAM relate to Zero Trust?

In a Zero Trust model, identity, not the network, becomes the main security boundary. Trust does not come from being “inside” the network or sitting behind a firewall. IAM provides three pillars of this approach: verify every request, grant as little access as possible, and assume a breach has already happened. In practice this means adaptive authentication, which scores risk based on signals such as device, location and behavior, continuous session checks and tight limits on the scope of access.

Why is IAM critical for security and threat detection?

Identity is now one of the most common routes of attack: credential theft, phishing, credential stuffing, session hijacking and abuse of privileged accounts. Tellingly, an attacker who obtains a real password often no longer has to break anything in — they simply log in. That is why classic methods can easily miss it.

For the SOC and network monitoring (NDR/SIEM), IAM data is a valuable source of warning signals:

• sign-in and access logs — unusual logins, ones that geographically could not happen (impossible travel), brute-force attempts and password spraying (testing one password across many accounts);
• MFA events — mass denials of requests or so-called MFA fatigue, which can be a sign of attack;
• permission changes — a sudden grant of an administrator role or a change to access policies;
• service-account and machine-identity activity — deviations from the norm that, combined with network traffic, may point to lateral movement, meaning an attacker moving across the network.

When you combine identity logs with network traffic data, you see not only who logged in but also what they are doing on the network. That is the basis for detecting account abuse and identity-based attacks.

How does IAM support regulatory compliance?

IAM provides the mechanisms required by standards and regulations, including GDPR, ISO/IEC 27001 and the NIS2 directive: enforcing least privilege, MFA, separation of duties, periodic access reviews and complete audit trails. They make it possible to answer who had access to what and when.

Learn more

• Zero Trust Architecture — IAM supports Zero Trust by verifying every user and access request.
• SaaS Security Posture Management (SSPM) — IAM helps control identities and permissions across SaaS apps.
• NIST Cybersecurity Framework — IAM supports NIST CSF identity management and access control practices.
• BYOD (Bring Your Own Device) — IAM helps restrict access to corporate resources from personal devices.
• API Security — IAM secures APIs by authenticating clients and enforcing authorization.
• Active directory — Active Directory is a common directory service used to manage IAM.