IAM Basics

What it is

Identity and Access Management is the framework of policies, processes, and technologies an organisation uses to manage digital identities and what those identities can do. It answers two fundamental questions: who is this user, and what are they allowed to do?

The core distinction underneath everything is between authentication and authorisation. People conflate these constantly, but they are different problems.

Authentication is the process of verifying that a user is who they claim to be. The classic categories of authentication factors are:

• Something you know. A password, a PIN, an answer to a security question. The cheapest factor, also the weakest, and the one that breaks most often.
• Something you have. A hardware token, a phone with an authenticator app, a smartcard, a FIDO2 security key. Stronger than knowledge alone because the attacker has to physically possess the thing.
• Something you are. Biometrics: fingerprint, face, voice, iris. Convenient but not infallible, and irrevocable when compromised.
• Somewhere you are. Location or context as a factor. A login from a known device on a corporate network is treated differently from a login from a foreign IP on an unknown browser.

Multi-factor authentication (MFA) requires evidence from two or more of these categories. Phishing-resistant MFA additionally requires that the second factor be cryptographically bound to the legitimate origin, which defeats the AitM proxy attacks that beat push-based and SMS-based MFA.

Authorisation is the process of deciding what an authenticated user can do. Two main models dominate:

• Role-Based Access Control (RBAC). Users are assigned to roles, and roles have permissions. A user in the "Accounts Payable" role gets the permissions associated with that role. RBAC is conceptually clean but creates "role explosion" in large organisations as exceptions multiply.
• Attribute-Based Access Control (ABAC). Permissions are evaluated dynamically based on attributes of the user, the resource, the action, and the environment. A finance employee can read a financial document if they are in the finance department, the document is classified as internal, the request comes during working hours, and the device is managed. ABAC is more expressive than RBAC but harder to implement and audit.

In practice, real systems mix the two. RBAC handles the bulk of access. ABAC adds context-sensitive overlays for high-risk actions.

Why it matters

Identity has become the new perimeter, in a sense the network used to be. The reasons trace through several long-term shifts:

Networks no longer define the boundary. With cloud services, SaaS applications, remote work, and mobile devices, employees and partners reach corporate resources from anywhere. The firewall stopped being the meaningful control years ago. The login is.

Most modern breaches are identity breaches. Verizon's annual breach report has put credential abuse and phishing at the top of breach causes for over a decade. The 2024 Snowflake-related incidents, the 2023 Caesars and MGM breaches, the 2022 Uber breach, and dozens of others all started at the identity layer.

Cloud and SaaS amplify identity risk. A single set of leaked admin credentials can give an attacker access to every customer, every database, every record an organisation has stored. There is no firewall to compensate. The login is the control.

Identities have proliferated. The average enterprise employee now uses dozens of distinct services, each with its own identity, often loosely federated. The opportunities for misalignment between intended and actual access have grown accordingly. Machine identities (service accounts, API keys, workload identities) typically outnumber human identities by ten to one in modern environments, and they receive less scrutiny.

Compliance increasingly requires it. SOX, PCI DSS, HIPAA, GDPR, and most industry frameworks have specific IAM requirements: MFA, periodic access reviews, separation of duties, audit logging. Failure here surfaces fast in audits.

The cost of getting IAM wrong is no longer measured in inconvenience. It is measured in tens of millions of dollars per major incident.

How attackers exploit IAM weaknesses

A few weaknesses appear over and over in real incidents.

Orphaned accounts. Accounts belonging to people who left the organisation but were never deprovisioned. They retain their access, their MFA does not get re-enrolled, and nobody is monitoring them because nobody is using them. When credentials leak, the activity goes unnoticed. The Cash App incident in 2022 involved exactly this pattern.

Over-privileged accounts. Users accumulate access over their tenure. Project A ended five years ago, but the access remains. The user moved from one department to another, and the old access was never revoked. Attackers who compromise the account get whatever the user has accumulated, not just what the user currently needs.

Shared admin accounts. Multiple people using the same root, administrator, or service account. Attribution becomes impossible, MFA becomes weak (because the credentials are in a shared password manager), and rotation requires coordinating with everyone who depends on it. The Snowflake incidents in 2024 exploited shared customer admin accounts that lacked MFA.

Stale service accounts. Service accounts created for a long-forgotten integration, with passwords that never rotate, no MFA, broad permissions, and no clear owner. They are the favourite target of attackers who got initial access through any vector. Service accounts often have far broader access than the most powerful human accounts.

Weak federation and SSO configurations. A misconfigured SAML trust, an OAuth grant flow that does not validate redirects properly, or a federation that accepts assertions from a compromised identity provider can let an attacker impersonate any user. The 2023 Microsoft mailbox breach (Storm-0558) exploited a stolen signing key to forge tokens for any tenant.

