In the first week of a new cloud account, do five things: protect the top-level owner identity, move people to temporary access, turn on audit logging, block public storage at the account or organization level, and avoid long-lived keys. Each has a provider setting you can apply in an hour or less.
Day 1: secure the top identity
The first identity in a new account can do everything.
- AWS: secure the root user with MFA, no access keys and a group mailbox. AWS says all account types require MFA on root, and recommends several MFA devices. See the root user post.
- Azure: the person who signs up for the tenant becomes a Global Administrator. Limit how many people hold that role, and know that it can elevate to manage all subscriptions. See Azure roles versus Entra roles.
- Google Cloud: keep the list of people with organization-level administrative roles short and reviewed.
Day 2: move people to temporary access
Create administrative identities for daily work and stop using the owner account. In AWS that means IAM roles, or IAM Identity Center for multiple accounts. Aim for no long-term user credentials.
Day 3: turn on logging
You cannot investigate what you did not record.
- AWS: event history gives 90 days of management events per Region. Create a trail or event data store for more. See CloudTrail event history versus a trail.
- Azure: activity logs are collected automatically, but resource logs need a diagnostic setting. See Azure log types.
- Google Cloud: Admin Activity logs are always on, but Data Access logs are off except for BigQuery. See GCP audit logs.
Click through it at your own pace, or open it full screen.
Day 4: close the public storage door
- AWS: turn on all four S3 Block Public Access settings for the account. See the four settings.
- Azure: set AllowBlobPublicAccess to false on storage accounts. See disabling anonymous blob access.
- Google Cloud: use the storage.publicAccessPrevention organization policy. See public access prevention.
Day 5: remove long-lived keys
Static keys are the credentials most often found in repositories.
- Use OIDC from your CI to your cloud. See GitHub Actions to AWS with OIDC.
- On Google Cloud, block service account key creation. See service account key alternatives.
- On Azure, use managed identities. See system-assigned versus user-assigned.
Weekend: smaller defaults
- On AWS, enable EBS encryption by default in each Region, and require IMDSv2 on instances.
- Review security groups for world-open SSH and RDP.
What to write down
Record who owns the account, where logs go, who can change guardrails, and which exceptions exist and why. A one page record saves hours later, and it is the first thing an auditor or incident responder will ask for.
Where Safeguard fits
Once the baseline is in place, Safeguard's asset discovery and compliance and evidence automation can help you keep track of what runs and show that controls stay on. Start with the free scan at gold.safeguard.sh/scan if you want a first look at your dependencies.
Quick check
What is the single most important step?
Securing the top-level owner identity. Everything else assumes nobody can simply take over the account.
Do these steps cost money?
Most are settings with no direct charge, but logging and some key features have costs. Check your provider's current pricing before enabling data event logging at scale.
Sources
- Root user best practices for your AWS account
- Azure roles, Microsoft Entra roles, and classic subscription administrator roles
- Working with CloudTrail event history
- Azure Monitor data sources and data collection methods
- Cloud Audit Logs overview
Last reviewed: 19 October 2026.
