AWS access control & privilege security checks
Admin roles, standing privileges, permission scopes and policy enforcement — the settings that decide how much damage one compromised account can do.
On AWS, Black Cat runs 11 checks in this area on every scan. Each one below lists its severity, how to fix it, and the compliance controls it satisfies where a control applies. See what access the AWS connector needs.
Checks (11)
severity: critical Root Access Key Exists fix difficulty: easy #
Delete all access keys associated with the AWS root account
- Sign in to the AWS Management Console as the root user
- Navigate to IAM > Security credentials (top-right account menu)
- Under "Access keys", locate any existing root access keys
- Click "Delete" for each access key listed
- Confirm deletion in the dialog
- If automation requires programmatic access, create an IAM user with least-privilege permissions instead
Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.c NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2
severity: medium Unused Access Keys fix difficulty: easy #
Deactivate or delete IAM access keys that have not been used recently
- Navigate to IAM > Users in the AWS Console
- Click the user name to open the user detail page
- Select the "Security credentials" tab
- Under "Access keys", review the "Last used" column for each key
- For keys unused for 90+ days, click "Deactivate" or "Delete"
- Confirm the change and notify the user if necessary
Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.c NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2
severity: medium Old Access Keys Not Rotated fix difficulty: medium #
Rotate IAM access keys older than 90 days
- Navigate to IAM > Users in the AWS Console
- Click the user name, then select the "Security credentials" tab
- Under "Access keys", note the "Created" date for each key
- Click "Create access key" to generate a new key for the user
- Update the application or script that uses the old key with the new credentials
- Once the new key is confirmed working, click "Deactivate" then "Delete" on the old key
Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-32.1a HIPAA (SaaS Security) HIPAA-312.c NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2
severity: medium Inactive IAM Users fix difficulty: medium #
Deactivate or remove IAM users who have been inactive for 90+ days
- Navigate to IAM > Users in the AWS Console
- Review the "Last activity" column to identify inactive users
- Click the user name, then select the "Security credentials" tab
- Deactivate all access keys by clicking "Deactivate" for each
- If the user account is no longer needed, navigate back and click "Delete user"
- Confirm the deletion and update any resource policies referencing the user
Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-308.a3 NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2
severity: medium Password Never Used fix difficulty: easy #
Deactivate the console login profile for IAM users who have never signed in
- Navigate to IAM > Users in the AWS Console
- Open the flagged user and select the "Security credentials" tab
- Click "Manage" next to "Console sign-in" and remove the password
- Confirm with the owning team that no automation depends on the user
- If the user is no longer required, delete it entirely
Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2
severity: critical Overly Permissive IAM Policy fix difficulty: hard #
Replace wildcard IAM policy permissions with specific actions and resource ARNs
- Navigate to IAM > Policies in the AWS Console
- Locate the policy flagged and click its name to open it
- Click "Edit policy" and switch to the JSON tab
- Replace any "Action" wildcards (e.g. "*" or "service:*") with the specific actions required
- Replace any "Resource" wildcards ("*") with the specific resource ARNs needed
- Use IAM Access Analyzer to generate a least-privilege policy based on actual usage if available
- Click "Review policy", then "Save changes"
Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-308.a4 NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2
severity: high Weak Password Policy fix difficulty: easy #
Strengthen the IAM account password policy to meet security best practices
- Navigate to IAM > Account settings in the AWS Console
- Click "Edit" next to the password policy
- Set minimum password length to at least 14 characters
- Require at least one uppercase letter, one lowercase letter, one number, and one non-alphanumeric character
- Enable "Prevent password reuse" and set history to at least 24 passwords
- Set maximum password age to 90 days or fewer
- Click "Save changes"
Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-32.1b.i HIPAA (SaaS Security) HIPAA-312.d NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2
severity: medium Password Policy Expiration Too Long fix difficulty: easy #
Reduce maximum password age to 90 days or fewer
- Navigate to IAM > Account settings in the AWS Console
- Click "Edit" next to the password policy
- Set "Maximum password age" to 90 or a smaller number of days
- Click "Save changes"
Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2
severity: high SCP Not Attached to Root fix difficulty: easy #
Attach at least one SCP to the organizational root to enforce root-level guardrails
- Navigate to AWS Organizations > Policies > Service control policies
- Select the SCP that should define organization-wide guardrails
- Click "Attach" and choose the organizational root
- Verify the Organization root has at least one SCP attached
Satisfies: NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2
severity: medium SCP Allows All Actions fix difficulty: hard #
Replace the wildcard Allow SCP with restrictive deny-based guardrails
- Navigate to AWS Organizations > Policies > Service control policies
- Select the flagged SCP and click "Edit"
- Remove the "Allow *" statement (default FullAWSAccess)
- Replace with explicit Deny statements for risky actions
- Test in a sandbox OU before applying to production
Satisfies: NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2
severity: medium SCP Overly Broad Deny Exception fix difficulty: hard #
Narrow the NotAction exception list in the SCP Deny statement
- Navigate to AWS Organizations > Policies > Service control policies
- Select the flagged SCP and click "Edit"
- Review the Deny statement's NotAction list
- Remove wildcards and reduce to specific required actions
- Test with Access Analyzer before deploying
Satisfies: NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2