Legacy authentication. Protocols that do not support modern MFA. IMAP, POP3, basic-auth Exchange, and various older directory protocols still allow password-only access in many environments. They become the path of least resistance for credential stuffing.

Weak MFA factors. SMS-based MFA falls to SIM swapping. Push-based MFA falls to fatigue attacks and AitM proxies. TOTP falls to phishing. Each can be defeated by attackers who know what they are facing.

How to detect and remediate

The IAM observability picture has matured significantly in recent years. The signals worth tracking:

• Anomalous authentication patterns. Logins from unusual locations, impossible-travel scenarios, sudden device changes, or activity outside normal working hours.
• Failed authentication spikes. Credential stuffing campaigns produce distinctive patterns: many usernames, similar passwords, distributed source IPs. Detection at this layer catches attacks before they succeed.
• MFA prompt anomalies. A user receiving MFA prompts they did not initiate is a high-fidelity signal that someone has their password.
• OAuth grant changes. A user granting consent to an unfamiliar application can mean a successful consent phishing attack.
• Privilege escalation events. Group additions, role changes, and federation modifications that produce broader access deserve immediate review.
• Service account behaviour changes. Service accounts that suddenly start logging in interactively, accessing resources they have not touched before, or operating from new IP ranges.

The lifecycle of an identity covers four core stages, and each one needs explicit handling:

1. Provisioning. Creating the account with the right access from the start. Joiner workflows that map roles to actual job functions, integrated with HR systems, prevent the "access creep" that starts day one.
2. Modification. Updating access as the user's role changes. Mover workflows are usually the worst-handled lifecycle stage. Most organisations add access on a role change but rarely remove the old access. The result is the over-privileged accounts described above.
3. Recertification. Periodic review, usually quarterly or annually, where managers confirm that their team's access is still appropriate. Default revocation when access is not confirmed forces real review.
4. Deprovisioning. Removing access when the user leaves. Same-day revocation across all systems, integrated with HR offboarding, is the goal. Federated systems and forgotten SaaS apps are where deprovisioning fails most often.

For machine identities, a parallel lifecycle exists: secret rotation, ownership tracking, and retirement of unused service accounts. These often receive less attention than human identities and accumulate risk faster.

Best practices

• MFA everywhere. No exceptions. Including service accounts where technically possible (certificate-based authentication, workload identity federation, or at minimum strong rotated credentials with monitoring).
• Move toward phishing-resistant MFA. Passkeys and FIDO2 hardware tokens defeat AitM phishing. Push and SMS do not.
• Enforce strong password policies, then move past passwords. Block known-breached passwords at the password-set step. Adopt passwordless authentication for accounts that support it.
• Implement just-in-time elevation for privileged access. Standing privileged access is the riskiest configuration. JIT means the user gets admin rights for the specific task, then loses them when finished.
• Run access recertification quarterly for sensitive systems. Default revocation when access is not actively confirmed.
• Inventory and govern service accounts. Each one should have an owner, a business purpose, a documented permission set, and a rotation schedule.
• Disable legacy authentication. Block IMAP, POP3, basic auth, and similar at the tenant level unless there is a documented exception.
• Monitor identity activity centrally. A SIEM or identity threat detection platform that aggregates auth logs from your IdP, your SaaS apps, your cloud, and your VPN finds patterns that any single source misses.
• Plan deprovisioning before you provision. Knowing how an account will be removed is part of knowing how to create it correctly.

Where IAM meets zero trust

Zero trust as a framework rests on the assumption that the network does not provide trust. Every request is verified individually based on the identity, the device, the context, and the requested resource. IAM is the foundation that makes zero trust possible. Without strong identity, contextual authorisation, and continuous validation, zero trust collapses into marketing.

The practical version of this is that strong IAM enables several specific zero trust controls:

• Continuous authentication, where session validity is re-evaluated based on changing context rather than granted indefinitely after login.
• Device-bound credentials, where authentication is tied to a specific managed device.
• Conditional access policies, where the rules for granting access depend on the request context (user, device, location, resource sensitivity).
• Least-privilege enforcement, where users get the minimum access required for their current task, dynamically.

None of this works if your IAM cannot answer the basic questions reliably. Get the foundations right first.

On the limits of IAM

IAM is necessary but not sufficient. Several real risks lie outside its scope:

• A user with legitimate access who misuses it (insider threat) is not an IAM failure in the strict sense.
• An application vulnerability that lets an attacker bypass authorisation entirely is an application security problem, not an IAM one.
• A backup system or a database with no authentication at all is not protected by your IAM controls, however good they are.
• Supply chain compromises that occur upstream of your IAM (compromised vendors, dependencies, or build pipelines) often arrive with legitimate credentials.

A good IAM programme reduces the surface significantly and makes the remaining risks easier to detect and respond to. It does not, on its own, make an organisation secure.