The Cloud Security Risks Hiding in Plain Sight

A developer gets temporary permissions to fix an issue. A service account outlives the project it was built for. An access key goes 90 days without rotation. A role gets an "allow all" grant because something needed to work right now.

Individually, these decisions may be reasonable. The risk comes when temporary access becomes permanent.

That is how Identity and Access Management (IAM) drift develops: access gradually moves away from what your organization intended. As infrastructure changes and exceptions accumulate, the attack surface grows with it.

Watch for Risks That Quietly Accumulate

IAM drift often shows up during an audit, an incident, or an investigation into access that should have been removed months earlier.

Four areas deserve consistent attention:

• Compromised credentials. Users without multi-factor authentication (MFA) create an avoidable path into critical systems. MFA coverage is straightforward to detect and report on, making it a good place to start.
• Forgotten attack paths. Dormant identities, unused roles, and aging access keys can survive long after their original purpose disappears. If an employee leaves and a new hire is later assigned the same email address, poor account cleanup can result in inherited permissions. Access keys older than 90 days are also a useful trigger for review.
• Excessive blast radius. Broad permissions often begin as a shortcut. An "allow all" policy gets someone through a deadline, then sticks around. The broader the permission, the more damage a compromised identity can cause.
• Compliance decay. A CIS benchmark may define a specific configuration check while a NIST control describes the broader security outcome behind it. Passing the check once only proves the environment was compliant at that moment. The better question is whether your team will know when the control stops being true.

Point-in-time reviews only show what was true when they ran.

Cloud environments keep changing. People move between teams, applications are retired, infrastructure is rebuilt, and permissions are added for immediate needs.

That gap creates both security and operational risk.

Build Toward Continuous Security

Automating every remediation on day one tends to cause more problems than it solves. False positives create disruption. Too many alerts create noise. Poorly tuned policies can break legitimate workflows.

A better approach is to move through five stages: detect, notify, tune, remediate, automate.

Start by detecting the issue and confirming the signal is accurate. Notify the right people and tune the policy based on what you learn. Once the team trusts the results, move into remediation and, where it makes sense, automation.

Treat IAM Drift as an Engineering Problem

Security can define the policy, but engineering is where those controls live.

Permissions are part of deployment pipelines, service accounts, infrastructure code, and application architecture.

Catching drift early and fixing it quickly matters more than passing any single audit.

Watch the Full Talk

In the full talk from AWS Community Day Midwest 2026, I walk through how to apply this model using Cloud Custodian, an open source Policy as Code tool, with practical IAM examples across AWS, Azure, and GCP.

If you’re seeing IAM drift in your environment, start with detection. Six Feet Up can help you use Policy as Code to find issues, tune the controls, and automate remediation once you trust the results. Contact us.