When a company gets compromised, the cinematic image is wrong. The attacker rarely smashes through a firewall. Far more often they sign in, with a password that was phished, reused, or bought for the price of a coffee, and the system waves them through because, as far as it can tell, they are a legitimate user. Identity and access management (IAM) is the set of controls that answers two questions every system has to answer thousands of times a day: who is this? and what are they allowed to do? Get those two answers right and most attacks lose their easiest route in.

The quick version

  • Identity is proving who someone (or something) is, that's authentication. Access is what that proven identity is permitted to do, that's authorisation. IAM is the combined system for both.
  • Stolen credentials are the workhorse of modern attacks. Verizon's 2024 breach report found stolen credentials have featured in roughly a third of breaches over the past decade, which is why "who gets in" is a leadership problem, not just an IT one.
  • Two principles do most of the heavy lifting: least privilege (give each person only the access their job needs) and zero trust (verify every request instead of trusting anyone just because they're "inside the network").
  • The cheapest, highest-impact move is multi-factor authentication. Microsoft has reported it blocks over 99.9% of account-compromise attacks, and most organisations still haven't switched it on everywhere.

The idea in depth: authentication, authorisation, and the four jobs of IAM

It helps to separate two words that get used interchangeably and shouldn't be. Authentication is establishing identity, proving you are who you claim to be, classically through something you know (a password), something you have (a phone or hardware key), or something you are (a fingerprint or face). Authorisation is the separate question of what that identity is then allowed to reach. A receptionist and a finance director might both authenticate perfectly well; they should not be authorised to touch the same things. IAM is the system that handles both, plus the unglamorous lifecycle around them, creating accounts when someone joins, adjusting them when they change roles, and (the step everyone forgets) removing them when they leave.

So the practical frame for a leader is four jobs, not one acronym. Joiner: provision the right access on day one. Mover: change it when the person changes roles, and crucially, take away the old access, not just add the new. Leaver: revoke everything the moment they go. Reviewer: periodically check that the access people have still matches the access they need. The "mover" and "reviewer" jobs are where most organisations rot: people accumulate permissions like barnacles across a decade of role changes, and nobody ever scrapes them off. Put a recurring access review on the calendar, quarterly for sensitive systems, and treat "privilege creep" as a real risk, not a tidiness preference.

flowchart LR
  A(["Request to access
a resource"]) --> B(["Authentication
who are you?"])
  B --> C(["Authorisation
what may you do?"])
  C --> D(["Access granted
least privilege only"])
  B -.->|"fails"| X(["Denied"])
  C -.->|"not permitted"| X
Every access decision is really two decisions, proving identity, then checking permission. IAM is the system that makes both, every time. Leaders Loop

Least privilege: the oldest idea that still works

The single most durable principle in this field is also one of the oldest. In 1975, Jerome Saltzer and Michael Schroeder set out a now-classic list of security design principles in "The Protection of Information in Computer Systems", and the one that has aged best is least privilege: "every program and every user of the system should operate using the least set of privileges necessary to complete the job." The logic is brutally simple, you can't misuse access you were never granted, and an attacker who hijacks a low-privilege account can do less damage than one who lands on an admin.

Half a century on, the principle is everywhere in modern security guidance precisely because it limits the blast radius of any single failure. Start from zero and add; never start from "everyone can see everything" and trim. When someone asks for access, the question isn't "why not?", it's "what's the smallest grant that lets you do the job?" That includes standing access to production systems, which is the classic over-grant: many teams now issue it just in time, for a few hours when it's genuinely needed, rather than leaving it switched on permanently.

You can't misuse access you were never granted. Least privilege is the cheapest insurance in security.

An honest limitation. Least privilege is easy to state and hard to live with. Pushed too far, it generates a constant drizzle of access requests, frustrated employees, and shadow workarounds, people sharing logins or stashing data somewhere ungoverned just to get their jobs done. The point isn't to make access painful; it's to make it proportionate. If your least-privilege regime is so strict that staff are routing around it, you haven't secured the system, you've pushed the risk somewhere you can no longer see. Calibrate it against how sensitive the resource actually is.

Zero trust: stop trusting the network

The second big idea is a reaction to how badly the old model aged. For decades, security worked like a castle: a hard perimeter (the firewall) and a soft, trusting interior, once you were "on the network," you were largely trusted. That assumption collapsed the moment work went remote and data went to the cloud, because there is no longer a clean inside and outside. The response is zero trust, a term coined by analyst John Kindervag and later formalised by the US National Institute of Standards and Technology in Special Publication 800-207 (2020). NIST defines it as moving from implicit trust based on network location to continuous, per-request verification, "never trust, always verify." Identity becomes the core control, checked against device health and context on every request, not once at the door.

flowchart TD
  A(["Old model: castle & moat"]) --> B(["Inside the network
= trusted"])
  B --> C(["One stolen login
roams freely"])
  D(["Zero trust"]) --> E(["Verify every request
identity + device + context"])
  E --> F(["A stolen login is
checked, limited, contained"])
Zero trust drops the assumption that "inside" means "safe", every request is verified on its own merits. Leaders Loop

The reason this matters to a leader is in the breach data. Verizon's 2024 Data Breach Investigations Report found stolen credentials have appeared in roughly a third of breaches over the past ten years, the most reliable way in for attackers, ahead of both phishing and exploiting software flaws. In a trust-the-network world, one stolen login is a skeleton key. Under zero trust, that same login is just one signal among several, checked again at every step and confined to least-privilege scope. The point isn't to buy a product labelled "zero trust." It's to stop granting access on the basis of where a request comes from and start granting it on the basis of verified identity plus least privilege, everywhere.

An honest limitation. Zero trust is a strategy, not a switch you flip, and the marketplace has thoroughly muddied it, vendors slap the label on everything. NIST's own document is careful to call it an evolving set of principles you architect toward over time, not a finished product you install. Treat any pitch promising "zero trust in a box" with suspicion; the real work is incremental and mostly about identity hygiene, not a single purchase.

A worked example

Take a mid-sized professional-services firm, call it Harlow & Co, running on a familiar setup: a cloud email and document suite, a finance system, and a client database. (Illustrative scenario throughout; not a real company.) An attacker buys a batch of stolen credentials and finds that one belongs to a Harlow account manager whose password matched. They log in. Because the firm trusts anyone "signed in," that single login opens email, shared drives, and, since the account manager once helped on a finance project and was never de-provisioned, the finance system too. The attacker quietly forwards invoices to a new bank account. Nobody notices for weeks.

Now rerun it with the two principles in place. Multi-factor authentication means the stolen password alone fails, the login is challenged for a second factor the attacker doesn't have, and most of these attacks die right there. Suppose they get past it anyway through a sophisticated phishing kit. Least privilege means the account manager's leftover finance access was stripped in the last quarterly review, so the door to invoices is simply not there. And zero trust means the sign-in from an unrecognised device and country triggers an extra check before anything sensitive opens. The same stolen credential that was a skeleton key in the first telling is, in the second, a key that opens almost nothing.

flowchart TD
  A(["Stolen password
account manager"]) --> B{"MFA enabled?"}
  B -->|"No"| C(["Logged in,
trusted everywhere"])
  C --> D(["Reaches finance via
leftover access, fraud"])
  B -->|"Yes"| E(["Second factor fails
attacker stopped"])
  C -.->|"with least privilege"| F(["No finance access
damage contained"])
Same stolen credential, two outcomes. MFA stops most attempts; least privilege limits the few that get through. Leaders Loop

Nothing in the second telling required a big budget or a security team of twenty. It required MFA switched on everywhere, access reviewed so leftovers got removed, and sign-ins checked for context. That is IAM doing its job, and as cyber risk & incident response planning makes clear, the cheapest breach to handle is the one that never gets past the front door.

Frequently asked questions

What's the difference between authentication and authorisation?

Authentication proves who you are, passwords, a code from your phone, a fingerprint. Authorisation decides what you're allowed to do once you've proven it. They're separate steps: someone can authenticate perfectly (they really are who they say) and still be correctly denied access to a system that's none of their business. Good IAM keeps the two clearly distinct, because conflating them is how people end up with far more access than their identity should warrant.

Is multi-factor authentication really worth the friction?

By the numbers, it's the best return in security. Microsoft has reported that MFA blocks over 99.9% of account-compromise attacks, because a stolen password on its own stops being enough. It isn't perfect, sophisticated attackers can sometimes intercept or fatigue people into approving prompts, but the friction is small and the protection is enormous. If you do one thing after reading this, make it turning MFA on everywhere it isn't already, starting with admin accounts.

Should we still force everyone to change their password every 90 days?

Current guidance says no. NIST's digital identity guidelines (SP 800-63B) recommend against routine periodic password expiry, because forcing frequent changes drives people to weak, predictable patterns (Spring2026!, Summer2026!). Change passwords when there's evidence of compromise, encourage long passphrases, screen them against known-breached lists, and put the saved effort into MFA instead. This is a case where the old "best practice" actively made things worse.

What's "privilege creep" and why does it matter?

It's the slow accumulation of access rights as people move roles without anyone removing the old permissions. After a few years, a long-serving employee can quietly hold the keys to half the organisation, a huge prize if their account is ever compromised, and a temptation if they go rogue. The fix is dull but effective: periodic access reviews where managers confirm each person still needs what they hold, and anything unjustified is removed. Treat it as routine hygiene, like changing the locks when a tenant moves out.

Do small organisations really need all this?

The principles scale down cleanly, and the cheap parts are exactly the high-impact ones. A small firm won't run an enterprise identity platform, but it can turn on MFA, avoid shared logins, give people only the access they need, and remove accounts promptly when someone leaves. Attackers don't skip small organisations, they often prefer them, precisely because the basics are missing. The good news is that the basics are also the affordable bit.

Related in the Toolkit

IAM is one pillar of a broader security posture: it sits alongside how you reason about threats in the first place (security fundamentals & threat modelling) and feeds directly into what you do when something slips through (cyber risk & incident response).

Where to go next