AWS IAM doubled managed policies per role to 20 in August 2026 — three caps did not move

Summary. On 19 August 2026 AWS Identity and Access Management raised the default quota for managed policies per role from 10 to 20, with a maximum of 25 available through Service Quotas. The change landed in all commercial AWS Regions, AWS GovCloud (US) and the China Regions, and applied automatically to every existing IAM role with no action required. Three limits sitting directly next to it did not move: managed policies per group stays at 10 and is not adjustable at all, managed policies per user stays at a default of 10, and AssumeRole still accepts a maximum of 10 managed policy ARNs per session inside a 2,048-character budget. The per-policy size ceiling of 6,144 characters is unchanged and cannot be raised. Anyone whose least-privilege design routes through session policies or groups gets nothing from this announcement, and three AWS documentation surfaces now report the same quota as 20, as 2, and not at all.

What changed, exactly

The announcement is narrow and precise. AWS states that IAM "has increased the default quota for managed policies per role from 10 to 20", and that "if you need more than 20 managed policies per role, you can request a quota increase up to 25 using Service Quotas". AWS gives two reasons: teams following the practice of separating permissions into purpose-specific policies were burning Service Quotas requests to do it, and onboarding to AWS Partner products often requires attaching extra managed policies to an existing role.

The IAM and AWS STS quotas page now lists Managed policies per role with a default quota of 20 and a maximum quota of 25 in its table of resources whose increases are automatically approved. That table also says requests up to the maximum "are automatically approved and completed within a few minutes", which is the more useful half of the news: the walk from 20 to 25 is a self-service change, not a support case.

The AWS General Reference confirms the same figure from a different angle and adds the quota codes. Managed policies per role reads "Each supported Region: 20", adjustable, quota code L-0DA4ABF3. Managed policies per user reads "Each supported Region: 10", adjustable, quota code L-4019AD8B.

The three caps that did not move

Limit	Value before 19 Aug 2026	Value now	Adjustable?
Managed policies per role	10	20 (max 25)	Yes, L-0DA4ABF3
Managed policies per user	10	10 (max 20)	Yes, L-4019AD8B
Managed policies per group	10	10 (max 10)	No
Managed policy length	6,144 characters	6,144 characters	No
Managed policy ARNs per session	10	10	Not published as adjustable

Read the group row twice. The AWS General Reference marks Managed policies per group as not adjustable, so 10 is a hard ceiling, not a default you can raise with a ticket. An estate that grants human access through IAM groups rather than assumed roles is unaffected by the 19 August change and has no path to 20.

The user row is one step behind: default 10, maximum 20. So a role can now carry 25 managed policies where a user tops out at 20 and a group at 10. That spread did not exist before; the three entity types used to share the same default.

Sessions are where this actually bites

The limit most teams will hit is not on the role at all. It is on the session.

The IAM and AWS STS quotas page states that for role session policies, "the size of the passed JSON policy document and all passed managed policy ARN characters combined can't exceed 2,048 characters", and that "you can pass a maximum of 10 managed policy ARNs when you create a session". Neither number changed on 19 August.

That matters because session policies are the standard mechanism for downscoping. A SaaS vendor assuming a customer role, a CI/CD job narrowing its own permissions per pipeline stage, a broker minting short-lived credentials per tenant — all of them call AssumeRole with a policy document, ARNs, or both. A role that has been split into 20 purpose-specific managed policies cannot be mirrored into a session that accepts 10 ARNs inside 2,048 characters. The permission model AWS is now encouraging on the role side cannot be expressed on the session side.

The same page adds a compression detail that catches people out: session policies and session tags are packed into a binary format with a separate limit, and the PackedPolicySize response element reports by percentage how close the request came to it. The session-tags documentation lists the failure conditions plainly — more than 50 session tags, tag keys over 128 characters, tag values over 256 characters, or session policies totalling more than 2,048 characters. Attribute-based access control designs that pass a dozen tags alongside session policies are working inside a budget that did not grow.

What breaks: the guardrails written against 10

The announcement says the change "applies automatically to all IAM roles in your account with no action required". That is the operational risk in one sentence.

