How to Enforce IMDSv2 on EC2 Instances (Security Hub EC2.8)

Security Hub control EC2.8 fails when an EC2 instance still accepts IMDSv1 (its HttpTokens setting is optional). To enforce IMDSv2, confirm the CloudWatch MetadataNoToken metric shows no IMDSv1 calls, run modify-instance-metadata-options with –http-tokens required and –http-endpoint enabled, then make required the Region default for new launches. No reboot is needed.

The command is the easy part. The real work is proving that nothing on the instance (an old SDK, a bootstrap script, a monitoring agent, a container) still calls the metadata service without a token, and stopping templates and Auto Scaling groups from bringing the finding back.

What the scanner is actually detecting

None of these tools touch the instance. They read its configuration through the AWS API, which is how cloud security posture management (CSPM) tools work in general.

EC2.8 checks a single attribute. It does not look at whether anything actually uses IMDSv1 or whether the instance has a role attached.

Real-world risk, stated honestly

IMDSv1 answers plain HTTP GET requests to 169.254.169.254 from anything on the instance. If an application has a server-side request forgery (SSRF) bug, or the instance works as an open reverse proxy, WAF or NAT device, an outside attacker can make it fetch /latest/meta-data/iam/security-credentials/ and return the temporary credentials of the instance role. Those credentials work from anywhere until they expire.

IMDSv2 adds three hurdles, per AWS documentation: a session token must first be requested with a PUT carrying a TTL header, PUT requests containing an X-Forwarded-For header are rejected, and the token response has an IP hop limit of 1 by default so it does not leave the instance.

It has limits. IMDSv2 does not stop an attacker who already runs code on the instance, or a request-forgery flaw that lets them set the HTTP method and headers. What stolen credentials can do depends on the role, so pair this fix with an audit of over-permissioned IAM roles. An instance with no role and no secrets in its user data carries less practical risk, even though the control still rates it High.

How to confirm it

List instances in a Region that still allow IMDSv1, then inspect one:

aws ec2 describe-instances --region us-east-1 
    --filters "Name=metadata-options.http-tokens,Values=optional" 
    --query "Reservations[*].Instances[*].[InstanceId]" --output text

aws ec2 describe-instances --instance-ids i-1234567890abcdef0 
    --query 'Reservations[].Instances[].MetadataOptions'

On the instance, a request without a token returns 200 while IMDSv1 is allowed and 401 once tokens are required:

# Linux
curl -s -o /dev/null -w "%{http_code}n" http://169.254.169.254/latest/meta-data/

