What Happened
Your security team discovered 200 AWS IAM roles across three accounts, many with permissions far beyond what's necessary. IAM Access Analyzer flagged roles with unused service permissions and actions not exercised in months. Some roles weren't assumed at all. This wasn't a breach, but permission sprawl. Roles created during rapid deployments kept broad permissions. Engineers who set up roles during incidents never revisited them. Roles defined in CloudFormation templates were manually adjusted, only to revert on the next deployment.
The team saw the problem. IAM Access Analyzer provided findings and recommended policies. What was missing was a sustainable remediation path. Manual fixes didn't last. Console changes vanished with infrastructure-as-code redeployments. The backlog grew faster than the team could manage.
Timeline
This wasn't a single incident. It's a gradual accumulation common in AWS environments:
Initial deployment phase: Development teams grant broad permissions to get applications running, intending to tighten them later.
Months 1-6: Roles accumulate. New services launch with generous policies. Engineers create roles manually during troubleshooting. Permissions go unchecked.
Month 6+: IAM Access Analyzer flags unused permissions. Some roles haven't been assumed in over six months. The security team starts manual remediation.
Ongoing: Manual fixes revert on the next deployment. Findings pile up faster than the team can address them. The gap between detection and remediation widens.
Which Controls Failed or Were Missing
AC-6 (Least Privilege): NIST SP 800-53 Rev 5 requires least privilege, allowing only necessary access. The environment violated this by maintaining overprivileged roles long after deployment needs changed.
CM-2 (Baseline Configuration): Without infrastructure-as-code enforcement, there was no authoritative baseline for IAM role configurations. Manual changes created drift between intended security and actual deployment.
CM-3 (Configuration Change Control): IAM role changes lacked proper change control. Console modifications bypassed code review. CloudFormation deployments overwrote manual security improvements without review or approval.
AC-2(7) (Role-Based Schemes): This control requires regular review and updates of privileged roles to reflect current needs. The organization detected issues through IAM Access Analyzer but lacked a systematic process to act on findings.
AU-6 (Audit Review, Analysis, and Reporting): Security monitoring identified unused permissions, but findings didn't trigger timely corrective action. The audit capability existed; the remediation workflow didn't.
What the Relevant Standards Require
NIST SP 800-171 Rev 2 control 3.1.5 mandates the principle of least privilege, including specific security functions and privileged accounts. For defense contractors under DFARS 252.204-7012, this is a contractual obligation for systems processing Controlled Unclassified Information.
NIST SP 800-53 Rev 5 goes further. AC-6(1) requires access authorization based on security functions. AC-6(7) mandates review and reevaluation of privileged role assignments. CM-2(2) requires automation support for maintaining baseline configurations.
Under CMMC 2.0, least privilege appears in multiple Level 2 practices. AC.L2-3.1.5 demands least privilege implementation. CM.L2-3.4.2 requires baseline configurations. If your organization holds a CMMC Level 2 assessment, assessors will look for evidence that you're actively managing IAM permissions, not just detecting issues.
For FedRAMP Moderate systems, AC-6 is a required control. Your System Security Plan must document how you enforce least privilege, and your continuous monitoring plan must show you're actively reviewing and remediating excessive permissions. IAM Access Analyzer findings that sit unaddressed for months signal a control gap.
Lessons and Action Items for Your Team
Treat IAM roles as code, not console resources. If it's not in your repository, it will drift. Migrate manually created roles into CloudFormation or AWS CDK. This isn't just a suggestion, it's how you make remediation permanent.
Build remediation into your CI/CD pipeline, not your security backlog. IAM Access Analyzer tells you what's wrong. Your pipeline should generate the fix. Use CloudTrail to identify which stack owns each role, retrieve the recommended policy from IAM Access Analyzer, and create a pull request with the updated code. Let your existing code review process evaluate the change.
Implement a three-tier remediation strategy. IaC-managed roles get automated pull requests with production-ready code updates. Manually created roles get issues with the recommended policy and migration guidance. Unused roles get a soft-disable workflow: attach a deny-all policy, monitor for 30 days to confirm nothing breaks, then delete. Don't force immediate deletion, seasonal workloads exist.
Use Amazon Bedrock to bridge the gap between security findings and developer understanding. A recommended policy is useful. A plain-English explanation of what permissions are being removed and why makes the pull request actionable. Generate both.
Set exclusion filters carefully. Your break-glass roles need broad permissions. Service-linked roles are managed by AWS. Tag critical roles that legitimately require elevated access and exclude them from automated remediation. But keep the exclusion list short, every exception is a potential gap.
Deploy organization-wide if you operate multiple accounts. An ORGANIZATION_UNUSED_ACCESS analyzer in your delegated administrator account generates findings across all member accounts from a single vantage point. Your Lambda function can extract the account ID from each finding's ARN and route remediation appropriately.
Track remediation velocity as a metric. Publish CloudWatch metrics for findings processed, pull requests created, and issues opened. If your backlog grows faster than your remediation rate, you need more automation, not more security engineers.
The technical pattern matters less than the operational principle: convert findings into deployable code changes, not security tickets. Your developers already know how to review pull requests. They don't want another dashboard to check.
