You created your AWS account. You logged in with the email and password. You've been doing everything — deploying services, checking billing, configuring domains — with that same root login. You know you shouldn't, but you're the only person on the team, and setting up "proper IAM" sounds like it takes a week and a degree in cloud security.
It doesn't. Here's the practical setup that takes under 20 minutes, requires minimal ongoing maintenance, and reduces your account's risk by an order of magnitude.
Why Root Is Dangerous
The root account is not just an admin account — it's a god account. It can do things that no IAM user, no IAM role, and no Service Control Policy can prevent: close the account, change the root email, modify consolidated billing, and access billing information regardless of IAM policies. If an attacker gets root access, no guardrail in AWS can save you.
Every time you log into the console with root credentials, every time you use root to deploy a service, you're exposing those credentials to potential interception — through browser extensions, session hijacking, or simply someone looking over your shoulder.
The 20-Minute IAM Setup
Step 1: Secure the Root Account (5 minutes)
Log in as root for the last time. Go to IAM → Security credentials. Enable MFA — use a hardware key if you have one, otherwise use an authenticator app. Delete any root access keys if they exist (run aws iam list-access-keys to check). Write down the root email and password and store them in a physical safe or a dedicated password manager vault. You should only need root credentials 2-3 times a year for billing changes or if you lock yourself out of IAM.
Step 2: Set Up IAM Identity Center (10 minutes)
IAM Identity Center (formerly AWS SSO) is the modern way to manage user access. It gives you temporary credentials that expire automatically — no long-lived access keys to leak.
Go to IAM Identity Center in the console. Enable it (it takes about 2 minutes to initialize). Create a user for yourself with your email address. Create a permission set called "AdminAccess" that uses the AdministratorAccess managed policy. Assign yourself to the account with that permission set.
You'll get an SSO portal URL (something like d-xxxxxxxxxx.awsapps.com/start). Bookmark this — it's your new login page. From now on, you log in through the SSO portal, not the root console.
Step 3: Configure CLI Access via SSO (5 minutes)
Update your AWS CLI to use SSO credentials instead of long-lived access keys. Run:
aws configure sso
SSO session name: my-sso
SSO start URL: https://d-xxxxxxxxxx.awsapps.com/start
SSO region: us-east-1
SSO registration scopes: sso:account:accessFollow the browser prompt to authenticate. Select your account and role. The CLI will create a profile in ~/.aws/config that uses temporary SSO credentials. These credentials expire automatically and are refreshed when you run aws sso login.
No more access keys in ~/.aws/credentials. No more keys that could be accidentally committed to Git.
What About Service Access Keys?
If your application needs to call AWS APIs (S3, SES, DynamoDB, etc.), use IAM roles — not access keys. If your application runs on EC2, attach an IAM instance profile with a role that has only the permissions it needs. If it runs on Lambda, the execution role handles this automatically. If it runs on ECS/Fargate, use the task execution role.
The only legitimate use case for long-lived access keys in 2026 is CI/CD pipelines running outside AWS and legacy applications that can't use temporary credentials. Even for CI/CD, consider using OIDC federation with GitHub Actions or GitLab CI instead of access keys.
The Minimum IAM Policies
You don't need to write complex IAM policies as a solo engineer. Start with the AdministratorAccess managed policy for your SSO user (you need it since you're managing everything), and scope service roles down to what each service actually needs. The IAM policy simulator and IAM Access Analyzer will help you tighten policies over time as you understand your access patterns.
The important thing is that your admin access goes through SSO with MFA and temporary credentials — not through root, and not through a static access key.
When You Add Your First Team Member
When you hire your first engineer, the SSO setup pays off immediately. Create a new user in IAM Identity Center, create a permission set with the access they need (probably not full admin), and assign them. They get their own login, their own temporary credentials, and you have a clear audit trail in CloudTrail of who did what. No shared passwords, no shared access keys.
The Automated Safety Net
Even with a good IAM setup, things drift. Someone creates an access key "temporarily." A permission set gets broadened during an incident and never tightened back. A new IAM role gets created with wider permissions than intended.
Vigilare monitors your IAM configuration continuously — access key age, MFA status, overly permissive policies, unused permissions — and flags drift before it becomes a security gap. It's the automated version of remembering to check your IAM configuration every month. Start a free trial.
Related Reading
Protect your AWS accounts before it's too late
Vigilare monitors your AWS accounts for suspension risks — billing anomalies, IAM issues, GuardDuty findings, and more — and alerts you before AWS takes action.
Written by Viktor B.
Co-founder & CEO