# Windows PowerShell
try { (Invoke-WebRequest -Uri http://169.254.169.254/latest/meta-data/ -UseBasicParsing).StatusCode } catch { $_.Exception.Response.StatusCode.value__ }

Before changing anything, check who still uses IMDSv1. The MetadataNoToken metric in the AWS/EC2 namespace counts successful tokenless calls:

aws cloudwatch get-metric-statistics --region us-east-1 
    --namespace AWS/EC2 --metric-name MetadataNoToken 
    --dimensions Name=InstanceId,Value=i-1234567890abcdef0 
    --start-time 2026-09-12T00:00:00Z --end-time 2026-09-26T00:00:00Z 
    --period 86400 --statistics Sum

Pick a window that covers a reboot and any weekly or monthly jobs. If the sum is above zero, AWS’s open-source IMDS Packet Analyzer shows which process makes the IMDSv1 calls.

How to enforce IMDSv2

Existing instances

The change applies to a running instance immediately, without a restart. AWS requires –http-endpoint enabled whenever you pass –http-tokens.

aws ec2 modify-instance-metadata-options 
    --instance-id i-1234567890abcdef0 
    --http-tokens required 
    --http-endpoint enabled

With AWS Tools for PowerShell:

(Edit-EC2InstanceMetadataOption `
    -InstanceId i-1234567890abcdef0 `
    -HttpTokens required `
    -HttpEndpoint enabled).InstanceMetadataOptions

To cover every remaining instance in a Region once MetadataNoToken is clean:

REGION=us-east-1
for id in $(aws ec2 describe-instances --region "$REGION" 
    --filters "Name=metadata-options.http-tokens,Values=optional" 
    --query "Reservations[*].Instances[*].InstanceId" --output text); do
  aws ec2 modify-instance-metadata-options --region "$REGION" 
      --instance-id "$id" --http-tokens required --http-endpoint enabled
done

Instances that run containers

From a container, the metadata service is one extra network hop away. With a hop limit of 1, SDKs that require IMDSv2 may get no response, and others retry and fall back to IMDSv1 after a delay. Raise the limit to 2 only where containers genuinely need IMDS; AWS also suggests passing settings such as the Region to the container directly.

aws ec2 modify-instance-metadata-options 
    --instance-id i-1234567890abcdef0 
    --http-tokens required 
    --http-put-response-hop-limit 2 
    --http-endpoint enabled

Launch templates and Auto Scaling groups

Fixed instances do not stay fixed if an Auto Scaling group replaces them from an old template. Create a new version and make it the default:

aws ec2 create-launch-template-version 
    --launch-template-id lt-0abcdef1234567890 
    --source-version 3 
    --version-description "IMDSv2 required" 
    --launch-template-data '{"MetadataOptions":{"HttpEndpoint":"enabled","HttpTokens":"required"}}'

aws ec2 modify-launch-template 
    --launch-template-id lt-0abcdef1234567890 --default-version 4

Use the version number the first command returns. If a group pins a specific version, point it at the new one with aws autoscaling update-auto-scaling-group and its –launch-template option. Existing instances are not changed: modify them as above, or replace them with an instance refresh. Launch configurations (AutoScaling.3) cannot be edited, so create a new one or, better, move the group to a launch template. In CloudFormation, set MetadataOptions with HttpTokens: required and HttpEndpoint: enabled under LaunchTemplateData.

Region defaults and enforcement

Account defaults apply only to new launches and must be set in each Region. A hop limit of -1 means no preference (2 for AMIs with ImdsSupport v2.0, otherwise 1); set 2 if the account hosts containers.

aws ec2 modify-instance-metadata-defaults --region us-east-1 
    --http-tokens required --http-put-response-hop-limit -1

aws ec2 get-instance-metadata-defaults --region us-east-1

Once nothing depends on IMDSv1, enforce it. Launches configured for IMDSv1 then fail, and IMDSv1 cannot be re-enabled on instances that have it disabled:

aws ec2 modify-instance-metadata-defaults --region us-east-1 
    --http-tokens required --http-tokens-enforced enabled

Across an AWS Organization, Declarative Policies can set the same defaults centrally. The IAM or SCP condition key ec2:MetadataHttpTokens can block IMDSv1 launches, and ec2:RoleDelivery with value 2.0 rejects API calls made with credentials obtained through IMDSv1.

Lightsail instances

The EC2 commands do not cover Lightsail, which has its own call (no restart needed):

aws lightsail update-instance-metadata-options 
    --instance-name my-instance --http-tokens required

How to verify the fix and rescan

1. Rerun the describe-instances filter in every Region; it should return nothing. MetadataOptions should show HttpTokens: required and State: applied (it reads pending briefly after the change).
2. On the instance, the tokenless request should now return 401 while the token flow still works:

   TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" 
       -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
   curl -s -H "X-aws-ec2-metadata-token: $TOKEN" 
       http://169.254.169.254/latest/meta-data/instance-id

3. Watch MetadataNoTokenRejected for a few days. Once tokens are required, only this metric is emitted, and any count means something still tries IMDSv1 and is now failing.
4. EC2.8 is change triggered, so the control should flip to Passed after AWS Config records the new configuration. If it does not, confirm AWS Config is recording EC2 instances in that Region.

What can break and how to roll back

• Old AWS SDKs and CLI builds. IMDSv2 support starts at AWS CLI 1.16.289, Boto3 1.12.6 (botocore 1.13.25), AWS SDK for Java 1.11.678 and AWS Tools for Windows PowerShell 4.0.1.0. Older builds cannot fetch role credentials.
• Home-grown scripts. User data, cron jobs and agents that call curl or Invoke-RestMethod without a token start failing.
• Containers with hop limit 1, as described above.
• Enforcement. Old launch templates or pipelines that request IMDSv1 fail to launch.

# Re-allow IMDSv1 on one instance
aws ec2 modify-instance-metadata-options --instance-id i-1234567890abcdef0 
    --http-tokens optional --http-endpoint enabled

# If the Region enforces IMDSv2, that call fails until enforcement is off
aws ec2 modify-instance-metadata-defaults --region us-east-1 
    --http-tokens-enforced disabled

If get-instance-metadata-defaults shows ManagedBy: declarative-policy, change the organization policy instead. For launch templates, set the previous version back as the default. One change is permanent: setting imds-support v2.0 on an AMI cannot be undone, and AWS says the only reset is a new AMI from the underlying snapshot.

Common false positive reasons

• The metadata endpoint is disabled. With HttpEndpoint: disabled, IMDSv1 is unreachable, but EC2.8 only checks HttpTokens and still fails. Require tokens (the call needs the endpoint enabled) and then disable the endpoint again, or suppress the finding with a written justification.
• Stopped instances. The rule evaluates recorded configuration, so a stopped instance with optional tokens can still fail.
• The finding keeps coming back. An Auto Scaling group replaced your fixed instance from an old template version; the new instance has a new ID.
• Stale results. AWS Config is not recording EC2 instances in that Region, so the control never re-evaluates.
• Different scopes. A clean EC2.8 result does not clear Defender for Cloud’s Auto Scaling group or Lightsail recommendations.

FAQ

Does requiring IMDSv2 need a reboot?

No. AWS documents that the change takes effect on running instances immediately, without a restart.

Does setting the account default fix existing instances?

No. Region defaults and enforcement only affect new launches. Existing instances keep their setting until you modify or replace them.

Is a hop limit of 2 a security weakness?

It lets the token response travel one hop further, which is what containers need. Security Hub retired its control that flagged launch configurations with a hop limit above 1 (AutoScaling.4) in April 2024. Keep 1 on instances without containers that call IMDS.

Should I just turn IMDS off?

Only where nothing needs it. With the endpoint disabled, role credentials and user data are unavailable (disabled at launch, the SSH public key is not delivered either), and EC2.8 still checks HttpTokens.

Tracking this finding across many accounts

Across many accounts, the durable fix is Region defaults plus corrected launch templates, with the Security Hub control status as your evidence. If you use SITEY, a self-hosted vulnerability management platform that imports findings from 16 scanners, confirm your cloud posture source is among them first; duplicates are merged per scanner rather than across scanners, and its AI triage suggests false positives with evidence while a human decides. For on-instance work such as updating tools that still call IMDSv1, its AI-written, host-specific scripts run only after human approval and are deployed by its agents on Windows and Linux endpoints.

Sources

• AWS: Security Hub CSPM controls for Amazon EC2 (EC2.8)
• AWS: Transition to using Instance Metadata Service Version 2
• AWS: Modify instance metadata options for existing instances
• AWS: Configure instance metadata options for new instances
• Microsoft Learn: Compute security recommendations in Defender for Cloud