NEW: The State of AWS Security 2026 - Free WhitepaperFree AWS Security Whitepaper

AWS Verified Access Security

NETWORKING

AWS Verified Access provides secure access to corporate applications without requiring a VPN. It evaluates each access request in real time against Cedar policies, using identity and device posture data from configured trust providers.

MEDIUM

Risk Level

Regional

Scope

Inst/Grp/EP/TP

Key Components

Cedar

Policy Language

📋Service Overview

Core Components

Verified Access Instance (top-level resource), Trust Provider (identity via IAM Identity Center/OIDC or device posture via CrowdStrike/Jamf/JumpCloud), Group (collection of endpoints sharing a Cedar policy), and Endpoint (single application: load-balancer, network-interface, rds, cidr).

Attack note: Compromising Verified Access means bypassing zero-trust enforcement entirely. Modifying group or endpoint policies grants access to every protected application.

Cedar Policy Model

Cedar policies default to implicit deny. Group-level policies are inherited by all endpoints. Endpoint-level policies are evaluated in addition to the group policy. An overly broad permit at the group level with no endpoint-level restrictions grants access to all endpoints in that group.

Attack note: A blanket "permit(principal, action, resource);" at the group level with no conditions allows any authenticated user to access all endpoints in the group.

Security Risk Assessment

LowMediumHighCritical

6.5

Risk Score

Verified Access is a protective control, not a data store. The primary risk is misconfiguration that weakens or bypasses access enforcement. Compromise of the trust provider or overly permissive Cedar policies can expose all protected applications.

⚔️Attack Vectors

Trust Provider Abuse

•Compromise OIDC identity provider to issue valid tokens
•Register a rogue device trust provider with fabricated data
•Exploit misconfigured OIDC scopes to elevate membership
•Steal or replay user session tokens
•Target IdP admin console to add attacker-controlled users

Policy and Configuration Manipulation

•Modify group policy to blanket permit statement
•Disable endpoint policy (--no-policy-enabled)
•Create new endpoint in permissive group for sensitive app
•Attach attacker-controlled trust provider to instance
•Delete endpoint to force fallback to less secure access

⚠️Misconfigurations

Policy Weaknesses

•Group policy with no conditions (permit all authenticated)
•Endpoint policy not enabled (PolicyEnabled: false)
•Cedar checks identity but ignores device posture
•Policy references non-existent trust provider context key
•No endpoint-level policy refinement across group

Operational Gaps

•Access logging not enabled on the instance
•OIDC issuer URL misconfigured or deprecated
•No device trust provider attached (identity-only)
•No tags or naming convention for audit
•Network-interface endpoints exposed to broad segments

🔍Enumeration

List Verified Access Instances

aws ec2 describe-verified-access-instances

List Trust Providers

aws ec2 describe-verified-access-trust-providers

List Verified Access Groups

aws ec2 describe-verified-access-groups

List Verified Access Endpoints

aws ec2 describe-verified-access-endpoints

Get Group Policy (Cedar)

aws ec2 get-verified-access-group-policy \
  --verified-access-group-id vagr-0dbe967baf14b7235

Check Logging Configuration

aws ec2 describe-verified-access-instance-logging-configurations \
  --verified-access-instance-ids vai-0ce000c0b7643abea

📈Privilege Escalation

Key Escalation Actions

•ec2:ModifyVerifiedAccessGroupPolicy - blanket permit on group
•ec2:ModifyVerifiedAccessEndpointPolicy - weaken/disable endpoint policy
•ec2:CreateVerifiedAccessEndpoint - add sensitive resource to permissive group
•ec2:AttachVerifiedAccessTrustProvider - attach attacker-controlled provider
•ec2:CreateVerifiedAccessTrustProvider - register rogue OIDC issuer

Trust Provider Exploitation

•Compromise OIDC provider for token issuance
•Fabricate device posture via rogue trust provider
•Modify OIDC scopes to gain group membership
•Replay stolen session tokens
•Chain: rogue provider + blanket permit = full access

Key insight: ModifyVerifiedAccessGroupPolicy is the most critical permission — it can replace Cedar policies to grant blanket access to all endpoints in a group.

🔗Persistence

Persistence Mechanisms

•Attach attacker-controlled trust provider
•Modify Cedar policy to permit attacker identity
•Create hidden endpoint to sensitive internal resource
•Disable access logging to hide activity
•Add attacker users to authorized IdP groups

Evasion Techniques

