Cloud IAM and least privilege for audits

Auditors test cloud access three ways: who can reach production today, how a new person got access, and how a departing one lost it. Federated identity answers all three with one system.

Last reviewed 2026-09-30Written by Jacob Masse, TrazTech Inc.

Cloud IAM that passes an audit has four properties. People sign in through one identity provider with MFA, never with cloud-native users or long-lived keys. Roles map to job functions, not individuals. Standing administrator access is rare and logged. And someone reviews the list every quarter and signs it. Everything else is detail on those four.

Why federate cloud access to one identity provider?

Federation means people exist only in your identity provider, such as Okta, Microsoft Entra ID or Google Workspace, and the cloud trusts it. Removing someone there removes their cloud access at the same moment. That turns offboarding, the most commonly failed access control, into a single step with a single record. It also puts MFA enforcement in one policy instead of one per account.

Designing roles an auditor will accept

Least privilege does not mean every engineer gets a bespoke policy. It means access follows a small set of roles that each match a job, and nobody holds a role they do not need. A workable set for a 20 to 100 person SaaS company:

• Read-only production. Most engineers. Enough to debug, not enough to change.
• Production operator. On-call and platform engineers. Scoped write access to the services they operate.
• Administrator. Two or three people, activated when needed rather than held permanently.
• Break glass. Emergency access, stored offline, alerting on every use.
• Non-production write. Everyone who ships code, confined to development and staging accounts or subscriptions.

Production changes should come from the deployment pipeline's identity, not from people. That single decision makes both CC6 and CC8 of SOC 2 simpler, because human write access to production becomes the exception you log.

Privileged access

Standing administrator access is the finding auditors raise most often after missing MFA. The fix is just-in-time elevation: an engineer requests a role for a period, often with an approval or a ticket number, and the activation is logged.

AWS

Temporary elevated access with IAM Identity Center, or a separate admin permission set that only a small group can assume, with CloudTrail alerts on its use.

Azure

Privileged Identity Management with eligible assignments, activation justification and optional approval.

Google Cloud

Privileged Access Manager for time-bound grants, or IAM conditions with expiry on role bindings.

Service and workload identities

Machines need access too, and their credentials are where secrets leak. Prefer identities the platform manages and rotates: IAM roles for EC2, ECS and Lambda; managed identities on Azure; attached service accounts on Google Cloud. For CI/CD, use OIDC federation from GitHub Actions or GitLab to the cloud instead of stored keys. Keep an inventory of any static key that remains, with an owner and a rotation date. Secrets management covers the rest.

The access review

This is the control auditors sample every time. Each quarter, export who has which role in every production account, subscription or project, have the owner of each system confirm or revoke each line, record the date and the reviewer, and keep proof that revocations happened.

1. Export assignments from the cloud and from the identity provider groups that grant them.
2. Send each system owner their list. Ask for keep or remove on every line.
3. Remove what was flagged within a stated number of days.
4. Save the export, the decisions, the reviewer name, the date and the removal evidence together.

Microsoft Entra ID access reviews do this natively. On AWS and Google Cloud, a spreadsheet signed off by email or ticket is acceptable evidence, and it is what most first audits use.

Evidence summary