Controlling console access with resource-based policies and resource control policies

AWS Sign-In supports resource-based policies and resource control policies (RCPs) to control access to AWS Sign-In. Use these policies to verify user identity and network location throughout AWS Management Console access – before, during, and after authentication. For root users, these policies validate network location and user identity before credential collection begins. Credentials can be entered only when access originates from expected networks.

AWS Sign-In resource-based policies:

Resource control policies (RCPs):

Both policy types verify access before authentication. This blocks principals from accessing the sign-in page from unexpected networks.

These policies do not replace IAM identity-based policies, which continue to apply.

AWS Sign-In resource-based policies and RCPs apply to the following authentication methods:

These controls do not apply to programmatic access using access keys (AWS SDKs or API calls signed with SigV4).

How AWS Sign-In evaluates resource-based policies

AWS Sign-In evaluates the applicable resource-based policies or resource control policies (RCPs) at two points during console access: before authentication (the pre-authentication phase) and after successful authentication (the post-authentication phase). Each evaluation checks the condition keys defined in your policy. The keys available depend on the phase and action. For details, see Supported condition keys.

After authentication, the evaluation also considers the principal's identity-based policies. An IAM policy that denies the relevant sign-in action can prevent the console session from being granted, even when network conditions are met.

Supported actions

AWS Sign-In resource policies (resource-based policies and RCPs) support the following actions:

Supported condition keys

AWS Sign-In supports the following condition keys in resource-based policies and resource control policies (RCPs). Use these keys to control console access based on network location and principal identity:

For detailed usage rules, operator compatibility, combination restrictions, and the availability matrix by action, see AWS Sign-In condition keys reference.

Getting started with console access control using resource policies

Prerequisites

Specify --region us-east-1 for all write operations on AWS Sign-In policies. AWS replicates policies globally from this Region. Read operations can target any Region.

Step 1: Create resource permission statements

Create permission statements that define your access controls. All write operations require --region us-east-1 (the AWS Sign-In service accepts policy changes only in this Region). The remaining parameters (--source-vpc, --source-ip, --requested-region, --excluded-principal) define the conditions in your policy. For example, --requested-region us-west-2 adds a condition restricting sign-in to the us-west-2 regional sign-in endpoint.

Example – Restrict access to corporate VPC:

aws signin put-resource-permission-statement \
  --source-vpc vpc-0abc123def456789 \
  --requested-region us-west-2 \
  --excluded-principal "arn:aws:iam::123456789012:user/EmergencyAdmin" \
  --client-token unique-request-id-12345 \
  --region us-east-1

Example – Restrict access to specific IP range:

aws signin put-resource-permission-statement \
  --source-ip "IP_ADDRESS" \
  --excluded-principal "arn:aws:iam::123456789012:role/BreakGlassRole" \
  --region us-east-1

Step 2: Enable console authorization configuration

The following step activates policy enforcement for the console sign-in process on your account or organization. Resource permission statements can be created at any time, but they are not evaluated until console authorization is enabled.

For standalone accounts:

aws signin put-console-authorization-configuration \
  --target-id <your-aws-account-id> \
  --region us-east-1

For AWS Organizations:

aws signin put-console-authorization-configuration \
  --target-id <your-aws-organization-id> \
  --region us-east-1

Verify the configuration:

aws signin get-console-authorization-configuration \
  --target-id <your-target-id> \
  --region <your-region>

Delete the console authorization configuration:

aws signin delete-console-authorization-configuration \
  --target-id <your-target-id> \
  --region us-east-1

Step 3: Verify your policy

List all permission statements:

aws signin list-resource-permission-statements \
  --max-results 50 \
  --region <your-region>

Retrieve the complete consolidated policy:

aws signin get-resource-policy \
  --region <your-region>

The get-resource-policy command returns the complete resource-based policy composed of all your permission statements. Review this policy to confirm it reflects your intended access controls before testing console access.