Most mature AWS estates encode the old number somewhere. A Config rule or CSPM policy asserting no more than ten attached managed policies per role. A Terraform or CDK lint step. A pull-request check on aws_iam_role_policy_attachment counts. A pipeline that fails a deployment when attachment reaches the quota. None of those break loudly. They keep passing while the actual surface doubles, which is the worst failure mode a permissions guardrail has: silence.

Two practical checks are worth running this week. First, inventory roles by attached-policy count and look for the ones that were previously pinned at 10 because the quota stopped them — those are the roles most likely to grow now. Second, grep your policy-as-code for the literal 10 near managed-policy attachment logic and decide deliberately whether your internal ceiling should follow the AWS default up to 20 or stay where it is. AWS raising a quota is not the same as AWS recommending you use it. The real cost of a permissions change is usually the review burden it creates, not the API call.

For teams already running a posture-management baseline across accounts, the same reasoning applies to the detective controls covered in our guide to AWS Security Hub multicloud posture decisions. If your baseline compares live configuration against a hardcoded quota rather than against the account's reported quota, this is the week it drifted.

AWS documentation reports the same quota three ways

The gap between AWS surfaces is wide enough to matter if you are building automation against it.

Source	What it reports for managed policies per role
IAM and AWS STS quotas page	Default 20, maximum 25
AWS General Reference, IAM quotas	Each supported Region: 20, adjustable, L-0DA4ABF3
GetAccountSummary API Reference sample	AttachedPoliciesPerRoleQuota set to 2
AWS CLI 2.36.7 get-account-summary example	Key absent from the sample output entirely

The GetAccountSummary API Reference presents its numbers plainly under "Sample Response" with no label marking them as illustrative, and its sample shows AttachedPoliciesPerRoleQuota, AttachedPoliciesPerUserQuota and AttachedPoliciesPerGroupQuota all set to 2. The AWS CLI 2.36.7 reference for the same command shows a different sample again — GroupsQuota 100, RolesQuota 250, InstanceProfilesQuota 100 — against the General Reference values of 300, 1,000 and 1,000. Three pages, three sets of numbers, one live quota.

The consequence is straightforward. Do not read your quota out of documentation. Read it out of the account. aws iam get-account-summary returns a SummaryMap whose valid keys include AttachedPoliciesPerRoleQuota, AttachedPoliciesPerUserQuota and AttachedPoliciesPerGroupQuota, and that map is the only source that reflects what your account will actually enforce today.

aws iam get-account-summary \
  --query 'SummaryMap.{Role:AttachedPoliciesPerRoleQuota,User:AttachedPoliciesPerUserQuota,Group:AttachedPoliciesPerGroupQuota}'

Where the extra ten slots should and should not go

AWS documentation on managed policies and inline policies draws the line clearly: an AWS managed policy is created and administered by AWS and "you cannot change the permissions defined in AWS managed policies", updates to which "affect all principal entities" the policy is attached to; a customer managed policy is one you create and can change as often as you like; an inline policy "maintains a strict one-to-one relationship between a policy and an identity" and is deleted when the identity is. The same page adds the rule of thumb: "If a policy could apply to more than one entity, it's better to use a managed policy."

Two consumers of the extra slots are legitimate. Partner and vendor products that require their own managed policy on an existing role now fit without a quota request — relevant to anyone integrating third-party tooling that assumes a role with an external ID, where AWS separately warns that the external ID "can be seen by anyone with permission to view the role" and is not treated as a secret. Genuine functional separation is the other: splitting one 6,144-character policy that has hit its size ceiling into several purpose-named policies is now cheaper than fighting the character limit.

One consumer is not legitimate. Attaching a broad AWS managed policy because there is now room for it is the opposite of what the quota change was justified by. The same discipline applies to non-human identities, which is where attachment sprawl usually starts — see our note on AI agent identity governance and on the cross-account gaps in AWS MCP server authentication.

India-specific considerations

Indian teams running multi-tenant delivery for offshore clients feel the session-policy cap first, because the pattern is so common: one delivery account assumes a role in each client account with a downscoped session. That design is bounded by 10 managed policy ARNs and 2,048 characters per session regardless of what the client's role now carries. The Digital Personal Data Protection Act, 2023 pushes in the same direction — a data fiduciary that cannot express its access boundary at session level is relying on the role's static attachment set to do the work, which is exactly the surface that just doubled. Where DPDP obligations apply, keep the tenancy boundary in the trust policy and the external ID, not in an attachment count.

