The Fix Library: how every AWS finding gets fixed

1. Open S3, the bucket, Permissions tab.
2. Under Block public access (bucket settings), choose Edit, tick Block all public access, save and confirm.
3. Review the bucket policy and ACL for public grants and remove them; for a genuinely public website, serve it through CloudFront with an origin access control instead.
4. Turn on the account-level Block Public Access setting (S3, Block Public Access settings for this account).

aws s3api put-public-access-block --bucket <bucket-name> --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
aws s3control put-public-access-block --account-id <account-id> --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Rollback: Set the four Block Public Access flags back to their previous values (recorded in the fix history) with put-public-access-block.

1. Open S3, the bucket, Properties tab.
2. Under Default encryption, choose Edit, pick SSE-S3 (or SSE-KMS with your key), save.
3. Existing objects are not re-encrypted; use S3 Batch Operations (Copy) if they must be.

aws s3api put-bucket-encryption --bucket <bucket-name> --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'

Rollback: Default encryption is normally left on. If it must be removed: aws s3api delete-bucket-encryption --bucket <bucket-name>. Objects already written stay encrypted.

1. Confirm how the application connects (it must be inside the VPC, over VPN or a bastion, not from the internet).
2. Open RDS, the database, Modify, Connectivity, Additional configuration, choose Not publicly accessible, continue and Apply immediately.
3. Review the database security group so it only allows the application subnets or security group.

aws rds modify-db-instance --db-instance-identifier <db-id> --no-publicly-accessible --apply-immediately

Rollback: aws rds modify-db-instance --db-instance-identifier <db-id> --publicly-accessible --apply-immediately (the instance must be in public subnets).

1. Open CloudTrail, Trails, the trail.
2. Choose Start logging (top right). If logging keeps stopping, check the S3 bucket policy and KMS key the trail writes with.

aws cloudtrail start-logging --name <trail-arn-or-name>
aws cloudtrail get-trail-status --name <trail-arn-or-name>

Rollback: Nothing to undo: turning a protection on is the intended state. If it must be turned off again, do it through your change process and TrustProof will report it as a finding.

1. Open IAM, Account settings.
2. Under Password policy, choose Edit and pick Custom.
3. Set the minimum length to 14 or more, require upper and lower case, numbers and symbols, allow users to change their own password, and prevent reuse of the last 24 passwords.
4. Save. Existing passwords are not reset; the rules apply at the next change.

aws iam update-account-password-policy --minimum-password-length 14 --require-symbols --require-numbers --require-uppercase-characters --require-lowercase-characters --allow-users-to-change-password --password-reuse-prevention 24

Rollback: Edit the password policy back in IAM Account settings. The previous values are recorded in the fix history.

1. Set up AWS Systems Manager Session Manager (no inbound port needed) or note your office/VPN IP range.
2. Open EC2, Security Groups, the group, Inbound rules, Edit inbound rules.
3. Delete the rule for port 22 or 3389 with source 0.0.0.0/0 (and ::/0), or change its source to your office/VPN range.
4. Save and test that administrators can still connect through the new path.

aws ec2 revoke-security-group-ingress --group-id <sg-id> --protocol tcp --port 22 --cidr 0.0.0.0/0
aws ec2 revoke-security-group-ingress --group-id <sg-id> --protocol tcp --port 3389 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 22 --cidr <office-cidr>

Rollback: Add the rule back with authorize-security-group-ingress, but limited to your office or VPN range rather than 0.0.0.0/0. The removed rules are listed in the fix history.

1. Open EC2, Security Groups, the group, Inbound rules, Edit inbound rules.
2. For each rule with source 0.0.0.0/0 or ::/0: delete it, or change the source to the load balancer's security group, your office/VPN range or the specific client range.
3. Keep 80/443 open only on groups attached to internet-facing load balancers or CloudFront origins; everything else should be reachable through them.

aws ec2 describe-security-group-rules --filters Name=group-id,Values=<sg-id>
aws ec2 revoke-security-group-ingress --group-id <sg-id> --ip-permissions 'IpProtocol=-1,IpRanges=[{CidrIp=0.0.0.0/0}]'
aws ec2 revoke-security-group-ingress --group-id <sg-id> --ip-permissions 'IpProtocol=tcp,FromPort=<from>,ToPort=<to>,Ipv6Ranges=[{CidrIpv6=::/0}]'

