Who can get into your AWS account: the entry points a user list doesn't show

TL;DR. Most AWS access reviews start with the list of IAM users, which is the smallest part of the answer. A role’s trust policy can name an external identity provider, another AWS account, an AWS service, or a federated web identity — so principals with no user record in your account can assume roles in it. Worse, those trust relationships have no lifecycle. A person leaving triggers a process; a vendor relationship ending, a pipeline being retired or an account being closed usually triggers nothing at all, and the trust survives. The inventory worth building is not “who has an account” but “what can assume a role here, and who controls each of those things today.”

Why the user list is the wrong starting point

Ask most teams how many people can access their AWS account and they will check IAM users, maybe cross-reference their identity provider, and give you a number. It is a reasonable answer to a question that is not quite the one that matters.

An IAM user is one kind of principal. AWS documents several others that a role’s trust policy can name: another AWS account or an IAM role inside it, an AWS service, a SAML or OIDC identity provider, and federated web identities. Each of those is a way to obtain credentials in your account without ever appearing in your user list.

This is not a misconfiguration. It is how roles are designed to work, and most of these trusts were created deliberately by someone who needed them. The problem is not that they exist. It is that they are recorded in a different place from the thing everyone reviews.

The four entry points people forget

Your identity provider

If you have connected single sign-on, a role trusts your identity provider rather than any individual. Whoever that provider vouches for can assume the role. The list of people who can get in is therefore maintained in a different system — often by a different team — and your AWS user list will never reflect it.

The practical consequence: an access review inside AWS cannot answer “who can use this role” on its own. You have to go and read the group membership on the other side.

Another AWS account

A role can trust an entire AWS account. When it does, the permission to assume it is delegated: anyone in that account who is allowed to call assume-role can come through. You are trusting that account’s own access controls, whoever administers them.

That is fine when the other account is yours. It deserves more thought when it belongs to a partner, a managed service provider, or a company you acquired.

Your build pipeline

Modern CI systems authenticate to AWS with a short-lived token from an OIDC provider rather than a stored key, which is a genuine security improvement. It also means the pipeline is a principal. A role trusts your CI provider, scoped by conditions on which repository and which branch.

Get those conditions wrong or leave them broad, and the practical meaning is that a change to a code repository becomes a change in your AWS account. Anyone who can merge can, indirectly, act in production.

The tool you connected two years ago

Every third-party product you have given AWS access to — cost dashboards, security scanners, backup tools, monitoring vendors — holds a role in your account, usually one it can assume from its own AWS account, protected by an external ID.

These accumulate. They are created during an evaluation, survive the evaluation, and are rarely removed when the tool is dropped.

The part that actually bites: nothing offboards

Here is the asymmetry worth internalising.

When a person leaves your company, a process fires. HR closes the ticket, IT disables the account, a checklist gets worked through. It is imperfect, but it exists, and someone owns it.

When a trust relationship becomes obsolete, nothing fires. The vendor contract ends and the role stays. The pipeline is retired and the trust stays. The partner account is closed and the trust stays, now pointing at an account ID that could in principle be reissued. There is no expiry on a trust policy, no renewal date, and no alert.

The result is that the set of things which can enter your account only ever grows, while the set of people is actively pruned. Over a few years those two curves diverge a long way.

How to inventory the ways in

You are building a different list from the one you already have.

1. Enumerate roles, not users. For every role in the account, read its trust policy and record what it names — an account, a service, a provider, a federated identity.
2. Resolve each principal to a human owner. For an identity provider, that means the group on the other side. For another account, the team that administers it. For a pipeline, the repository and branch conditions. For a vendor, the contract.
3. Ask when each one was last used. IAM records a last-used timestamp for roles. A role no one has assumed in a year is a strong candidate for removal.
4. Ask who would notice if it were removed. If the answer is nobody, that is your answer.
5. Give each trust an owner and a review date, since AWS will not give it one for you.

Step three is where most of the value is. Unused roles with live trusts are the clearest signal you have, and they are cheap to find.

What this does not tell you

This is an inventory of entry points, not of risk. It says how many ways in exist and who controls them. It does not tell you how far any of them can get once inside — that is a different analysis, about how permissions compose into privilege escalation paths, and it is worth doing alongside this one rather than instead of it.

The two questions pair naturally. This one asks who can get in. That one asks what happens next.

FAQ

Does an IAM user list show everyone who can access my AWS account?

No. IAM users are one kind of principal. Roles can also be assumed by other AWS accounts, AWS services, SAML or OIDC identity providers, and federated web identities. Principals arriving through any of those routes never appear in your user list.

Do AWS trust relationships expire?

No. A role’s trust policy has no expiry date and no renewal requirement. It stays exactly as written until somebody edits or deletes it, which is why obsolete trusts accumulate silently after a vendor, pipeline or partner account goes away.

How do I find roles nobody uses any more?

IAM records a last-used timestamp for each role. Roles with a live trust policy and no recent use are the highest-value candidates for review, because they carry a standing entry point that nothing currently depends on.

Is trusting an entire AWS account a bad practice?

Not inherently, but it delegates the decision. Anyone in the trusted account who is permitted to assume the role can enter yours, governed by that account’s controls rather than your own. Scoping the trust to a specific role rather than the whole account narrows it considerably.

What is the difference between this and a privilege escalation review?

This inventories the ways into an account. A privilege escalation review asks how far a principal can get once inside, by composing individually reasonable permissions. Both are worth doing, and neither substitutes for the other.