Identity is the new perimeter: eight IAM mistakes that quietly cause breaches

For decades, security was drawn as a castle: a strong wall (the firewall) around a trusted interior. Cloud services, remote work, and SaaS dissolved the wall. Your data now lives in dozens of places that your network perimeter doesn't cover, and the thing that decides who gets in is no longer a network location — it's an identity.

That's why identity and access management, or IAM, sits at the center of modern security. And it's why the same handful of IAM mistakes show up in incident after incident. None are exotic. All are fixable.

Mistake 1: MFA missing, or the weak kind

Passwords get phished, reused, and leaked. Without multi-factor authentication, a single stolen password is a full compromise. Even with MFA, not all factors are equal: SMS codes and push approvals can be intercepted or abused through fatigue attacks, while phishing-resistant options like FIDO2 security keys and passkeys are much harder to trick.

Fix: Require MFA for everyone, starting with administrators, remote access, and email. Move privileged users to phishing-resistant methods.

Mistake 2: Permissions that are far too broad

The path of least resistance when something "doesn't work" is to grant broader access. Over months, that produces wildcard policies and accounts that can do far more than their job requires.

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

Fix: Start from least privilege — grant only what's needed, scoped to specific resources. Use your cloud provider's access analysis tools to see which permissions are actually used and trim the rest.

Mistake 3: Long-lived static credentials

Access keys that never expire are the gift that keeps giving to attackers. They get committed to repositories, pasted into chat, baked into images, and forgotten on laptops.

# Find access keys and when they were last used
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d

Fix: Prefer short-lived credentials from roles and federation over static keys. For CI/CD, use OIDC federation rather than stored secrets — we walk through this in securing GitHub Actions: secrets, OIDC, and least privilege. Where keys must exist, rotate them and alert on age.

Mistake 4: Shared accounts and everyday use of root

When five people share one login, nobody is accountable and offboarding becomes impossible. The all-powerful root or global administrator account is the extreme case, because it can do everything and bypass most guardrails.

Fix: Individual identities for every human. Lock the root account away with strong MFA, use it only for the few tasks that require it, and do daily work through limited roles.

Mistake 5: Stale accounts and missing offboarding

Contractors finish, people change teams, projects end — and their access lingers. Dormant accounts are attractive targets because nobody's watching them.

Fix: Tie access to your HR joiner-mover-leaver process. Run regular access reviews, and disable or remove accounts that haven't been used for a defined period. We cover the habit in zero trust isn't a product, it's a habit.

Mistake 6: Ignoring non-human identities

Service accounts, API tokens, and automation credentials often outnumber human users many times over, and they typically have broad, permanent access and no owner. Nobody gets an alert when a service account behaves strangely.

Fix: Inventory them, assign an owner to each, scope them narrowly, and rotate their secrets. Treat machine identities with the same rigor as people.

Mistake 7: No separation of privileged access

If the account used to read email is the same one that can administer your cloud, a single phishing click is catastrophic.

Fix: Separate daily-use accounts from administrative ones. Use just-in-time elevation so privileges are granted briefly, for a reason, and recorded — rather than held permanently.

Mistake 8: Not watching identity events

Attackers who steal credentials often act quietly. Without logging and alerting, impossible-travel sign-ins, new MFA devices, privilege escalations, and unusual API activity go unnoticed.

Fix: Turn on and centralize identity and audit logs, and alert on high-signal events: administrator role assignments, sign-ins from unusual locations, disabled MFA, and creation of new keys.

A one-week starting plan

Identity is a skill, not a switch

IAM looks simple on a diagram and gets intricate in practice: policy evaluation, federation, roles across accounts, conditional access. Getting it right takes understanding, not just tooling. Our Identity and Access Management Fundamentals course teaches these concepts hands-on, and the Zero Trust Architecture Workshop shows how identity fits into a broader design. For cloud-specific hardening, see Cloud Security on AWS and Cloud Security on Azure.