•Disable access logging before exploitation
•Use legitimate IdP tokens with elevated claims
•Modify endpoint policy rather than group (less visible)
•Blend access with normal application traffic
•Target endpoints without endpoint-level policies

🛡️Detection

CloudTrail Events to Monitor

•ModifyVerifiedAccessGroupPolicy - policy changed
•ModifyVerifiedAccessEndpointPolicy - endpoint policy changed
•CreateVerifiedAccessTrustProvider - new provider registered
•AttachVerifiedAccessTrustProvider - provider attached
•DeleteVerifiedAccessEndpoint - endpoint removed

Access Log Signals

•Unusual access patterns from new IP addresses
•Access from devices with unknown posture data
•Requests from trust providers not in inventory
•Spike in denied access attempts
•Access to endpoints from unexpected user groups

💻Exploitation Commands

Get Endpoint Policy (Cedar)

aws ec2 get-verified-access-endpoint-policy \
  --verified-access-endpoint-id vae-066fac616d4d546f2

Describe Logging Configuration

aws ec2 describe-verified-access-instance-logging-configurations \
  --verified-access-instance-ids vai-0ce000c0b7643abea

📜Verified Access Policy Examples

✗Dangerous - Blanket IAM Permit

{
  "Effect": "Allow",
  "Action": [
    "ec2:ModifyVerifiedAccessGroupPolicy",
    "ec2:ModifyVerifiedAccessEndpointPolicy",
    "ec2:CreateVerifiedAccessTrustProvider",
    "ec2:AttachVerifiedAccessTrustProvider"
  ],
  "Resource": "*"
}

Grants unrestricted ability to rewrite Cedar policies and attach arbitrary trust providers, allowing an attacker to bypass all Verified Access controls.

✓Secure - Scoped Read-Only for Auditors

{
  "Effect": "Allow",
  "Action": [
    "ec2:DescribeVerifiedAccessInstances",
    "ec2:DescribeVerifiedAccessGroups",
    "ec2:DescribeVerifiedAccessEndpoints",
    "ec2:DescribeVerifiedAccessTrustProviders",
    "ec2:GetVerifiedAccessGroupPolicy",
    "ec2:GetVerifiedAccessEndpointPolicy",
    "ec2:DescribeVerifiedAccessInstanceLoggingConfigurations"
  ],
  "Resource": "*"
}

Permits enumeration and policy review without the ability to modify any access control configuration.

✗Dangerous - Cedar Group Policy (No Conditions)

permit(principal, action, resource);

Allows any authenticated user from any trust provider to access all endpoints in the group, regardless of group membership, device posture, or any other attribute.

✓Secure - Cedar with Identity and Device Posture

permit(principal, action, resource)
when {
  context.idc.groups has "c242c5b0-6081-1845-6fa8-6e0d9513c107" &&
  context.jamf.risk == "LOW"
};

Requires the user to be in a specific IAM Identity Center group AND have a Jamf-assessed low-risk device before access is granted.

🛡️Defense Recommendations

📝

Enable Access Logging on Every Instance

Send Verified Access access logs to CloudWatch Logs, S3, or Kinesis Data Firehose for audit and incident response.

aws ec2 modify-verified-access-instance-logging-configuration \
  --verified-access-instance-id vai-0ce000c0b7643abea \
  --access-logs S3={Enabled=true,BucketName=my-va-logs-bucket,Prefix=verified-access/}

📱

Attach Both Identity and Device Trust Providers

Never rely on identity alone. Attach at least one device trust provider (CrowdStrike, Jamf, or JumpCloud) to enforce device posture checks.

🔒

Write Restrictive Cedar Policies at Both Levels

Use group-level policies for broad requirements (identity group membership) and endpoint-level policies for application-specific conditions (MFA, device compliance).

🔐

Restrict IAM Permissions for Modifications

Limit ec2:ModifyVerifiedAccess*, ec2:CreateVerifiedAccess*, and ec2:AttachVerifiedAccessTrustProvider to a small set of administrators. Use SCPs to prevent unauthorized changes.

🔔

Monitor CloudTrail for Policy Changes

Set up alarms for ModifyVerifiedAccessGroupPolicy, ModifyVerifiedAccessEndpointPolicy, CreateVerifiedAccessTrustProvider, AttachVerifiedAccessTrustProvider, and DeleteVerifiedAccessEndpoint.

🔍

Validate Trust Provider Configuration Regularly

Audit that OIDC issuer URL, client ID, and scopes point to your organization's IdP. Verify device trust provider integrations are active and reporting current posture data.

AWS Verified Access Security Card • Toc Consulting

Always obtain proper authorization before testing