IAM.

Where IAM fits on a long engagement.

Least privilege is easy to state and hard to sustain. Permissions are granted under time pressure, broadened when something does not work, and almost never narrowed afterwards. Most estates accumulate permissions monotonically, and an audit two years in finds roles that can do considerably more than anyone intended.

The practical path is starting narrow and widening from evidence. Access analysers and usage data show which granted permissions were actually used, which turns "what does this role need" from a guess into a measurement — and makes removing the rest defensible rather than risky.

What an assigned team does with IAM.

Human access and workload access need different treatment. People should authenticate through an identity provider with short-lived credentials; workloads should use instance or service-account identity rather than static keys. Long-lived access keys are the most common serious finding on any cloud audit.

Eliminating them is straightforward work with a large security return, assigned under devops managed services.

What we use IAM for.

• Permissions narrowed from evidence Access analyser data used to remove what was granted but never used.
• Static keys eliminated Workload identity replacing long-lived credentials, which is the standard audit finding.
• Human access through an identity provider Short-lived credentials via federation, so offboarding is immediate and complete.

How IAM capacity is assigned.

IAM work starts from an audit of what is currently granted rather than from a proposed model. What that audit covers is described in how an assignment runs.