Identity and Access Management (IAM) comprises the policies, processes and technical systems used to manage digital identities and control access. Across the identity lifecycle, IAM answers four questions: who is the identity, how does it prove that identity, what may it access and how is that access changed or removed in an auditable way?
Which components belong to IAM?
| Component | Purpose |
|---|---|
| Identity source | Manage users, devices, applications and technical accounts with clear ownership. |
| Authentication | Prove identity using a password, certificate, MFA or passkey. |
| Authorization | Translate roles, groups, attributes and policies into access decisions. |
| Provisioning | Create, adjust and remove access when people join, change roles or leave. |
| Federation and SSO | Use identities across application and organizational boundaries through SAML or OpenID Connect. |
| Governance | Approve, review, record and assign ownership for permissions. |
| Privileged access | Grant administrative and high-impact permissions separately, temporarily and under monitoring. |
Authentication is not authorization
A successful login establishes identity; it does not determine which data or functions may be used. Authorization must therefore be enforced at every relevant action. An application with a secure login can still contain Broken Access Control. Likewise, 2FA does not replace least privilege, role separation or secure sessions.
How do AD, Entra ID and IAM differ?
IAM is the overarching discipline. Active Directory primarily manages Windows domains, devices and Kerberos/LDAP-based access. Microsoft Entra ID governs cloud identities and SaaS or API access. Both can be components of an IAM architecture. Cross-application single sign-on commonly uses SAML or OpenID Connect.
Which IAM risks are common?
- Excess privilege:
Roles accumulate permissions, exceptions persist and technical accounts receive unnecessary access. - Orphaned identities:
Accounts for former staff, old applications or external partners remain active. - Unsafe recovery:
Password reset and helpdesk processes bypass strong authentication or allow account enumeration. - Federation mistakes:
Issuer, audience, signature or response correlation for SAML and OIDC messages is validated incorrectly. - Stolen sessions and tokens:
A secure login offers little protection after a long-lived token is taken over. - Unmanaged workloads:
API keys, service principals and CI/CD identities are neither inventoried nor rotated.
How is IAM implemented effectively?
- Define an authoritative identity source, owners and clear joiner-mover-leaver processes.
- Keep roles small, handle privileged access separately and prefer time-bound elevation.
- Use phishing-resistant passkeys or WebAuthn where the risk justifies it.
- Record access decisions, role changes, new applications and failed authentication without logging credentials.
- Have business owners recertify access and automatically disable unused identities.
- Test authentication, token validation and session management together.
Thank you for your feedback! We will review it and optimize this content.