Rollback: Add rules back with authorize-security-group-ingress for the exact port, limited to the source that needs it. Every removed rule (protocol, ports, source) is listed in the fix history.

1. Turn on EBS encryption by default for the region first (EC2, Settings, EBS encryption, Manage) so new volumes are always encrypted.
2. For each existing volume: create a snapshot, copy the snapshot with encryption on, create a new volume from the encrypted copy in the same Availability Zone.
3. Stop the instance, detach the old volume (note its device name), attach the new volume on the same device name, start the instance and check it.
4. Keep the old volume for your retention period, then delete it and the unencrypted snapshot.

aws ec2 enable-ebs-encryption-by-default --region <region>
aws ec2 create-snapshot --volume-id <volume-id> --description "pre-encryption copy"
aws ec2 copy-snapshot --source-region <region> --source-snapshot-id <snapshot-id> --encrypted --kms-key-id <kms-key-id>
aws ec2 create-volume --availability-zone <az> --snapshot-id <encrypted-snapshot-id> --volume-type gp3

Rollback: Stop the instance, swap the original (unencrypted) volume back onto the same device name and start it. Keep the original until the new volume has run cleanly.

1. AWS cannot turn encryption on for an existing database. Plan a maintenance window and tell dependent teams.
2. Open RDS, the database, Actions, Take snapshot.
3. Select the snapshot, Actions, Copy snapshot, tick Enable encryption and choose the KMS key.
4. Restore the encrypted copy as a new instance (or cluster) with the same parameter and option groups, subnet group and security groups.
5. Stop writes, catch up any changes (or use DMS for near-zero downtime), then repoint the application to the new endpoint (or rename the instances so the endpoint stays the same).
6. Keep the old, unencrypted instance stopped for your retention period, then delete it and its unencrypted snapshots.

aws rds create-db-snapshot --db-instance-identifier <db-id> --db-snapshot-identifier <snapshot-id>
aws rds copy-db-snapshot --source-db-snapshot-identifier <snapshot-id> --target-db-snapshot-identifier <snapshot-id>-encrypted --kms-key-id <kms-key-id>
aws rds restore-db-instance-from-db-snapshot --db-instance-identifier <db-id>-encrypted --db-snapshot-identifier <snapshot-id>-encrypted

Rollback: Repoint the application back to the old, still-stopped unencrypted instance within your retention period. Data written to the new instance in the meantime must be reconciled.

1. Open IAM, choose Users, then the affected user.
2. On the Security credentials tab, under Multi-factor authentication (MFA), choose Assign MFA device.
3. Pick an authenticator app, passkey or hardware key and follow the prompts; the user can do this themselves from their own security credentials page.
4. Repeat for every listed user. For people who no longer need console access, remove their console password instead.

aws iam enable-mfa-device --user-name <user-name> --serial-number <mfa-device-arn> --authentication-code1 <code1> --authentication-code2 <code2>
# only after the user is confirmed not to need console access: aws iam delete-login-profile --user-name <user-name>

Rollback: Removing an MFA device weakens access control. If a device is lost, an administrator can deactivate it in IAM and the user enrols a new one.

1. Open IAM, Users, the affected user, Security credentials.
2. Create a second access key and update every system that uses the old one.
3. Set the old key to Inactive. Watch for failures for a day or two.
4. Delete the inactive key. Longer term, replace user keys with IAM roles (instance profiles, IRSA, GitHub OIDC) so there is nothing to rotate.

aws iam create-access-key --user-name <user-name>
aws iam update-access-key --user-name <user-name> --access-key-id <old-key-id> --status Inactive
# only after the new key is verified in every system: aws iam delete-access-key --user-name <user-name> --access-key-id <old-key-id>

Rollback: Set the old key back to Active (if it has not been deleted) while you finish moving the dependent system.

1. Open CloudTrail, Trails, the trail, Edit.
2. Tick Enable for all accounts in my organization if applicable, set Multi-region trail to Yes, and under Additional settings turn on Log file validation.
3. Confirm the destination bucket blocks public access and has a lifecycle rule for retention.

aws cloudtrail update-trail --name <trail-name> --is-multi-region-trail --enable-log-file-validation
aws cloudtrail start-logging --name <trail-name>

Rollback: aws cloudtrail update-trail --name <trail-name> --no-is-multi-region-trail --no-enable-log-file-validation (not recommended).

