Identity and Access Management (IAM) answers two questions: who is this user, and what are they allowed to do? Okta, Microsoft Entra ID (formerly Azure AD), Ping, and JumpCloud are the names that come up most often. Underneath the marketing, the building blocks are stable: SAML and OIDC for authentication, SCIM for provisioning, OAuth for delegated access. Complexity hides in the corners—guest access, contractor accounts, service principals, break-glass admins, and the perennial argument over where machine-to-machine authentication should live.
Most breaches that make headlines trace back to identity mistakes: stale accounts with too much access, MFA fatigue attacks, OAuth scopes granted years ago to a vendor that was later acquired by someone less trustworthy. Mature programs review privileged accounts quarterly, enforce phishing-resistant MFA (security keys or device-bound passkeys, not SMS), and treat session length as a tunable security setting rather than a UX irritation to minimize at all costs.
A practical maturity test: can the security team produce a list of every external SaaS application that has access to a specific employee’s mailbox, then revoke that access in under an hour with an audit trail? If the answer requires more than two people and a spreadsheet, the IAM program has gaps that no amount of EDR or SIEM spending will close. The same test applied to service accounts and CI/CD tokens usually reveals an even larger blind spot.