How to Manage AWS Zero Trust Security Using MFA, Service Control Policies and GuardDuty?

Setting up Zero Trust in AWS is the first step. Managing it requires ongoing attention as users join, accounts are added, credentials remain active, and permissions change over time.

Most AWS security gaps appear after the initial setup. A developer receives temporary administrator access that is never removed. An access key created for a project six months ago remains active. A new AWS account is added to the organization without GuardDuty enabled. A Service Control Policy that should restrict high-risk actions was never created.

These gaps can remain unnoticed until a security incident occurs.

This guide covers three controls used to manage AWS Zero Trust security: MFA for all users and accounts, Service Control Policies that establish organization-level guardrails that individual accounts cannot bypass, and GuardDuty monitoring that keeps threat detection aligned with changes to AWS accounts, users, and applications.

Managing Zero Trust Security After Initial Setup

Zero Trust is not a one-time setup. Every change in AWS, including new accounts, new team members, and new applications, can create gaps in access controls if they are not reviewed and managed properly.

Common ways Zero Trust controls develop gaps over time:

The three controls in this guide address these situations directly.

Require MFA for All IAM Identity Center Users

MFA is one of the most important protections against stolen credentials. If someone obtains a password, they may be able to sign in to AWS if MFA is not enabled.

MFA adds an additional verification step before access is granted. AWS now requires MFA for root users in all account types. The same requirement should apply to every user accessing AWS through IAM Identity Center.

Go to: IAM Identity Center → Settings → Authentication → MFA .

Set the following:

Why SMS MFA Should Be Avoided: SMS-based MFA is not recommended for a Zero Trust security model. SIM-swap attacks and message interception can give attackers access to one-time passcodes sent to a phone number. FIDO2 security keys and authenticator apps provide phishing-resistant authentication and are the preferred MFA methods.

Go to: IAM Identity Center → Permission sets → Select administrator permission set → Inline policy.

Add the following condition to your permission set inline policy:

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}

This blocks all actions if MFA was not used during sign-in, even if the permission set includes those actions.

Go to: IAM Identity Center → Users.

Review each user’s MFA devices. Users without MFA registered should be notified and given a short window, typically 5 to 7 days, to register a device before MFA becomes mandatory.

Apply Service Control Policies to Protect Organization-Wide Controls

Service Control Policies (SCPs) are used at the AWS Organizations level. They specify which actions can or cannot be performed within accounts in the organization, including actions by account administrators and root users in member accounts.

SCPs do not grant permissions. They set the maximum level of access available within an account. Even if an IAM policy in a member account permits an action, an SCP can still block it.

This makes SCPs an important control for preventing Zero Trust security settings from being disabled or bypassed at the account level.

Step 1: Enable Service Control Policies

Go to: AWS Organizations → Policies → Service control policies → Enable.

Once enabled, a default FullAWSAccess SCP is applied to all accounts. This permits all actions by default. You then add deny-based SCPs on top of this to restrict specific actions.

Step 2: Create an SCP to Prevent Disabling GuardDuty

This SCP prevents any user or role in a member account from disabling GuardDuty, deleting findings, or removing the GuardDuty administrator account relationship.

Go to: AWS Organizations → Policies → Service control policies → Create policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount",
        "guardduty:StopMonitoringMembers",
        "guardduty:UpdateDetector"
      ],
      "Resource": "*"
    }
  ]
}

Step 3: Create an SCP to Block Long-Term Access Keys

This SCP prevents the creation of new IAM users with long-term access keys in all accounts.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:CreateAccessKey"
      ],
      "Resource": "*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-south-1",
            "us-east-1"
          ]
        }
      }
    }
  ]
}

Go to: AWS Organizations → AWS accounts → Select OU or account → Policies → Attach.

Attach SCPs to Organizational Units rather than individual accounts where possible. New accounts added to an OU automatically inherit the correct guardrails.