IAM mistakes startups make (and how to fix them)

Startups often begin with a single AWS (or Azure/GCP) account and one or two people using root or admin-equivalent access. That’s acceptable for a proof of concept; it becomes a liability as the team and surface area grow.

The first mistake is treating IAM as an afterthought. Early on, create separate IAM users or, better, use IdP federation so there are no long-lived passwords or keys in the cloud. Assign humans to groups (e.g. developers, admins) and grant permissions to groups, not individuals. When someone leaves, you remove them from the IdP; no need to hunt for keys or inline policies.

The second is overprivilege. Broad policies like s3:* or ec2:* on production resources are convenient but dangerous. Start with a small set of roles (e.g. read-only, deploy, admin) and attach policies that only include the actions those roles truly need. Use policy conditions (e.g. MFA, source IP) where it matters.

The third is mixing automation and human access. CI/CD and scripts should use dedicated roles (e.g. a deployment role) with scoped permissions, not a developer’s credentials. That way you get clear audit trails and can rotate or revoke automation credentials without affecting people.

The fourth is ignoring cross-account and cross-service access. As you add accounts (e.g. for prod vs. dev), define how roles are assumed across accounts and avoid sharing root or long-lived keys. Use OIDC or SAML for GitHub/Azure DevOps so pipelines assume roles without stored secrets.

Fixing this does not require a big-bang rewrite. Introduce an IdP and one or two roles, migrate one team or pipeline, then expand. We help teams design and implement this path so security improves without slowing delivery.