Least privilege service identities
Put a service role's purpose next to its owner
Identities outlive deployments unless someone owns their lifecycle. Keep the permission rationale and recovery procedure available to the team operating the workload.
In this article
Maintain an identity record
Record the workload, owner, environment, trust mechanism and policy location. Link the normal and recovery operations that justify its access.
Include any long-lived credential exception and its management procedure without storing the secret value in the documentation. The record should explain where authority comes from, not expose it.
Use naming that distinguishes runtime, deployment and administrative identities. Similar names with different authority create avoidable confusion during incidents.
Preserve the permission evidence
Keep the allowed and denied test cases with the relevant policy version. Include uncommon schedules and recovery operations that a new maintainer might otherwise remove as unused.
Document the limits of activity-based analysis. A quiet observation period is evidence about that period, not proof that every unobserved permission is unnecessary.
Record why broader scopes remain where provider semantics require them and what other restrictions apply.
Rehearse a denial investigation
Give the incoming team a synthetic failure involving the wrong output resource. They should identify the actual principal, requested action and effective policy context before proposing a change.
Verify that they can distinguish an application targeting error from a legitimate missing permission. The default response should not be attaching an administrator policy.
Document the approved emergency access path and how temporary grants are removed after recovery.
Retire access with the workload
Include identity review in service decommissioning, account changes and ownership transfers. Remove unused roles, trust relationships and resource grants through the supported process.
Confirm that deployment automation no longer recreates retired access. Deleting a role manually while leaving its infrastructure definition active produces confusing drift rather than a lasting retirement.
A useful handover lets another operator explain every important permission and find the person authorised to change it. That makes future maintenance safer and faster than relying on a role whose only history is that it once fixed an outage.
Primary sources
AWS: IAM security best practicesReferences checked 11 September 2026.