The shape of identity in a business
Identity is the control plane for who and what can do what. The trick to keeping it sane: nest accounts into groups and roles, and never pin a permission on a user.
The difference between “add this person to the group” and “hunt down every permission they ever touched” is usually a Friday afternoon. Get the structure right now. Identity management is the unglamorous infrastructure work that pays off when you need to answer a plain question: who or what is allowed to do a thing, where, and under which conditions. Every entity that touches IT is an identity—staff, contractors, guests, service accounts, bots, AI agents, devices, workloads. Get the nesting right, and joiner/mover/leaver, access reviews, and least privilege fall out naturally. Get it wrong, and you’re hand-patching permissions one ACL at a time for the next three years.
(If you haven’t seen the frame yet: identities are one of five pillars that structure modern IT infrastructure. This post digs into how to shape the identity pillar itself.)
Everything is an identity
Start with the basics: an identity is anything that authenticates and gets authorized. That includes people, but it also includes service accounts, bots, AI agents, devices, and workloads running in containers. Each identity has an owner, a purpose, and a lifecycle. They start as a request, get provisioned, go active, maybe get elevated for a task, then suspend and deprovision when they’re done.
The structural rule that matters: every automation should have its own service identity instead of borrowing a human’s account. That stopped being optional years ago—in most estates now, the non-human identities already outnumber the humans.
Don’t pin permissions on people, nest them
Here’s the structural rule that keeps access manageable at any size: you never grant User A a permission directly. You nest. It’s the classic AGDLP chain, Account → Global group → Domain local group → Permission, and it still maps cleanly onto a modern IdP.
User A is an account. It’s a member of a global group (Team A1), which nests into a department, which nests into a business unit. The permission lives on none of those. It lives on a domain local group that represents access to exactly one resource. Membership flows down the nest, rights attach at the far end, and the two only ever meet in the middle.
Roles are the unit you actually design with
Groups model who you are; roles model what you may do. A role is one or more access rights bundled into something with a name a human recognises, “PLC integrator”, “Backup operator”, “Read-only auditor”. Roles nest the same way groups do: a parent role can contain child roles, an identity can hold several at once, and a role respects the same tiering as the accounts in it (a role only ever contains identities from one tier). Design access as roles → rights, and you stop hand-wiring individual users to individual permissions one checkbox at a time.
The tiering is not decoration. Base identities do daily work; tier 0 is domain-admin territory; and the two never mix, so a compromised mailbox can’t reach the control plane. Roles inherit that discipline instead of quietly bridging across it.
Golden rule: nest membership, attach permissions once. The day you find yourself editing a user to grant access, you’ve already lost the thread.
Why bother
The payoff is boring, and that’s exactly the point. Joiner/mover/leaver collapses into “change group membership,” not “hunt down every resource this person could possibly touch.” Access reviews read off roles instead of raw ACLs, so you can actually answer “who had what, when, and who approved it.” Least privilege and tiering fall out of the structure instead of being policed by hand. And the tooling underneath is allowed to change, AD today, Entra or Authentik tomorrow, because the shape doesn’t: accounts into groups, groups into roles, permissions attached exactly once, at the far end of the nest.