Regional availability

Console authorization APIs are available in all AWS commercial Regions. You can call these APIs from any Region where you operate.

Understanding the policy structure

AWS Sign-In policies contain two statements that protect different phases of the console sign-in flow:

Both statements are required because console sign-in uses OAuth 2.0, which flows through all three actions sequentially. A policy with only one statement leaves the other phase unprotected. signin:PrincipalArn supports root user, IAM user, and role principal types. aws:PrincipalArn supports all principal types (root user, IAM user, federated user, role).

Policy examples

Example 1: RCP with network perimeter and excluded principals

The following resource control policy (RCP) denies AWS Management Console sign-in from outside your corporate network across all accounts in your organization. Designated excluded principals are exempted for emergency access. Since VPC IDs are unique only within a Region, the policy includes a third statement that pins VPC-based access to the expected Region.

The EnforceNetworkPerimeterPreAuth statement uses signin:PrincipalArn to exempt excluded principals during the pre-authentication phase. The EnforceNetworkPerimeterPostAuth statement uses aws:PrincipalArn to exempt excluded principals after authentication. The EnforceSourceVPCRegion statement ensures the request Region matches the VPC Region, restricting access to the expected Region for the specified VPC.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceNetworkPerimeterPreAuth",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["signin:Authenticate"],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "signin:PrincipalArn": [
            "arn:aws:iam::111122223333:root",
            "arn:aws:iam::444455556666:root",
            "arn:aws:iam::777788889999:user/EmergencyUser",
            "arn:aws:iam::777788889999:role/OrgBreakGlassRole"
          ]
        },
        "NotIpAddressIfExists": {
          "aws:SourceIp": "<my-corporate-cidr>"
        },
        "StringNotEquals": {
          "aws:SourceVpc": "<my-vpc>"
        }
      }
    },
    {
      "Sid": "EnforceNetworkPerimeterPostAuth",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": [
            "arn:aws:iam::111122223333:root",
            "arn:aws:iam::444455556666:root",
            "arn:aws:iam::777788889999:user/EmergencyUser",
            "arn:aws:iam::777788889999:role/OrgBreakGlassRole"
          ]
        },
        "NotIpAddressIfExists": {
          "aws:SourceIp": "<my-corporate-cidr>"
        },
        "StringNotEquals": {
          "aws:SourceVpc": "<my-vpc>"
        }
      }
    },
    {
      "Sid": "EnforceSourceVPCRegion",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "signin:Authenticate",
        "signin:CreateOAuth2Token",
        "signin:AuthorizeOAuth2Access"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:SourceVpc": "<my-vpc>"
        },
        "StringNotEqualsIfExists": {
          "aws:RequestedRegion": "<my-vpc-region>"
        }
      }
    }
  ]
}

This policy:

Example 2: Resource-based policy for IP-based access with excluded principal

The following resource-based policy denies console access to all principals making requests from outside the specified IP range, with an excluded principal exempted. The policy contains two statements: a pre-authentication statement that uses the service-specific signin:PrincipalArn key, and a post-authentication statement that uses the global aws:PrincipalArn key.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": { "AWS": "*" },
      "Action": ["signin:Authenticate"],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "signin:PrincipalArn": "<excluded-principal-arn>"
        },
        "NotIpAddress": {
          "aws:SourceIp": "<my-corporate-cidr>"
        },
        "StringEquals": {
          "aws:ResourceAccount": "<my-aws-account-id>"
        }
      }
    },
    {
      "Effect": "Deny",
      "Principal": { "AWS": "*" },
      "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": "<excluded-principal-arn>"
        },
        "NotIpAddress": {
          "aws:SourceIp": "<my-corporate-cidr>"
        },
        "StringEquals": {
          "aws:ResourceAccount": "<my-aws-account-id>"
        }
      }
    }
  ]
}

This policy:

Best practices

Configure excluded principals for emergency recovery access