What is still unknown

AWS has not published whether the 10-ARN session policy limit or the 6,144-character managed policy length are on any roadmap. It has not stated a combined evaluation limit for the characters across 20 or 25 attached managed policies — the per-policy figure is documented, the aggregate is not. It has not said whether the Managed policies per group ceiling of 10 will ever become adjustable. And the stale sample values in the GetAccountSummary references have not been corrected as of 21 August 2026.

FAQ

What did AWS change on 19 August 2026?

AWS Identity and Access Management increased the default quota for managed policies per role from 10 to 20. The change applied automatically to every existing IAM role with no action required, and reached all commercial AWS Regions, AWS GovCloud (US) and the China Regions on the same date.

Can I attach more than 20 managed policies to a role?

Yes, up to 25. The IAM and AWS STS quotas page lists managed policies per role with a default of 20 and a maximum of 25 in its table of automatically approved increases, and states that requests up to the maximum are approved and completed within a few minutes through Service Quotas.

Did the limit for IAM users and groups change too?

No. The AWS General Reference lists managed policies per user at a default of 10, adjustable to 20, and managed policies per group at 10 with adjustable marked as no. The group ceiling of 10 is therefore hard, and cannot be raised through a Service Quotas request at all.

Does this help if I downscope permissions with session policies?

No. The quotas page still states that you can pass a maximum of 10 managed policy ARNs when you create a session, and that the JSON document plus all ARN characters combined cannot exceed 2,048 characters. Neither figure changed on 19 August 2026, so session-based downscoping keeps its old ceiling.

How large can a single managed policy be?

Each customer managed policy can be at most 6,144 characters, and that limit cannot be increased. IAM does not count white space when measuring a policy against it. Inline policy totals differ by entity: 2,048 characters for a user, 10,240 for a role and 5,120 for a group.

How do I check the real quota in my own account?

Call the aws iam get-account-summary command in the account you care about. The returned SummaryMap includes the keys AttachedPoliciesPerRoleQuota, AttachedPoliciesPerUserQuota and AttachedPoliciesPerGroupQuota. Read the quota from that live response rather than from any documentation sample, because the samples in the API Reference and the AWS CLI 2.36.7 reference currently disagree with each other and with the published defaults.

What should I check in my own guardrails this week?

Look for any Config rule, policy-as-code lint, CSPM baseline or pipeline check that hardcodes ten attached managed policies per role. Those checks now pass while the permitted surface is twice as large. Compare against the account's reported quota instead of a literal, and decide deliberately whether your internal ceiling follows AWS up to 20.

How eCorpIT can help

eCorpIT runs IAM and cloud posture reviews for teams on AWS, mapping attached-policy sprawl, session-policy limits and detective controls against what an account actually enforces rather than what a documentation page claims. That work sits inside our multicloud security posture management practice, delivered by senior engineering teams and backed by CMMI Level 5 and ISO 27001:2022 certification. If your policy-as-code still asserts a limit of ten managed policies per role, we can audit the estate and reset the baseline. Talk to us at /contact-us/.

References

1. AWS IAM now supports 20 managed policies per role by default — AWS What's New, posted 19 August 2026.
2. IAM and AWS STS quotas — AWS Identity and Access Management User Guide.
3. AWS Identity and Access Management endpoints and quotas — AWS General Reference.
4. Managed policies and inline policies — AWS Identity and Access Management User Guide.
5. GetAccountSummary — AWS Identity and Access Management API Reference.
6. get-account-summary — AWS CLI 2.36.7 Command Reference.
7. Requesting a quota increase — Service Quotas User Guide.
8. Pass session tags in AWS STS — AWS Identity and Access Management User Guide.
9. Access to AWS accounts owned by third parties — AWS Identity and Access Management User Guide.
10. Recent Announcements feed — AWS, retrieved 21 August 2026.
11. Amazon Resource Names and IAM identifiers — IAM and STS character limits, AWS Identity and Access Management User Guide.

Last updated: 21 August 2026.