1. Open KMS, Customer managed keys, the key, Key rotation tab.
2. Tick Automatically rotate this KMS key every year (or a period of 90 to 2560 days) and save.

aws kms enable-key-rotation --key-id <key-id>

Rollback: aws kms disable-key-rotation --key-id <key-id>. Existing key versions remain usable.

1. Open GuardDuty in each region you use and choose Get started, then Enable GuardDuty.
2. From an organisation management account, delegate an administrator and turn on auto-enable for all member accounts.
3. Route findings to the Security Hub or an SNS topic so someone is told.

aws guardduty create-detector --enable --region <region>

Rollback: aws guardduty update-detector --detector-id <detector-id> --no-enable (suspends; findings are kept).

1. Open AWS Config in each region, Settings (or Get started), create a recorder for all resource types including global resources in one region, with a delivery bucket.
2. Start the recorder.

aws configservice put-configuration-recorder --configuration-recorder name=default,roleARN=<config-role-arn> --recording-group allSupported=true,includeGlobalResourceTypes=true
aws configservice put-delivery-channel --delivery-channel name=default,s3BucketName=<config-bucket>
aws configservice start-configuration-recorder --configuration-recorder-name default

Rollback: aws configservice stop-configuration-recorder --configuration-recorder-name default.

1. Open VPC, Your VPCs, the VPC, Flow logs tab, Create flow log.
2. Filter All, destination CloudWatch Logs (with an IAM role) or an S3 bucket, and create it.
3. Set a retention period on the log group or bucket.

aws ec2 create-flow-logs --resource-type VPC --resource-ids <vpc-id> --traffic-type ALL --log-destination-type s3 --log-destination arn:aws:s3:::<flow-logs-bucket>

Rollback: aws ec2 delete-flow-logs --flow-log-ids <flow-log-id>.

