Least privilege means giving every person, application and automated process only the AWS permissions it needs for its job, and nothing more. In practice that means replacing broad permissions with narrow ones, in small steps, using what AWS has recorded about what each identity actually does. You do not need to design perfect policies on day one: AWS’s own IAM best practices accept that you “might start with broad permissions” while you learn what a workload needs, then tighten them.
The risk is not theoretical. Under the shared responsibility model, who can do what inside your account is your job, not AWS’s. An over-permissioned identity turns one stolen key or one phished login into a company-wide incident.
Where over-permissioning comes from
Most excess access is not malice or laziness. It is the residue of getting things working.
| Pattern | How it happens | Why it matters |
|---|---|---|
| Admin rights for convenience | Someone was blocked on a permissions error and was given AdministratorAccess “for now” | “For now” becomes years; every admin is a full-account compromise waiting for a password |
| Wildcards in policies | Action: "*" or Resource: "*" is the fastest way to stop an error | The policy allows far more than the job needs, including actions no one has thought about |
| Long-lived access keys | A key created for a script in 2021 is still in a repository or a laptop | AWS recommends temporary credentials through roles and federation instead of long-term keys |
| Orphaned identities | Leavers’ users, old project roles, tools no one uses | Unused access nobody is watching is the easiest to abuse |
| Daily use of the root user | The account’s founder logs in as root | AWS says to use the root user only for tasks that require it |
A five-step audit a small team can run
- Secure the top. Check the root user has MFA and no access keys it does not need, and do daily work through an administrative user in IAM Identity Center rather than as root.
- List who has administrator access. Anyone on that list should be able to say why. For most small teams the honest answer is two or three people.
- Find unused identities. The IAM console shows when each user, role and credential was last used. Disable first, delete after a quiet month.
- Replace broad policies with narrower ones. Start from an AWS managed policy for a job function. AWS notes these might not be least-privilege, so move to customer managed policies written for your use case.
- Repeat. Permissions drift. Put a quarterly review in someone’s calendar.
Let AWS’s own data do the narrowing
Guessing what a role needs is how outages happen: you remove a permission and an overnight job fails. AWS gives you the evidence instead.
| Tool | What it tells you | Limits |
|---|---|---|
| Last-accessed information | Which services (and, for management actions, which actions) an identity has used | Service-level data goes back at least 400 days; action-level data does not cover data plane events |
| Policy generation in IAM Access Analyzer | Builds a policy from up to 90 days of CloudTrail activity | At no additional charge, but iam:PassRole is not tracked, and AWS says not to use it for auditing |
| Unused access findings | Unused roles, unused access keys and passwords, and unused permissions | Charged per role or user analysed per month; external access findings are free |
One caution: generated policies are a starting draft. Review them, because a role that runs a quarterly or annual job will not show it in a 90-day window.
A worked example
(Illustrative.) A 20-person investment-operations firm has 60 IAM users and roles in its main AWS account. An audit finds seven people with AdministratorAccess, four access keys unused for over a year, and one Lambda role with a wildcard on S3. The firm does the following over two weeks:
- Cuts administrators from seven to three, using IAM Identity Center for day-to-day access.
- Disables the four stale keys, and deletes them after a month with no complaints.
- Uses policy generation to replace the Lambda role’s wildcard with the four S3 actions it used on one bucket.
- Turns on unused access analysis for the account. At AWS’s example rate of $0.20 per role or user per month, 60 identities cost $12 a month.
The tooling cost is small next to the engineering time, which is why the first pass is best treated as a short project rather than an ongoing chore.
Guardrails across the whole account
Narrow policies protect one identity at a time. Two features protect the account from the mistakes that slip through: service control policies and permissions boundaries. Service control policies set the maximum permissions for every account in an AWS Organization, and permissions boundaries let you delegate permission-setting without letting someone grant themselves more than you intended. Neither grants access on its own; they limit what other policies can grant.
Why this matters to a regulated firm
The FCA does not prescribe how you design IAM. But if a cyber incident disrupts an important business service, you will be asked how access to your systems was controlled. Our FCA operational resilience guide covers that expectation. A small set of named administrators, short-lived credentials and an access review you can evidence are a far better answer than “we have not looked”.
Least privilege is the cheapest security improvement most AWS accounts have left. If you would like it reviewed as part of a wider resilience check, see our disaster recovery and resilience service.
