Identity-first foundations
A manager once asked me to use a stored local admin credential to create new user accounts on a piece of lab equipment. A separate time, the same request came in with a different purpose: use that shared credential to reset my own password. Both requests were well-intentioned. The person asking wasn't trying to create a security problem. They were trying to get something done.
That's exactly how shared credentials survive in environments that should know better. Not through negligence, through convenience. And the problem isn't what gets done. The problem is that when something goes wrong later, the logs will show that admin did it. That's all anyone will ever know.
Shared accounts don't remove responsibility. They remove traceability.
This is true at any layer. A shared local admin on a piece of equipment. A generic service account three teams use because it was easier than provisioning individual access. A vendor account that never got rotated after the project closed. The credential works. The access is real. But the person behind it is gone the moment they log out.
In a normal environment this is an annoyance. In a regulated one it's a compliance failure. In an incident it becomes the thing that makes a full investigation impossible. You can tell what happened. You cannot tell who made it happen. That gap is the cost of shared identity, and it compounds every time you let it slide.
Access logs tell you what happened. Identity tells you who did it. Without the second one, the first one is a partial record at best. A partial record under audit pressure is not a good place to be.
How identity gets complicated without anyone trying.
Most environments don't start out messy. They grow that way. Each addition makes sense in the moment. The problem is that nobody is tracking the sum of it.
In a domain environment you might have a standard user account, a separate admin account for elevated tasks, and then standalone local accounts on individual systems that predate the domain or never got folded in. Add specialized equipment that has its own access model. Add elevated roles for people who need both standard and privileged access depending on what they're doing, so they end up with two accounts: one for day to day work and a separate one scoped to the elevated role. Add vendors who configured things before you owned them and left their defaults behind.
None of those decisions were wrong on their own. Each one solved a real problem at the time. But the result is an environment where the same person might have four or five different credentials across different systems, where account ownership is murky, and where revoking access at offboarding means hoping you can find all of it. That's not an identity strategy. That's identity by accumulation.
Identity that grows without a plan eventually becomes identity nobody can fully account for.
Starting with who, not what.
The pattern I keep coming back to is asking ownership questions before anything else gets built. Not what does this service need, but who will use it, why will they use it, and how much access does that actually require. Those three questions change what you build and in what order you build it.
When I built out the mail server for my lab environment, I pre-created the accounts before the server was running. Not after, not as part of setup, before. Because the question of who gets a mailbox and under what identity should not be answered in the middle of a configuration session. It should be answered before the first service starts. The same logic applies to every application that comes after: does this need to be tied into centralized authentication, or does it stand alone? If it stands alone, why? What does that cost in terms of visibility and control later?
Those questions sound small. They save a significant amount of cleanup work later.
Naming as a forcing function.
A consistent naming scheme isn't just organization. It's a record of intent. When you can look at an account name and immediately know which domain it belongs to, what role it carries, and roughly what access level it implies, you've built something auditable almost for free. When you can't, every access review becomes a research project.
Across my lab domains I use consistent patterns, similar enough that the logic transfers but distinct enough that accounts from one domain can't be confused for another. Every domain has a standard user identity, an admin identity with a clear naming convention, and planned elevated or dev-scope accounts that follow the same pattern when they get built. The names are boring by design. Boring names that mean something are better than creative names that require explanation.
brad // standard identity
admbrad // elevated / admin
devbrad // dev scope, future
the-keep // business domain
brad_carson // standard identity
admbradcars // elevated / admin
bradcars // short form, planned
devbradcars // dev scope, future
Each account has a clear purpose before it exists. That's the point. You're not naming accounts to stay organized. You're naming them to enforce the decision about what they're for.
Why IAM comes before apps.
When identity is an afterthought, it becomes a retrofit. Every new service inherits whatever access model was convenient at the time it was stood up, and none of those models talk to each other. Access reviews are manual. Offboarding is incomplete by default. Incidents are harder to scope because you can't quickly answer who had access to what.
When identity is the foundation, everything built on top of it is cleaner. New services get their access model from the identity layer, not from their own local config. Onboarding is additive and controlled. Offboarding is a single action with downstream effects. Incidents start with a known access map, not an investigation into one.
Every audit, every incident, every access review is easier when identity was right from the start. Not a little easier. Structurally easier. Because the answers to "who has access" and "who did this" are already there.
The shared admin credential that got used to reset my password was a solvable problem in the moment. It always is. The question is what you're building toward. An environment where every action is attributable, every account has an owner, and access can be revoked cleanly doesn't happen by accident. It happens because someone asked the ownership questions first, before the first service started, and kept asking them every time something new came along.
Identity comes first because everything else depends on it. That's not a philosophy. It's just how the architecture actually works.