Every cloud account has one identity that can do anything, including things no policy can prevent: close the account, change billing, remove other administrators. Using that identity for daily work is the most common avoidable mistake in cloud security.
Why the split matters
An identity that can do anything cannot be constrained, monitored meaningfully, or safely shared. If it is compromised, there is no policy that limits the damage and often no clean way to revoke access quickly. Every other identity in the account can be scoped, logged and revoked.
-
Root or owner
Created with the account. Unconstrained. Should be used for a handful of tasks that genuinely require it, and otherwise left alone.
-
Administrative identity
Created by you, with broad but revocable permissions and its own multi-factor authentication. This is what you use.
-
Service identities
Machine credentials scoped to one job. No console access, minimum permissions, rotated on a schedule.
Setting it up
- Secure the root identity: strong unique password, multi-factor authentication enabled, recovery contacts correct.
- Create an administrative identity for yourself with its own multi-factor authentication.
- Verify you can perform your normal work as that identity.
- Remove any access keys attached to the root identity.
- Store the root credentials and recovery codes somewhere secure and documented.
- Record which tasks genuinely require root, so nobody reaches for it casually.
What still needs root
The list is short and provider-specific, but typically includes changing account-level billing details, closing the account, and a small number of account-wide settings. Everything else – creating resources, deploying, managing users – should be possible under a scoped identity.
Least privilege, applied pragmatically
Perfect least-privilege policies are a research project. A workable version is: start people with the permissions their role plainly needs, add specific permissions when something is blocked, and review the set periodically. That is far better than granting everyone administrator access because refining policies is tedious.
- Group permissions by role rather than attaching them to individuals.
- Prefer provider-managed policies as a starting point, then narrow.
- Keep a short list of who has administrative access, and review it quarterly.
- Use temporary elevation where the platform supports it.
Summary
Secure the all-powerful identity, then stop using it. Work under something scoped, logged and revocable. It takes five minutes to set up and it is the difference between a compromised credential being an incident and being a catastrophe.
