AWS just gave organizations a sharper tool for locking down the AWS Management Console. Resource-based policies and resource control policies now apply directly to AWS Sign-In. Administrators can deny sign-in attempts that originate outside approved IP ranges, on-premises networks, or specific VPCs.
The change arrived in mid-June 2026. AWS announced support for these controls on June 16. Two days later the detailed walkthrough appeared on the AWS Security Blog from Swara Gandhi and Rishi Tripathy.
Traditional IAM policies evaluate after a user reaches the sign-in page. These new controls sit earlier. They check the request before credentials are collected. Root users see the block before the password field even appears.
Evaluation happens twice. Pre-authentication covers the initial sign-in request. Post-authentication rechecks when the session requests fresh credentials through OAuth flows. Both phases must pass or access fails.
The policies target three actions: signin:Authenticate, signin:AuthorizeOAuth2Access, and signin:CreateOAuth2Token. Omitting any one leaves a gap in protection.
Network conditions rely on familiar keys such as aws:SourceIp, aws:SourceVpc, and aws:RequestedRegion. Identity conditions appear after authentication using aws:PrincipalArn. A service-specific key, signin:PrincipalArn, works in the pre-auth phase to exempt designated break-glass accounts.
Implementation starts simple for single accounts. Run put-resource-permission-statement with the corporate CIDR, VPC ID, requested region, and an excluded principal ARN. The command lives in us-east-1. AWS generates the JSON statements automatically.
Then enable enforcement with put-console-authorization-configuration on the target account ID. Until that step, the permission statements sit idle. CloudTrail records every evaluation, successful or denied.
Sample policy output shows paired DENY statements. One pair blocks non-corporate IPs and non-matching VPCs. The second pair ties the VPC to its home region because VPC IDs are not globally unique.
Organizations gain scale through RCPs. Attach the policy at the root, OU, or account level. It propagates automatically. The same GitHub sample repository that holds data-perimeter examples now includes a sign-in console RCP template.
Layering with existing perimeter tools
These sign-in controls complement AWS Management Console Private Access. Private Access routes traffic through VPC endpoints and lets endpoint policies restrict which accounts users can reach from inside the network. The new resource policies decide who can reach the sign-in endpoint at all.
Together they create a two-stage gate. First, only approved networks reach sign-in. Second, only approved accounts become visible once inside. Documentation on Console Private Access shows how to combine the features.
Both sets of controls fit the broader data-perimeter model AWS has promoted for years. Network perimeters now extend to the console entry point itself. Identity perimeters remain the job of IAM policies and SCPs.
Recent X posts confirm quick adoption signals. Security teams noted the feature blocks console access from personal devices or coffee-shop Wi-Fi without touching programmatic keys. One post highlighted the pre-auth block for root users as a notable improvement over prior options.
Cost stays at zero. The feature runs in every commercial region. Write operations target us-east-1 for global replication. Read operations work from any region.
Best-practice notes appear throughout the docs. Always define at least one excluded principal before enabling enforcement. Test from both allowed and blocked networks. Monitor CloudTrail for signin events. Review the consolidated policy with get-resource-policy before flipping the switch.
Edge cases matter. Federated sign-ins through SAML or OIDC still flow through these checks. IAM Identity Center sessions receive the same treatment. Programmatic access via access keys bypasses the controls entirely, as expected.
Lockout risk exists if network conditions shift or an RCP inadvertently denies the sign-in actions. The documentation explicitly warns to verify SCPs and RCPs first. Emergency access via an excluded principal mitigates that scenario.
Verification uses CloudTrail ConsoleLogin events. Successful attempts from allowed networks show the expected success record. Denied attempts from outside the perimeter produce failure events with the policy evaluation details.
Teams already running data-perimeter controls can extend the pattern. The same condition keys that protect S3 buckets or KMS keys now protect the console front door. Consistency across the stack reduces cognitive load for auditors and operators alike.
Early community reaction on LinkedIn and X focused on regulatory use cases. Financial services firms cited the corporate-network requirement as a direct match for compliance mandates. The feature removes the need for custom proxy solutions or browser extensions in many environments.
Future expansion looks likely. The underlying RCP framework already supports additional services. Sign-In joins the list alongside other perimeter-sensitive resources. Administrators should watch the AWS Organizations and Sign-In documentation for new condition keys or actions.
Start with a pilot account. Define the corporate network ranges. Add an emergency principal. Enable authorization. Test sign-in flows. Expand via RCP once comfortable. The mechanics are straightforward once the first policy is live.
WebProNews is an iEntry Publication