A new AWS account needs five things before any workload: a locked down root user, people signing in through federation with temporary credentials, MFA wherever a user still exists, a multi-Region CloudTrail trail that outlives the 90 day event history, and organization level guardrails. Everything below comes from AWS documentation.
What do you do with the root user?
AWS tells you to safeguard root credentials the way you would protect other sensitive personal information, and points to a separate root user best practices page. We read only the summary line, so use that page for the detailed steps. Where you do need a root or IAM user, AWS says to require MFA, and recommends phishing resistant MFA such as passkeys and security keys wherever possible.
How should people and workloads sign in?
The IAM best practices page puts temporary credentials first, for both groups.
For people, use federation with an identity provider so users assume roles and receive temporary credentials. For central management AWS recommends IAM Identity Center.
For workloads, use IAM roles. On EC2 or Lambda, AWS delivers the role's temporary credentials, so there is no need to distribute long lived keys. For workloads outside AWS, the page lists options: IAM Roles Anywhere with an X.509 certificate, AssumeRoleWithSAML, and AssumeRoleWithWebIdentity with a token from a configured identity provider. A CI system is a typical case for the web identity route.
Long term access keys are for cases that really need them, and the page says to update them when needed, for example when an employee leaves, using last used information to do so safely.
How do you keep permissions small?
Start broad only while you explore, then reduce toward least privilege. AWS suggests starting with AWS managed policies, then moving to customer managed policies, since managed ones are shared by all customers and may be too wide. IAM Access Analyzer can generate fine grained policies from CloudTrail activity, validate policies with more than 100 checks, and find public and cross-account access. Review and remove unused users, roles and credentials using last accessed information. Conditions can restrict further, such as requiring TLS.
What about many accounts?
AWS recommends separating workloads across accounts under AWS Organizations, using service control policies for principals and resource control policies for resources as guardrails. The page is careful that SCPs and RCPs grant nothing; permissions still come from identity or resource policies. Permissions boundaries set the maximum a delegated role can receive.
How do you keep an audit trail?
CloudTrail's console shows event history, and a trail extends it. The AWS page says a trail gives you a record of events beyond 90 days, can send events to CloudWatch Logs for alarms, and allows querying with Athena. It recommends a multi-Region trail because it captures activity in all enabled Regions, and all trails made in the console are multi-Region. With Organizations you can create one trail for every member account, which only the management account or a delegated administrator can do. If delivery to the S3 bucket fails, CloudTrail retries for 30 days.
We did not read the CloudTrail integrity validation or bucket policy pages, so check those for log tamper protection.
What to do
- Secure the root user, enable phishing resistant MFA, and stop using root for daily work.
- Set up IAM Identity Center or another identity provider for people.
- Use IAM roles for all workloads, and use Roles Anywhere or web identity for CI.
- Ban new long term access keys unless a documented exception exists.
- Create an organization trail that is multi-Region and delivers to a protected S3 bucket in a separate account.
- Apply SCPs to block disallowed actions across accounts.
- Turn on IAM Access Analyzer and review its findings.
- Schedule a monthly review of unused credentials.
- Write down the baseline and check each new account against it.
Safeguard can scan the infrastructure as code and dependencies you deploy into the account, and its compliance automation can help organise evidence, though this post covers account settings it does not manage.
Quick check
Do service control policies grant permissions?
No. AWS says SCPs and RCPs only set guardrails. You still need identity or resource policies to grant access.
Why create a trail if event history exists?
A trail keeps a record beyond 90 days and can feed alarms and queries.
Sources
- AWS: security best practices in IAM (fetched 18 October 2026)
- AWS CloudTrail: creating a trail (fetched 18 October 2026)
Last reviewed: 18 October 2026.