1. Open S3, the bucket, Permissions, Bucket policy, Edit.
2. Add a statement: Effect Deny, Principal *, Action s3:*, Resource the bucket and bucket/*, Condition Bool aws:SecureTransport = false.
3. Save and test that your clients still work (SDKs use HTTPS by default).

aws s3api put-bucket-policy --bucket <bucket-name> --policy '{"Version":"2012-10-17","Statement":[{"Sid":"DenyInsecureTransport","Effect":"Deny","Principal":"*","Action":"s3:*","Resource":["arn:aws:s3:::<bucket-name>","arn:aws:s3:::<bucket-name>/*"],"Condition":{"Bool":{"aws:SecureTransport":"false"}}}]}'

Rollback: Remove the Deny statement from the bucket policy.

1. Request or import a certificate in ACM for the hostname.
2. Open EC2, Load Balancers, the balancer, Listeners, Add listener: HTTPS 443 with the certificate, forwarding to the target group.
3. Edit the HTTP 80 listener so its default action is Redirect to HTTPS 443 (301).

aws elbv2 create-listener --load-balancer-arn <alb-arn> --protocol HTTPS --port 443 --certificates CertificateArn=<certificate-arn> --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 --default-actions Type=forward,TargetGroupArn=<target-group-arn>
aws elbv2 modify-listener --listener-arn <http-listener-arn> --default-actions '[{"Type":"redirect","RedirectConfig":{"Protocol":"HTTPS","Port":"443","StatusCode":"HTTP_301"}}]'

Rollback: Change the port-80 listener's default action back to forward.

1. Fix the source first (EBS encryption by default, encrypted volumes and databases) so new snapshots are encrypted.
2. For snapshots you must keep: copy each one with encryption on, then delete the unencrypted original once the copy is complete.
3. Delete unencrypted snapshots you no longer need (check they are not referenced by an AMI or a backup plan first).

aws ec2 copy-snapshot --source-region <region> --source-snapshot-id <snapshot-id> --encrypted --kms-key-id <kms-key-id>
aws rds copy-db-snapshot --source-db-snapshot-identifier <snapshot-id> --target-db-snapshot-identifier <snapshot-id>-encrypted --kms-key-id <kms-key-id>
# only after the encrypted copy is verified and no AMI or backup plan references it: aws ec2 delete-snapshot --snapshot-id <snapshot-id>

Rollback: A deleted snapshot cannot be recovered. Keep the unencrypted original until the encrypted copy is verified.

1. Open Bedrock, Settings, Model invocation logging, Edit.
2. Turn it on, choose which data to log (text, image, embeddings) and a destination (CloudWatch Logs and/or an S3 bucket with a role), save.

aws bedrock put-model-invocation-logging-configuration --logging-config '{"cloudWatchConfig":{"logGroupName":"<log-group>","roleArn":"<role-arn>"},"textDataDeliveryEnabled":true}'

Rollback: aws bedrock delete-model-invocation-logging-configuration.

1. Open Bedrock, Guardrails, Create guardrail: set content filters, denied topics and sensitive-information (PII) handling.
2. Create a version and reference the guardrail ID and version in every InvokeModel / Converse call or agent.

aws bedrock create-guardrail --name <name> --blocked-input-messaging "<message>" --blocked-outputs-messaging "<message>" --content-policy-config file://content.json

Rollback: aws bedrock delete-guardrail --guardrail-identifier <guardrail-id>.

1. Compare the listed resources with your AI system inventory (the AI Compliance module or your register).
2. Add any missing system to the inventory with its owner and purpose, or remove the AWS resource if it is no longer needed.

aws bedrock list-agents
aws bedrock list-knowledge-bases
aws sagemaker list-endpoints

Rollback: Not applicable: nothing is changed in AWS.

1. Open AWS Backup, Backup plans, Create backup plan (start from the Daily-35day-Retention template).
2. Assign resources by tag (for example backup=true) or by type, with an IAM role for AWS Backup.
3. Tag the databases, volumes and file systems that matter. Check the Jobs page after the first run.

aws backup create-backup-plan --backup-plan file://plan.json
aws backup create-backup-selection --backup-plan-id <plan-id> --backup-selection file://selection.json

Rollback: aws backup delete-backup-plan --backup-plan-id <plan-id>; existing recovery points stay in the vault.

1. Open RDS, the database, Modify.
2. Set Backup retention period to 7 days or more, tick Enable deletion protection, and under Availability choose Multi-AZ (this causes a brief failover when applied).
3. Apply during the next maintenance window unless you can take the failover now.

aws rds modify-db-instance --db-instance-identifier <db-id> --backup-retention-period 7 --deletion-protection --multi-az --apply-immediately

Rollback: Modify the instance back (--no-deletion-protection, --no-multi-az, shorter retention). Reducing retention deletes older automated backups.

1. Open DynamoDB, Tables, the table, Backups tab.
2. Under Point-in-time recovery, choose Edit, turn it on, save.

aws dynamodb update-continuous-backups --table-name <table-name> --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

Rollback: Run the same command with PointInTimeRecoveryEnabled=false.

1. Open S3, the bucket, Properties, Bucket Versioning, Edit, Enable, save.
2. Add a lifecycle rule to expire noncurrent versions after a set period so storage does not grow forever.

aws s3api put-bucket-versioning --bucket <bucket-name> --versioning-configuration Status=Enabled

Rollback: aws s3api put-bucket-versioning --bucket <bucket-name> --versioning-configuration Status=Suspended (existing versions are kept).

1. Open Certificate Manager, the certificate. If it is ACM-issued, check why renewal failed: usually a missing DNS validation record or the domain no longer pointing at AWS. Fix the record and ACM renews it.
2. If it was imported, obtain a renewed certificate from your CA and use Reimport certificate (same ARN, so listeners keep working).

aws acm describe-certificate --certificate-arn <certificate-arn>
aws acm import-certificate --certificate-arn <certificate-arn> --certificate fileb://cert.pem --private-key fileb://key.pem --certificate-chain fileb://chain.pem

Rollback: Not applicable: a renewed certificate replaces an expiring one. Keep the old files until the new one is confirmed in use.

1. Load balancers: EC2, Load Balancers, the balancer, Listeners, the HTTPS listener, Edit, Security policy ELBSecurityPolicy-TLS13-1-2-2021-06 (or newer).
2. CloudFront: the distribution, General, Edit, Security policy TLSv1.2_2021. This needs a custom certificate (not the default *.cloudfront.net one).

aws elbv2 modify-listener --listener-arn <listener-arn> --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06
aws cloudfront update-distribution --id <distribution-id> --distribution-config file://config.json   # ViewerCertificate.MinimumProtocolVersion = TLSv1.2_2021

Rollback: Set the previous security policy back with the same command.

1. Open CloudWatch, Log groups, select the group, Actions, Edit retention setting, pick a period (for example 1 year) and save.
2. Optionally Actions, Edit encryption, and choose a KMS key whose policy allows the logs service principal.

aws logs put-retention-policy --log-group-name <log-group-name> --retention-in-days 365
aws logs associate-kms-key --log-group-name <log-group-name> --kms-key-id <kms-key-arn>

Rollback: aws logs delete-retention-policy --log-group-name <log-group-name> (already-expired events are gone).

1. Open Security Hub in each region, Go to Security Hub, tick AWS Foundational Security Best Practices (and CIS if you want), Enable Security Hub.
2. From an organisation management account, delegate an administrator and auto-enable new accounts.

aws securityhub enable-security-hub --enable-default-standards --region <region>

Rollback: aws securityhub disable-security-hub --region <region>.

1. Open AWS Config, Conformance packs, Deploy conformance pack.
2. Choose a sample template (for example Operational Best Practices for CIS AWS Foundations Benchmark) and deploy it.
3. Review the resources the rules flag, fix them or document exceptions.

aws configservice put-conformance-pack --conformance-pack-name <name> --template-s3-uri s3://<bucket>/<template>.yaml

Rollback: aws configservice delete-conformance-pack --conformance-pack-name <name>.

1. Open IAM, Access Analyzer, Analyzers, Create analyzer.
2. Choose External access, zone of trust = this account (or the organisation from the management account), and create it in each region you use.
3. Review and archive or fix the findings it produces.

aws accessanalyzer create-analyzer --analyzer-name <name> --type ACCOUNT --region <region>

Rollback: Delete the analyzer (aws accessanalyzer delete-analyzer). Its findings are lost.

1. Open Inspector, Get started, Activate Inspector (EC2, ECR and Lambda scanning).
2. Make sure instances are managed by Systems Manager (the SSM agent is how Inspector scans EC2), or turn on agentless scanning.

aws inspector2 enable --resource-types EC2 ECR LAMBDA --region <region>

Rollback: aws inspector2 disable --resource-types EC2 ECR LAMBDA.

1. Attach an instance profile with the AmazonSSMManagedInstanceCore policy to each instance (or use Default Host Management Configuration in Systems Manager, Fleet Manager settings).
2. Make sure the instance can reach the SSM endpoints (internet, NAT or ssm/ssmmessages/ec2messages VPC endpoints) and the SSM agent is installed (it is on Amazon Linux, Ubuntu and Windows AMIs).
3. Check Fleet Manager shows the instance Online, then set up Patch Manager.

aws ec2 associate-iam-instance-profile --instance-id <instance-id> --iam-instance-profile Name=<profile-name>
aws ssm describe-instance-information

Rollback: Detach the instance profile; the instance drops out of Systems Manager.

1. Create an SNS topic with an email (or chat) subscription and confirm it.
2. Open CloudWatch, Alarms, Create alarm, for example on a CloudTrail metric filter for root sign-in or unauthorised API calls, and set the alarm action to the topic.
3. Add availability alarms (5xx rate, unhealthy hosts, CPU) for your main services.

aws sns create-topic --name <topic-name>
aws cloudwatch put-metric-alarm --alarm-name <alarm-name> --metric-name <metric> --namespace <namespace> --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --alarm-actions <topic-arn>

Rollback: aws cloudwatch delete-alarms --alarm-names <alarm-name>.

1. Open Secrets Manager, the secret, Rotation configuration, Edit rotation.
2. Turn on automatic rotation, choose a schedule (for example every 30 days) and a rotation function (AWS provides templates for RDS, Redshift and DocumentDB).
3. Test rotation once by hand and confirm the application picks up the new value.

aws secretsmanager rotate-secret --secret-id <secret-name> --rotation-lambda-arn <rotation-function-arn> --rotation-rules AutomaticallyAfterDays=30

Rollback: aws secretsmanager cancel-rotate-secret --secret-id <secret-name>; the current value stays valid.

1. Open WAF & Shield, Web ACLs, Create web ACL (scope CloudFront for distributions, Regional for ALBs).
2. Add the AWS managed rule groups Core rule set and Known bad inputs (and Amazon IP reputation list), in Count mode first if you are unsure.
3. Associate the web ACL with the distribution or load balancer; watch the sampled requests, then switch rules to Block.

aws wafv2 create-web-acl --name <name> --scope REGIONAL --default-action Allow={} --rules file://rules.json --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=<name>
aws wafv2 associate-web-acl --web-acl-arn <web-acl-arn> --resource-arn <load-balancer-arn>

Rollback: aws wafv2 disassociate-web-acl --resource-arn <resource-arn> (or clear web_acl_id on the distribution).

1. Open Macie in each region with buckets, Get started, Enable Macie.
2. Create a sensitive data discovery job for the buckets that may hold personal data (automated discovery is on by default).

aws macie2 enable-macie --region <region>

Rollback: aws macie2 disable-macie --region <region>.

1. Open VPC, Endpoints, Create endpoint.
2. Add gateway endpoints for S3 and DynamoDB (free) to the route tables of your private subnets.
3. Add interface endpoints for the services your workloads use (for example Secrets Manager, SSM, ECR, CloudWatch Logs) in each private subnet, with private DNS on.

aws ec2 create-vpc-endpoint --vpc-id <vpc-id> --service-name com.amazonaws.<region>.s3 --route-table-ids <rtb-id>
aws ec2 create-vpc-endpoint --vpc-id <vpc-id> --vpc-endpoint-type Interface --service-name com.amazonaws.<region>.secretsmanager --subnet-ids <subnet-id> --security-group-ids <sg-id>

Rollback: aws ec2 delete-vpc-endpoints --vpc-endpoint-ids <endpoint-id>; traffic returns to the NAT or internet route.

1. Compare the listed regions with your documented data residency commitments.
2. Move or delete resources in regions you did not intend to use, then disable unused regions (Account, AWS Regions) or restrict them with an SCP.

aws ec2 describe-regions --all-regions
# only after the region is verified empty: aws account disable-region --region-name <region>

Rollback: aws account enable-region --region-name <region>.

1. Open IAM, Roles, the affected role, then Edit next to Maximum session duration.
2. Set 1 to 4 hours and save. Callers that asked for longer sessions will be refused until they request a shorter one.

aws iam update-role --role-name <role-name> --max-session-duration 14400

Rollback: Set the maximum session duration back with the same command.

1. Open AWS Artifact, Agreements, Account agreements (or Organization agreements from the management account).
2. Find the AWS Business Associate Addendum, review it, tick the acknowledgement and choose Accept.
3. Keep only HIPAA-eligible services in scope for PHI.

aws artifact list-customer-agreements

Rollback: Agreements can be terminated in AWS Artifact; do not without legal advice.

1. Open the Account page (account menu, Account), Alternate contacts, Edit.
2. Fill in the Security contact with a monitored team address and phone number, save.

aws account put-alternate-contact --alternate-contact-type SECURITY --email-address <security-team-email> --name "<name>" --phone-number "<phone>" --title "<title>"

Rollback: aws account delete-alternate-contact --alternate-contact-type SECURITY (not recommended).

1. Open IAM, Access Analyzer, and generate a policy from CloudTrail activity for the affected principal, or review Access Advisor (Last accessed) on the principal.
2. Write a replacement policy that lists only the actions and resources actually used.
3. Attach the new policy, detach the broad one, and watch for AccessDenied errors over a normal business cycle.

aws iam generate-service-last-accessed-details --arn <principal-arn>
aws iam detach-role-policy --role-name <role-name> --policy-arn <broad-policy-arn>

Rollback: Re-attach the previous policy version (IAM keeps up to five versions of a customer managed policy).

1. Sign in as the root user (the account email address), not as an IAM user. Only the root user can change root settings; no IAM role, including TrustProof's, can.
2. Open the account menu (top right), choose Security credentials.
3. Under Multi-factor authentication (MFA), choose Assign MFA device and register a hardware key or authenticator app. AWS allows up to eight devices; register two and store one securely.
4. Sign out and keep the root credentials and recovery codes in your organisation's secure store.

# No CLI path: root MFA is set in the console by the root user.

Rollback: Not applicable: removing root MFA is never recommended. If the device is lost, use the AWS account recovery process.

1. Find what uses the key first: check CloudTrail for recent calls made with the root access key ID.
2. Sign in as the root user and open Security credentials.
3. Under Access keys, make the key Inactive, wait for any dependent job to fail or be moved to an IAM role, then Delete it.
4. Replace any automation with an IAM role or, if a key is unavoidable, a least-privilege IAM user key with rotation.

# Root keys are managed by the root user in the console. For the replacement IAM user:
aws iam create-access-key --user-name <automation-user>

Rollback: A deactivated key can be made active again by the root user until it is deleted. A deleted key cannot be recovered; create a new one only if there is no alternative.