Identity and access management gets treated as a technology problem as opposed to a human one. Teams tend to obsess over SSO coverage, MFA rollout, role design, privileged access, and automation. To be fair, all of that matters. But the issue here is that most IAM failures don't start with a broken platform. They start with a person making a reasonable decision under bad conditions.
People request access, approve it, inherit it, work around it, and forget to remove it. I’ve seen too many active accounts over the years that belonged to staff who had long since departed the organization. Managers approve entitlements they don't really understand because someone needs to ship code by Friday. Contractor accounts can stay active for months because cleanup belongs to everyone, which means it belongs to no one. The control exists on paper. The human process around it quietly collapses.
Mature IAM programs treat user behavior as part of the control surface. Ignore the human layer, and your expensive tooling becomes a well-documented source of risk.
Friction drives bad access decisions
A user can't get into a system, so they ping a coworker for a workaround. A manager approves broad access because reviewing forty entitlements line by line is nobody's idea of a Tuesday. A team keeps shared credentials alive because the official process takes three days and the work takes one.
It should be clear that literally none of this is malicious in nature. It's friction, and friction always wins.
When access takes too long, people route around it and build side channels. When approval language is vague, reviewers make their best guess. When role design is messy, teams request the "safe" option, which in practice means more access than anyone needs. IAM teams call this an exception problem. It's a design problem wearing an exception costume.
A good IAM experience removes the need for judgment calls. Clear role names. Visible context: why the access is needed, who owns the app, what risk comes attached. Approvals routed to people who can actually evaluate them instead of whoever happened to be in the org chart. Security improves when the secure path is also the fast path. That's the whole trick.
More from Dave Lewis:
Dave Lewis
Dave Lewis
Lifecycle failures are human failures
Joiner, mover, leaver is where the human factor stops being theoretical. New hires need access on day one. Employees change roles faster than role models get updated. Departures don't propagate cleanly across every system. Every step depends on accurate input from HR, managers, app owners, and IT, which is a long chain of people who all have other jobs.
So the chain breaks. A manager sits on a transfer update, and an employee keeps access from a team they left in March. An app owner rubber-stamps a certification campaign because it arrived as a 400-row spreadsheet. A contractor lives outside the main HR flow, so their account outlives the contract, the project, and occasionally the vendor relationship itself.
These aren't edge cases. They're routine, and they create exactly the standing access attackers hunt for.
The fix is ownership and expiry dates. Every critical application gets a named owner. Every privileged role gets a review cadence. Every non-employee gets a sponsor and an end date that triggers actual deprovisioning, not a calendar reminder someone snoozes. Any process that depends on memory will fail, because memory is the least reliable system in your stack.
Strong authentication still depends on behavior
MFA is one of the most effective controls in IAM, and it still has a human failure mode. Users approve prompts on autopilot far too often. Help desks get sweet-talked into weak recovery steps. Service accounts get "temporary" exemptions that celebrate their third anniversary.
Security teams often misdiagnose this. They see resistance and conclude people hate security. People don't hate security. They hate bad implementation. Prompt someone eight times a day and they stop reading the prompt. Make recovery inconsistent and attackers will skip your MFA entirely and call your help desk instead. Make device registration confusing and adoption stalls right where you can least afford it.
Good programs design authentication around how people actually work. Stronger factors for higher-risk populations. Fewer, smarter prompts. Hardened recovery and identity proofing. And plain-language guidance on what a suspicious prompt looks like, because a user who has never seen one described will approve it.
Administrators are part of the risk model
The human factor doesn't stop at end users. IAM admins and service desk teams make high-impact decisions all day: urgent requests, exceptions, provisioning gaps, account recovery. Overload them or hand them poor tooling, and control quality drops fast, usually without anyone noticing until an audit does.
Good governance supports operators instead of just policing them. Clear runbooks. Narrow admin scopes. Peer review for sensitive changes. Logs a human can read without a decoder ring. It also means measuring where the process keeps breaking. Repeated manual overrides are a signal. So is an access review where 99.8% of entitlements get approved, which is less a review and more a formality with a progress bar.
IAM is only as strong as the decisions around it
IAM works when access is treated as a business decision with an owner, not an IT formality with a ticket number. Managers who approve access are accepting responsibility for it. Application owners have a real job, not a symbolic one. And security teams need to stop shipping controls that fail on contact with a normal workday.
If you want to improve the human factor, skip the old stalwart strategy deck and do this instead:
- Pull your ten most sensitive roles and rip out the entitlements nobody can justify.
- Map the staff add/remove (joiner, mover, leaver) flow for one business unit, end to end, and write down every step that depends on someone remembering something.
- Audit every single contractor account without a sponsor validation in the last 90 days.
- Run a tabletop on help desk identity recovery. Have someone play the attacker. They will win the first time, which is the point.
Then fix the spots where people are forced to guess, rush, or route around the process. IAM gets stronger when you treat humans as part of the system, because they always were. That's the difference between access control that works and access control that reports well.
