Identity and Access Management is the part of security responsible for answering one question: should this principal be allowed to perform this action on this resource?
That sounds simple. It isn't.
The core model
Every IAM system is built around three things:
- Principal — who (or what) is asking. A person, a service account, a machine, a third-party application acting on someone's behalf.
- Action — what they want to do. Read, write, delete, invoke, approve, escalate.
- Resource — what they want to do it to. A file, a database row, an API endpoint, a cloud function, a secret.
The challenge isn't defining the model. It's maintaining accurate answers to the question at scale — across thousands of principals, millions of resources, and a system that's constantly changing as people join, leave, and move roles.
The three failure modes
Most real-world IAM incidents trace back to one of three problems:
1. Identity is wrong. The system believes it knows who is making a request, but it's mistaken. Credentials were stolen or phished. A token was forged or replayed. A session was hijacked. The identity layer is compromised.
2. Permissions are wrong. The identity is correctly established, but it has access it shouldn't. Accounts accumulate permissions over time. Roles get assigned for one-off tasks and never revoked. Blast radius grows invisibly until something goes wrong.
3. Enforcement is incomplete. The policy says access should be denied, but some code path doesn't check. A legacy API trusts its callers implicitly. A service-to-service call bypasses the access control layer entirely. The policy exists on paper; it doesn't exist in practice.
Fix all three and you have a defensible IAM posture. Leave any one of them unaddressed and you have a policy document that doesn't match reality.
Zero Trust
This specific pillar took me the longest to wrap my head around. How does one adapt this to active directory permissions when certain integrations require you to use groups and how do you address these things safely.
Zero Trust is the architecture pattern that takes these failure modes seriously. The core premise: don't trust a request just because it originated inside the network perimeter. Verify every request, every time, from every principal.
The shift in thinking is from "inside is trusted, outside is untrusted" to "nothing is trusted until verified." A compromised internal service doesn't automatically get access to the rest of your infrastructure. Lateral movement becomes harder because there's no implicit trust to exploit.
Zero Trust is harder to build than perimeter-based security. The verification overhead is real. But the threat model it defends against — an attacker who has already breached the perimeter — is the relevant one.
Building flows and processes to get admin rights in a timely manner that is ephemeral and not static is both the best and hardesst thing to accomplish properly.
What good actually looks like
- Least privilege — every principal gets exactly the permissions they need to do their job, and nothing more. Regularly reviewed and pruned.
- Just-in-time access — elevated permissions are granted on-demand for a specific task and automatically revoked when the session ends.
- Continuous verification — access decisions are re-evaluated at each request, not just at login time. Revocation is immediate.
- Complete audit trail — every access decision is logged with enough context to reconstruct what happened. Alerts on anomalies.
IAM is infrastructure. It's not exciting to build, it's not visible when it works, and it becomes the most important thing you have the moment something goes wrong.
I'll keep writing about specific patterns and tools in this space. There's a lot of ground to cover.
The core issue no one like to think about
The thing that everyone will deal with, unless you are extremely lucky to be with a brand new company with zero architecture in place, is tech debt. Skeletons in your environment. Years or decades of old accounts, policies, group nesting nightmares, etc. I know I've dealt with this repeatedly in my time in the Identity space. "We have a list of groups to add to the Held Desk users to grant them access to AD (or insert system here) and can you tell me which group actually gives them access to do xyz?"
The answer is always yes, but its with an added caveat of "It might take me a while to figure out".