Nobody touches IAM findings, because nobody wants to cause the outage

The detection-remediation gap in IAM

Identity and Access Management (IAM) misconfigurations represent the most persistent category of cloud risk. While Cloud Native Application Protection Platforms (CNAPPs) have become proficient at identifying overprivileged roles by comparing granted permissions against historically used actions, the path from detection to least privilege remains blocked by operational risk. The primary deterrent is the fear of a production outage.

A developer may attach a managed policy like AdministratorAccess or PowerUserAccess to an EC2 instance or Lambda function to ensure the application works during initial deployment. Over time, that role becomes a permanent fixture. According to the 2024 Unit 42 Cloud Threat Report, 93% of cloud environments have identities with excessive permissions, yet the median time to resolve these findings often exceeds four months. The delay is not a lack of awareness. It is the difficulty of verifying that a specific permission, unused for 60 days, will not be required by a quarterly batch job or an edge case error handler tonight at 2am.

The limits of automated rightsizing

Most security tools propose a solution based on automated rightsizing. These tools analyze CloudTrail or equivalent logs, identify the delta between the policy and actual usage, and generate a new, narrower JSON policy. On paper, this solves the problem. In practice, the cloud security engineer is hesitant to apply the change.

Automated policy generation lacks context. A tool cannot know if a role requires s3:DeleteObject only during an end-of-quarter cleanup script that has not run since the last log rotation. If the automated fix removes that permission, the script fails, the database fills up, and the security team is blamed for the resulting downtime. This risk creates a psychological barrier that leads to backlog accumulation. Engineers choose the known risk of an overprivileged role over the immediate risk of a self-inflicted outage.

The infrastructure as code bottleneck

Remediation is further complicated by the way modern infrastructure is deployed. Changes made directly in the cloud console are overwritten during the next CI/CD deployment. To fix an IAM role permanently, the security team must find the specific Terraform, CloudFormation, or Pulumi code responsible for that role, submit a pull request (PR), and wait for the application owner to approve it.

This process introduces friction. Security teams often lack the permissions to commit to application repositories, and developers prioritize feature delivery over IAM hygiene. Without a mechanism to bridge the gap between a security finding and a merged PR, the finding remains open in the CNAPP dashboard, contributing to alert fatigue and audit failure.

A supervised approach to identity cleanup

Closing the IAM gap requires a shift from simple detection to human-supervised remediation. This is where Tamnoon operates. Rather than providing a list of JSON snippets for the customer to figure out, the Tamnoon model focuses on the entire lifecycle of the finding. This involves analyzing the usage data, validating the proposed change against the application's operational requirements, and working within the customer's existing change management and CI/CD workflows.

The goal is to reduce the blast radius of an identity without breaking the application logic. This requires an understanding of how the identity interacts with other cloud resources. For example, reducing a role's permissions on a specific S3 bucket requires verifying that no downstream service relies on that role for cross-account access.

Moving beyond the backlog

The failure of the last decade of cloud security has been the assumption that more visibility leads to more security. We now have more visibility than most teams can process. The bottleneck is the capacity to execute changes safely.

For IAM remediation to scale, it must move away from the "alert and ignore" cycle. Effective remediation requires:

1. Analysis of historical usage that accounts for long-tail events and infrequent tasks.
2. Integration with Infrastructure as Code (IaC) to ensure fixes are not ephemeral.
3. A verification step that allows for a "dry run" or staged rollout of new policies.
4. Professional oversight to handle the exceptions that automated logic misses.

By treating remediation as a service that owns the outcome rather than just the suggestion, organizations can finally begin to shrink their identity risk surface. The metric of success should not be how many overprivileged roles were found, but how many were safely moved to least privilege without an incident report being filed the next morning.

The operational reality of least privilege

Achieving least privilege is not a one-time project. As applications evolve, their identity requirements shift. A role that was correctly scoped six months ago may now be overprivileged if a specific microservice was decommissioned.

Managing this churn requires a dedicated remediation function. Relying on developers to perform their own IAM cleanup has proven ineffective in high-velocity environments. By utilizing a supervised remediation partner, security teams can offload the manual labor of policy investigation and PR generation, allowing them to focus on high-level architecture and threat modeling. This approach addresses the root cause of the cloud security backlog: the lack of time and specialized expertise to fix what is already known to be broken.