# Cover both IAM version actions when denying managed-policy changes

> Blocking SetDefaultPolicyVersion alone leaves a separate API path for creating and activating a new policy version.

- Canonical URL: https://update.dsesecurity.com/updates/cover-both-iam-version-actions-when-denying-managed-policy-changes/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:13:46+00:00
- Modified: 2026-10-20T18:34:29+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Blocking SetDefaultPolicyVersion alone leaves a separate API path for creating and activating a new policy version.

## Potentially affected

Review default-version change authority for customer managed IAM policies; customers cannot select the default for AWS managed policies or inline policies.

## DSE recommendation

DSE recommends reviewing both API paths when the requirement is to prevent a principal from changing an attached policy's effective permissions.

## Article

Blocking SetDefaultPolicyVersion alone leaves a separate API path for creating and activating a new policy version.

## Source facts

IAM CreatePolicyVersion can create a managed-policy version and set it as default. SetDefaultPolicyVersion can make an existing version the default. AWS says both actions must be denied to prevent a user from changing the default policy version. The default is the operative version for all users, groups and roles attached to that managed policy.

Source: [AWS Documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-versioning.html).

## Applicability

Review default-version change authority for customer managed IAM policies; customers cannot select the default for AWS managed policies or inline policies.

## DSE recommendation

DSE recommends reviewing both API paths when the requirement is to prevent a principal from changing an attached policy’s effective permissions. Inventory direct and inherited grants for the policy administrator and identify the exact customer managed policy resources within scope. Keep the proposed restriction targeted to that approved population rather than copying a deny across every policy merely to solve one access-control requirement. Have the policy owner review which attached identities would receive a newly selected default. Record the current default version before a controlled test and distinguish editing a saved document from making that document operative. Give policy-version administration an explicit owner and verify both paths whenever the restriction changes.

## Verification

Proposed verification: on a disposable customer managed policy, compare permission to select an existing default with permission to create a version using the set-as-default option. Then test the intended restriction on both actions and inspect the actual default version after each attempt. Retain identifiers and authorization outcomes without exercising this change against a production policy.

## Official reference

[AWS Documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-versioning.html). Reviewed October 20, 2026.

## Primary reference

- Name: AWS Documentation
- Authority: docs.aws.amazon.com
- URL: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-versioning.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Cover both IAM version actions when denying managed-policy changes,” DSE Security, https://update.dsesecurity.com/updates/cover-both-iam-version-actions-when-denying-managed-policy-changes/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.