AWS recommends configuring at least one excluded user before enforcing console authorization policies in production. At the pre-authentication stage, the signin:PrincipalArn condition key exempts root user, IAM user, and role principals. At the post-authentication stage, the aws:PrincipalArn condition key exempts all principal types (root user, IAM user, federated user, role).

Excluded principals are optional, but omitting them increases the risk of account lockout if network conditions change unexpectedly or if policies are misconfigured.

Recommended excluded-principal configuration steps:

Maintain recovery access paths

In addition to the excluded principal described above, ensure alternative access methods are available in case console authorization policies block sign-in unexpectedly:

Test before production deployment

AWS recommends that you don't attach restrictive RCPs to the root of your organization without thoroughly testing the impact that the policy has on accounts. Instead, create an OU that you can move your accounts into one at a time, or at least in small numbers, to ensure that you don't inadvertently lock users out of key accounts.

Testing workflow:

Design with defense-in-depth

Use AWS Sign-In resource-based policies and resource control policies as one layer within a broader security strategy. AWS Sign-In policies restrict console access based on network location and principal identity. Combine them with other policy types to create comprehensive access controls:

Monitor and audit continuously

AWS CloudTrail automatically records all AWS Sign-In policy evaluations and configuration changes. View these events in CloudTrail Event history for up to 90 days. For longer retention, deliver events to Amazon S3 by creating a trail (see Creating a trail). For real-time alerting, create Amazon EventBridge rules that match AWS Sign-In events, configure your trail to deliver to a CloudWatch Logs log group for metric filter-based alarms, or forward events to your existing SIEM solution.

Use cases

Troubleshooting console access control

I cannot sign in due to network conditions in Sign-in resource-based policies

You may see one of the following error messages when access is denied by a AWS Sign-In policy:

If you see any of these errors and believe your access should be allowed, contact your AWS administrator. They can review CloudTrail logs for ConsoleLogin events with errorMessage "Authorization denied because of a resource-based policy" or "Authorization denied because of a resource control policy" to identify which policy statement denied access.

Possible causes:

Resolution:

For administrators diagnosing this issue:

I am locked out of my account after enabling console authorization

If you configured console authorization and can no longer access your account, you may not have configured excluded principals before enforcing the policy.

There are multiple paths to regain access, depending on your account type and available credentials.

Option 1: Use programmatic access (AWS CLI or SDK)

Console authorization policies apply only to interactive console sign-in. They do not apply to API requests signed with SigV4. If you have programmatic access (for example, existing access keys, a cross-account role), use it to call signin:DeleteConsoleAuthorizationConfiguration and remove the restricting policy. The credentials you use must have permission to call signin:DeleteConsoleAuthorizationConfiguration. The AWSSignInResourcePolicyManagement managed policy includes this permission. AWS recommends temporary credentials over long-term IAM user access keys. For member accounts, management account administrators can assume OrganizationAccountAccessRole in the member account to obtain temporary credentials. This role is not automatically created in accounts that were invited to join the organization.

aws signin delete-console-authorization-configuration \
  --target-id <your-aws-account-id> \
  --region us-east-1

Or delete specific permission statements:

# First, list statements to get the statement ID
aws signin list-resource-permission-statements \
  --region us-east-1

# Then delete the problematic statement
aws signin delete-resource-permission-statement \
  --statement-id <statement-id> \
  --region us-east-1

Option 2: Contact AWS Support

If you do not have programmatic access and cannot use the OrganizationAccountAccessRole for account access, contact AWS Support to initiate the lockout recovery process.

The recovery process works as follows:

The recovery portal link expires 72 hours after AWS Support shares it. If you do not complete recovery within that window, contact AWS Support to restart the process.

After regaining access:

Changes that I make are not always immediately visible

Policy changes replicate globally, but replication may take a few minutes.

Resolution:

aws signin get-resource-policy --region <your-region>

Common policy replication issues: