The firewall moved. Your IAM policies are the outer wall. Most teams still treat them like internal plumbing.
Network controls still matter. They do not decide who can assume a role, mint a temporary credential, or approve a production change from a laptop in a cafe. When we reconstruct cloud incidents, the story almost always starts with a human or workload identity that had more reach than anyone remembered.
This note is for cloud and security leads who already "have MFA" and still keep finding standing admin access in forgotten accounts.
Why identity is the perimeter
In a VPC-centric world, compromise meant getting past the edge and then moving laterally. In a cloud-native world:
- APIs are the edge
- Temporary credentials are the session
- Role assumption is the privilege escalation path
- Federation and CI identities are often more powerful than any employee laptop
A stolen session token with the right role beats a perfect security group. Attackers know this. Phishing kits, OAuth consent phishing, and CI secret leaks are optimized for identity, not for port scans.
If your detection stack is still tuned for unusual inbound ports and not for unusual AssumeRole, GetFederationToken, or service-principal sign-ins, you are watching the wrong door.
Failure modes we keep seeing
### 1. Standing privilege that outlived the project
Roles created for a migration, a vendor PoC, or a "temporary" break-glass path that never got a deletion date. Six months later they are still attached to a human or to a long-lived access key.
Ask: what is the maximum blast radius of every identity that can touch production data or change IAM itself? If you cannot answer without opening five consoles, you do not have an inventory. You have hope.
### 2. Workload identities treated as second-class
Service accounts, instance profiles, GitHub OIDC roles, and Kubernetes service accounts often hold broader permissions than any named engineer. They also get weaker review: no MFA story, long-lived keys in CI variables, trust policies that accept any repo in an org.
The identity that deploys is frequently the identity that can also read secrets, modify IAM, or reach the data plane. That is not "automation." That is an unattended admin.
### 3. Session and MFA theatre
MFA on the IdP login, then eight-hour console sessions, shared break-glass passwords in a chat channel, and API keys that never expire. The checkbox was green. The session was still a standing credential.
Privileged roles need short sessions, step-up authentication for sensitive actions, and alerting when those roles are used outside expected paths.
### 4. Policy sprawl without version control
Inline policies edited in the console. Duplicate managed policies with slightly different names. "Temporary" wildcards (Action: , Resource: ) left in place after an incident response weekend.
Without a single source of truth in git (or equivalent) and a review path for IAM changes, drift is the steady state.
A hardening checklist that survives contact with production
Use this as a review boundary, not as a slogan list:
- Inventory — every human, service principal, role, and federated trust that can reach production. Name an owner. Delete what has no owner.
- MFA and phishing-resistant auth — for humans. For workloads, prefer short-lived federation (OIDC) over static keys. Kill long-lived access keys wherever the platform allows.
- Session bounds — privileged roles: short max session duration. No all-day admin cookies.
- Least privilege with review — managed policies in version control. No inline production policies. Wildcards require a ticket and an expiry.
- Separation of duties — the identity that deploys application code should not also be the identity that can rewrite IAM or empty audit logs.
- Stale access detection — quarterly reviews are theatre unless automated signals flag unused roles, unused keys, and unused grants continuously.
- Break-glass — two accounts, monitored, alerted on every use, never used for day-to-day work. Test them on a schedule so they work when you need them.
- Detect identity abuse — alert on unusual role assumption, impossible travel on IdP, new root/global-admin use, and mass permission changes.
AWS, Azure, and GCP differ in vocabulary. The failure modes do not. Translate the list into IAM roles, Entra ID roles / managed identities, and GCP IAM / workload identity federation. Do not invent a third framework that only your GRC tool understands.
What "good" looks like in a review
When we walk an IAM perimeter, we expect to leave with:
- A map of who can change who
- Evidence that privileged paths are short-lived and observed
- A clear story for CI and runtime identities, not only employees
- Proof that unused access is removed, not just documented
If the only artifact is a policy PDF, the perimeter is still soft.
Closing note
Network diagrams feel like security. Identity graphs decide outcomes.
Teams that treat IAM as the perimeter (inventoried, short-lived, reviewed, and detected) cut off the path most cloud breaches still take. Teams that treat IAM as plumbing keep rediscovering the same incident with a different ticket number.
AN3 Intel · field notes on cloud identity risk.