AWS added a lock. OFFENSAI had five new ways to test it by that afternoon.
On June 16, 2026, AWS shipped new sign-in restrictions controls. Network-based restrictions on Console access, enforced at both sign-in and credential refresh. Genuinely useful hardening — the kind of feature your team will queue up for the Q3 compliance roadmap.
OFFENSAI had five new attack techniques in the graph by that afternoon.
Not the next sprint. Not after a researcher noticed. That afternoon.
What are AWS Console sign-in restrictions?
AWS Console sign-in restrictions are a new way to control where users can access the AWS Management Console from.
Instead of only relying on identity permissions, AWS now allows teams to apply network-based restrictions to Console sign-in using resource-based policies and resource control policies (RCPs). These policies can limit Console access to approved network locations, such as a specific VPC, VPC endpoint (VPCE), or source IP range.
At the account level, resource-based policies can define which networks are allowed to access the Console. At the organization level, RCPs can apply similar restrictions across multiple AWS accounts through AWS Organizations.
The important part: these restrictions are evaluated not only when a user first signs in, but also during credential refresh. That means access can be continuously checked against the policy instead of only being validated at the initial login.
RCPs are especially powerful because they act as organization-wide guardrails. They define the maximum available permissions for resources across accounts in an AWS Organization, which makes them useful for enforcing consistent Console access rules at scale.
In practice, this gives security teams a stronger way to say:
"Even if this identity has permission to use the Console, it should only be able to sign in from approved networks."
That is useful hardening. But like every cloud control, the real question is not only whether the restriction exists.
It is who can change it.
The overlooked risk: who can change the restriction?
Resource-based policies and resource control policies now let you lock AWS Management Console sign-in to specific VPCs, VPCEs, or IP ranges. Resource Control Policies (RCPs) push the same enforcement org-wide. Your security team enables this, checks the box, and moves on.
Here's what they didn't read closely in the announcement:
One of the policy input fields is called excludedPrincipal.
An attacker who can write to this policy doesn't need to remove the AWS sign-in restriction. They add one line — their identity, excluded. The policy stays enabled. Your SIEM sees a normal config update. The compliance dashboard stays green.
And they sign in from anywhere on earth.
That's not a theoretical edge case. That's the design of the API.
Five Techniques. One Afternoon.
5 attack paths that can bypass AWS Console sign-in restrictions
OFFENSAI's graph expanded the moment this service landed. Five new attack techniques — automatically staged, connected to their prerequisite conditions, and mapped against every environment where those conditions are currently met.
We'll name them. The rest lives in our offensive IP.
| Technique | What it tests | Why it matters |
|---|---|---|
| Enumerate Console Network Restrictions | Whether an identity can discover existing Console sign-in restrictions and their policy scope. | Attackers need to know where the boundary is before deciding whether to weaken, disable, or bypass it. |
| Weaken Console Sign-In Policy | Whether a principal can modify network conditions or add an excluded principal. | The policy can remain enabled while no longer applying to the attacker. |
| Disable Console Authorization Config | Whether a principal can turn off the authorization configuration. | A single configuration change can remove enforcement without touching every identity. |
| Remove Console Network Restriction | Whether an identity can remove the network condition from the enforcing policy. | Blunt but effective when stealth is not the attacker's priority. |
| Bypass Org-Level Console RCP | Whether management-account or delegated-admin access can weaken organization-wide enforcement. | One org-level change can affect multiple member accounts. |
Five techniques. One new attack surface. Ingested, connected, and live in the graph before most security teams had finished their Monday standup.
How to validate AWS Console sign-in restrictions
Enabling AWS Console sign-in restrictions is only the first step. The control is valuable, but it needs to be validated like any other security boundary.
Here is where security teams should start.
1. Inventory every account with Console authorization policies
Start by identifying which AWS accounts have Console sign-in restrictions configured.
This should include both account-level resource-based policies and organization-level resource control policies. The goal is to understand where the control exists, where it does not exist, and whether coverage is consistent across your AWS Organization.
A partial rollout can create a false sense of protection. One restricted account does not mean the organization is protected.
2. Identify who can write or update those policies
The restriction is only as strong as the identities allowed to change it.
Review every principal that can create, update, attach, detach, or delete Console authorization policies and RCPs. This includes direct IAM permissions, inherited permissions, administrative roles, CI/CD roles, break-glass roles, and delegated administrator accounts.
If an attacker compromises one of these principals, they may not need to break the restriction. They may only need to change who the restriction applies to.
3. Monitor changes to sign-in policies and RCPs
Treat changes to Console sign-in restrictions as high-signal security events.
Monitor for updates to resource-based sign-in policies, RCP changes, policy attachments, policy detachments, and authorization configuration changes. These events should not be treated as normal configuration noise, especially when they affect network conditions, excluded principals, or organization-wide enforcement.
A policy can remain enabled while becoming less effective.
4. Review excluded principals
Pay special attention to excluded principals.
Excluded principals are useful for recovery access and operational continuity, but they also create an obvious exception path. Review every excluded identity and ask:
- Is this principal still needed?
- Is it protected with strong controls?
- Can it be assumed by another identity?
- Does it have broader permissions than required?
- Would we detect if this principal were added, changed, or abused?
The safest exception is one that is rare, monitored, and tightly governed.
5. Test access from unauthorized networks
Do not assume the restriction works because the policy exists.
Test Console sign-in from outside the approved VPC, VPCE, or source IP range. Then test again with different identity types, including standard users, admin roles, break-glass roles, federated identities, and any excluded principals.
The expected result should be clear: authorized identities can sign in only from approved networks, while unauthorized network paths are blocked.
6. Validate organization-level RCP inheritance
For organization-wide enforcement, confirm that RCPs apply where you expect them to apply.
Review inheritance across organizational units, member accounts, delegated administrators, and management account behavior. Check for accounts that are intentionally or accidentally outside the policy scope.
This matters because attackers look for gaps in inheritance, not just gaps in individual account configuration.
7. Re-test after AWS Organizations or IAM changes
Console sign-in restrictions are not a one-time control.
Re-test whenever there are changes to AWS Organizations, IAM roles, permission boundaries, SCPs, RCPs, delegated administrator settings, identity federation, break-glass access, or CI/CD deployment roles.
A restriction that worked last month may not work after an org restructure, new admin role, or policy exception.
The practical question is not simply:
"Did we enable AWS Console sign-in restrictions?"
It is:
"Can anyone weaken, remove, exclude themselves from, or bypass those restrictions today?"
Why new AWS features might create new attack paths
Each new technique isn't a standalone finding. It's a new node in the attack graph.
New connections form. Paths that were previously dead ends now connect. An attacker who was two hops from a privilege escalation may now be one, because a new AWS capability just bridged the gap.
Attack chains compound. Every AWS release, every new IAM action, every new policy primitive. That's the design. That's also what makes it hard to stay ahead of manually.
What is OFFENSAI?
OFFENSAI is AI Cloud Security Testing. It continuously maps your AWS estate against a live knowledge base of attacker techniques, validates which paths are actually viable in your environment right now, and proves them.
What OFFENSAI Already Knows About Your Environment
This isn't a research blog. This is a live system OFFENSAI has and operates precisely.
The prerequisites for these five techniques, the IAM permissions, the org configurations, the policy states are observable. OFFENSAI maps your environment against the attack knowledge base continuously, so it knows which of these paths are viable in your AWS estate today, and can prove it.
The question is whether you do.
See what OFFENSAI can say about your environment →
Full technique details, prerequisite chains, and detection logic are available to OFFENSAI customers and authorized security partners.
FAQs
Can AWS resource control policies be bypassed?
Not through a vulnerability — through policy access. Anyone who can write to the resource control policy or resource-based policy can add an excludedPrincipal entry for their own identity. The restriction stays enabled for everyone except them, with no alert.
What did AWS change in Console sign-in on June 16, 2026?
AWS added support for resource-based policies and resource control policies (RCPs) on AWS Management Console sign-in, allowing teams to restrict access by VPCs, VPC endpoints, or IP ranges, enforced at sign-in and on every credential refresh.
Are AWS Console network restrictions enough to stop attackers?
No. AWS Console network restrictions raise the bar, but the control is only as strong as the policy that defines it, and that policy is itself writable. Without continuous validation of who can modify it, the AWS console restriction can be silently weakened while still appearing active.
What is attack path management for AWS?
Attack path management maps how identities, permissions, and misconfigurations chain together into viable routes to critical assets. For AWS, it models every new IAM action and policy primitive as a node, surfacing the paths an attacker could actually use right now.
How do new AWS features create new attack paths?
Each new AWS capability adds a node to the attack graph. New nodes create new connections, turning former dead ends into viable routes and shortening privilege-escalation chains. This is why attack surface compounds with every AWS release and is impractical to track manually.
What permissions should be monitored after enabling AWS Console sign-in restrictions?
Monitor any IAM or AWS Organizations permission that can create, update, attach, detach, delete, or weaken Console sign-in policies, resource-based policies, RCPs, excluded principals, or authorization configurations.
How do I test whether Console sign-in restrictions are working?
Test Console access from both approved and unapproved networks, using different identity types, and confirm that authorized users can sign in only from allowed VPCs, VPCEs, or source IP ranges.
What is excludedPrincipal in AWS Console sign-in restrictions?
excludedPrincipal is a policy field that exempts specific identities from Console sign-in restrictions, which is useful for break-glass access but risky if attackers can add themselves to the exclusion list.