Identity and access management (IAM) is the discipline that answers two different questions that are confused all the time: who each person is, and what each person can do once inside. The first is authentication. The second is authorization. A system can get the first right and fail spectacularly at the second, and in fact that is the most common case.
In short: IAM is the set of rules, processes and tools that decide who gets in, what they get into and until when.
Why did identity become the most important thing?
For twenty years, security was organized around a perimeter. There was an inside and an outside, and the boundary was the office network. Everything inside was considered reasonably trustworthy.
That model fell apart for three reasons at once: people started working from anywhere, applications moved to the cloud and external vendors needed access to internal systems. There is no longer an inside. There are identities accessing resources from wherever they are.
When the network perimeter disappears, the only thing left between an attacker and your data is an identity and what that identity is allowed to do. That is why IAM stopped being an administrative matter and became the most decisive security control a company has. The zero trust architecture published by NIST puts it bluntly: when the network stops being the boundary, identity takes its place.
What are its components?
- Identity. The record of who exists: employees, contractors, vendors, and also systems. It is the master list, and it is almost always out of date.
- Authentication. Proof that whoever shows up is who they claim to be. This is where passwords and multi-factor authentication.
- Authorization. What that identity can do once confirmed. Read, write, delete, approve payments, export the customer database.
- Governance. Who decides those permissions, how often they are reviewed and who is accountable if they are wrong. It is the piece almost nobody has, and the one that turns IAM into something that works over time and not just on the day it was installed.
Why does authorization fail more than authentication?
Because authentication has a binary, verifiable answer: either the person proved they are who they claim to be or they did not. It is a closed problem with a known solution, and that is why it has improved so much in recent years.
Authorization has no single answer. Whether someone in finance can export the customer list may be perfectly fine or a disaster, and it depends on the role, the moment and the purpose. There is no way to verify it automatically, because the correct answer lives in the head of someone on the business side and not in any system.
That explains why the OWASP Top 10, the industry reference on the most serious application flaws, ranks broken access control first on its list. Not the weak password, not the poorly implemented encryption. The misplaced permission.
And it is a silent failure: an extra permission produces no error, no alert and no complaint. It works perfectly until the day someone uses it for something they should not.
What is the identity lifecycle?
Every identity goes through three moments, and the interesting one is not the one you would think.
Onboarding. Someone new joins and needs access to what they need. This almost always works, because if it fails the person cannot work and complains the same day.
Role change. Someone changes roles or departments. They are given the new permissions, and this is where the first crack appears: the old ones are almost never removed. Someone who has been at the company for eight years and has passed through three departments accumulates the access of all three.
Offboarding. Someone leaves. And this is the moment when everything breaks, because unlike onboarding, if offboarding fails nobody complains. The system keeps working exactly the same with a live account belonging to a person who no longer works there. There is no symptom, no ticket, no one inconvenienced.
A control whose failure causes no inconvenience is a control that degrades on its own. That is why it has to be measured instead of trusting that it was done.
What are the three problems that always show up?
When a mid-size company's IAM is audited for the first time, these three show up, in this order and with boring regularity.
Accumulated permissions. People with access they needed three years ago for a project that ended. Nobody removed it because nobody was looking and because removing it has a cost, the risk of breaking someone's work, while leaving it has no apparent cost at all.
Orphaned accounts. Active accounts with no identifiable owner. They belong to people who left, contractors whose work ended, a project that was canceled. They are an attacker's favorite target, because their activity surprises no one: nobody expects anything from them, so nobody notices if they suddenly do something.
Shared accounts. A user account shared by four people because the license is expensive or because it has always been done that way. The moment something happens with that account, there is no way to know who it was. And that turns any subsequent investigation into a guessing game.
And what about identities that are not people?
This is the fastest-growing part and the worst managed.
In any modern company there are many more identities than employees. Service accounts connecting two systems, API keys an application uses to talk to another, integrations someone configured two years ago, bots that run processes overnight. And, more recently, artificial intelligence agents that read emails, query databases and execute actions.
All of them are identities. All of them have permissions. And almost none of them have the three things a person's identity does have: a named owner, an expiration date and an offboarding process.
They also tend to have more permissions than they need, for a very human reason: nobody wants to be debugging a permissions error at three in the morning, so more is granted so that it works the first time. That excess stays there forever.
And there is a detail that makes them especially uncomfortable from the detection side: an automated identity that works in the early morning hours, touches many systems in a row and acts faster than any person looks a lot like a compromised account in the logs. Telling one from the other is not solved with a rule; it is solved by knowing how each one normally behaves.
What can be measured?
IAM has the advantage that it can be measured well, without buying anything. Four numbers any company can pull this quarter:
- Active accounts with no identifiable owner. If it is greater than zero, you already know where to start.
- Time between a person's departure and the closing of all their access. Not just email. All of them.
- Accounts with administrative permissions. Compare the number with the number of people who actually need to administer something.
- Non-human identities with no assigned owner. This is usually the most uncomfortable number of the four.
How do you start without launching a two-year project?
A full IAM deployment is expensive and long. But eighty percent of the risk is reduced with things that are not.
- Take inventory. Pull the list of all accounts in the main systems and cross-check it against the list of active staff. That cross-check, which takes days and not months, always produces surprises.
- Fix offboarding before onboarding. Write the procedure for what gets closed when someone leaves, with the full name of the person responsible and a deadline. It is the cheapest step and the one that closes the most.
- Separate administrative accounts. Nobody should administer systems with the same account they use to read email. It is free and cuts off an entire family of attacks at the root.
- Give automated identities an owner and an expiration date. Every service account and every API key with an owner and a review date. Boring and decisive.
- Monitor behavior. Because the best IAM in the world does not prevent someone from stealing a valid credential. What remains then is noticing that the identity is doing something it never does, and that requires someone to be watching.
Frequently asked questions
Are IAM and Zero Trust the same thing?
What is least privilege?
Do you need to buy an IAM tool?
How often should permissions be reviewed?
Does an artificial intelligence agent need its own identity?
The list nobody wants to open
Of everything written here, if only one thing can be done, make it the inventory. Pull the complete list of active accounts and cross-check it against the list of people who work at the company today.
It is a few days of work, it costs no money and there is nothing to buy. And the reason almost nobody does it is not technical: everyone has a hunch about what they are going to find.
