In a modern environment, network location says less about trust than identity does. A workload assumes a role, a deployment pipeline presents a token, an operator elevates for a task, and a service calls another service. These are infrastructure events even when no server is provisioned.
Treating identity as a collection of account settings misses the system that those events create.
Model relationships, not just accounts
An inventory can tell you that an identity exists. A relationship model tells you what it can become. Which groups grant roles? Which roles can assume other roles? Which service account can read a secret that unlocks a different environment? Which workflow can modify the code that receives production credentials?
That graph matters to defenders and attackers for the same reason: effective privilege is often the product of a chain, not a single permission.
Least privilege is not a property of one policy. It is a property of the complete path from identity to consequence.
Give workload identity first-class treatment
Human access usually receives the clearer lifecycle: join, change roles, leave. Workload identities tend to accumulate quietly. They outlive applications, inherit broad permissions, and rely on credentials nobody wants to rotate.
Prefer short-lived, context-bound credentials. Give each workload an owner and purpose. Keep trust policies narrow enough that a compromised pipeline, namespace, or repository cannot impersonate unrelated services. Then monitor actual use so unused privilege becomes visible.
Design privilege to decay
Permanent administrative access turns yesterday’s requirement into today’s attack surface. Time-bound elevation, approval context, and automatic expiration make privilege reflect a task instead of a job title.
Emergency access should follow the same principle. Break-glass identities need strong authentication, tightly controlled credentials, immediate alerting, and routine testing. An emergency path is part of the production system; if it is never exercised, it is only a theory.
Operate identity like a platform
Identity configuration should be versioned where possible, reviewed like code, tested for dangerous combinations, and observed at runtime. Ownership, change history, rollback, and service-level expectations all apply.
When identity is engineered as infrastructure, access becomes easier to reason about and harder to accumulate silently. That clarity improves security, but it also makes delivery and incident response faster—which is what good infrastructure tends to do.