Strong AWS identities can still be used from an unexpected network after credentials, sessions, or devices are compromised. AccessGuard adds a separate organizational guardrail: for selected AWS member accounts or organizational units, requests subject to the policy must originate from approved public IP ranges or match an explicit exception.

AccessGuard is intentionally narrow. It complements IAM, MFA, Identity Center, device controls, and least privilege; it does not replace them.

What AccessGuard does

AccessGuard deploys into the customer’s AWS environment. A scheduled Lambda retrieves the customer’s FraudGuard allowlist, normalizes approved IPv4 and IPv6 addresses to CIDRs, and updates an AWS Organizations service control policy (SCP).

The deployment can:

  • attach the guardrail to the organization root or a selected OU;
  • begin in dry-run mode without changing organization policy;
  • preserve approved AWS service-to-service activity;
  • define break-glass exceptions by principal or tag;
  • emit logs and optional alerts when the policy denies a request;
  • rebuild the policy as the approved list changes.

The AccessGuard CloudFormation template is the implementation source of truth.

How the AWS control works

AWS describes SCPs as limits on the maximum permissions available to identities in member accounts. They do not grant permissions, and they do not affect users or roles in the organization management account. IAM and resource policies still determine what an identity is allowed to do inside the guardrail.

AccessGuard uses an explicit deny based on request-origin context. That means an identity with broad IAM permission can still be denied when its request does not meet the approved-source policy.

This separation is valuable: an attacker must have both usable AWS credentials and a permitted network path.

Important boundaries

IP-based AWS policy needs careful scoping.

  • aws:SourceIp applies to public source addresses and is not available when a request uses a VPC endpoint.
  • AWS service-to-service calls can have network context removed or changed. The deployment must preserve approved service principals when workloads depend on those calls.
  • SCPs do not protect identities in the management account. AWS recommends limiting management-account use to tasks that require it.
  • Service-linked roles and some AWS tasks are not restricted by SCPs.
  • A large allowlist can exceed organization policy size limits; approved egress should be consolidated wherever practical.

Review the current AWS SCP documentation and AWS global condition key guidance before enforcing the policy.

Best-fit environments

AccessGuard works best when administrative access already passes through stable corporate VPN, secure access service edge, bastion, or other controlled egress addresses. It is a poor fit when users routinely administer AWS from unpredictable networks and no dependable egress layer exists.

Good candidates include:

  • multi-account organizations with centralized administrative access;
  • regulated teams that must demonstrate a network boundary for cloud administration;
  • environments with contractors or privileged roles that should operate only through approved egress;
  • organizations that want one reviewable source policy across many member accounts.

Safe rollout

  1. Inventory human, automation, VPC endpoint, and AWS service-to-service access paths.
  2. Define the target OU; do not begin with the entire organization unless the scope is already well understood.
  3. Configure break-glass principals and verify management-account recovery.
  4. Deploy in dry-run mode and inspect the generated policy.
  5. Test from both approved and unapproved networks in a non-production member account.
  6. Verify critical service integrations and VPC endpoint workflows.
  7. Enable enforcement for the smallest target, monitor denials, then expand deliberately.
  8. Keep the CloudFormation stack and rollback procedure available.

When AccessGuard is not enough

An approved IP does not establish the identity, device health, or legitimacy of a request. Continue to use phishing-resistant MFA, short-lived credentials, least privilege, CloudTrail, anomaly detection, and incident response. AccessGuard adds defense in depth; it should never become the only control protecting a privileged role.

AccessGuard requires a deployment review because AWS architectures differ. Review the setup guide, then contact hello@fraudguard.io to validate fit and current plan eligibility.