AWS Verified Access: Trust Providers, Cedar Policies and Logging Explained

A VPN that admits a user to a whole network after one login is the opposite of zero trust, and AWS Verified Access exists to replace it with a decision on every request. Verified Access sits in front of private applications in your VPCs and evaluates each request against user identity and device posture before forwarding it. That only works if the trust providers, Cedar policies and logs are configured with care: a permissive group policy or an unlogged instance quietly recreates the flat network you were trying to remove. This guide explains how the components fit together, how policies are evaluated, which identities and roles control the service, and what to log and measure. It is written for cloud security engineers and identity architects running AWS workloads. For the general concept, see the ZTNA Guide.

This is an independent guide from NHI Mgmt Group, based on AWS's public documentation as of November 2026. It is not sponsored or reviewed by AWS. Product features change, so confirm settings against AWS's current documentation.

Key takeaways

• Default deny is real but fragile. A group or endpoint with no policy blocks every request, yet a single broad permit on a group opens every endpoint in it, so group design is a security decision.
• Group and endpoint policies are AND-ed. When both have a policy document, both must allow; one applicable forbid overrides any number of permit statements.
• Trust is only as good as the provider. Each instance takes one user-identity provider (IAM Identity Center or OIDC) and optionally several device providers (CrowdStrike, Jamf, JumpCloud), and policies can only test the claims those providers send.
• Non-HTTP access changes the threat model. TCP endpoints need the Connectivity Client on managed devices, with a configuration file that must come from IT, because a tampered file could point users at a phishing page.
• Logging is off until you turn it on. Access logs in OCSF format go to CloudWatch Logs, S3 or Data Firehose, and trust context is only included when you enable it on the ocsf-1.0.0-rc.2 log version.

How identity and access work in AWS Verified Access

AWS describes Verified Access as a way to reach applications without a VPN, evaluating every request in real time rather than once per session. Five building blocks make up a deployment.

The request flow is short: the user requests the application, Verified Access obtains trust data from the provider, evaluates it against the group policy and any endpoint policy, and forwards the request through the endpoint only if access is allowed. Every attempt is logged when logging is enabled.

User-identity trust providers

• IAM Identity Center: requires an AWS Organizations instance of Identity Center (not a standalone account instance), enabled in the same Region as the trust provider. AWS documents support for up to 1,000 groups per user. Trust data exposes user.user_id, user.user_name, user.email.address, user.email.verified and a groups object keyed by group ID (a UUID) with a group_name value. See the AWS IAM Identity Center Guide.
• OIDC: any standards-based OpenID Connect provider. You supply the issuer, authorisation, token and UserInfo endpoints, a client ID and client secret, and scopes (openid is the minimum). Verified Access reads trust data from the UserInfo endpoint, so the claims available to policy depend on the scopes you request. Providers created on or after 24 February 2025 also expose ID token claims under addition_user_context; older providers evaluate UserInfo data only.
• Redirect URIs: HTTP applications use https://application_domain/oauth2/idpresponse; TCP applications used through the Connectivity Client use http://localhost:8000. Register only the URIs you actually use.
• Session length: AWS documents a default session of one day for OIDC providers created on or after 24 February 2025 and seven days for older ones; if a refresh token is issued, its expiry sets the session duration. Recreating an old provider is the simplest way to pick up the shorter default.

Device trust providers

The documented device identity types are CrowdStrike, Jamf and JumpCloud. Each needs the tenant ID of the provider's tenant application, and a redirect URI of the form https://DeviceValidationDomain/oauth2/idpresponse added to the provider's allow list (the domain is shown on the endpoint's Details tab). Device signals such as the Jamf risk value let you require that the laptop is managed and healthy, not just that the user logged in.

Cedar policy evaluation

Verified Access policies are written in Cedar. AWS states that the scope (principal, action, resource) must be left undefined; all logic lives in the when clause, which reads trust data as context.<policy-reference-name>.<attribute>. A policy document allows access only if at least one permit applies and no forbid applies. AWS's own example combines identity and device:

permit(principal, action, resource)
when {
  context.idc.user.email.address.contains("@example.com")
  && ["LOW", "SECURE"].contains(context.jamf.risk)
};

• Prefer group IDs to email domains: an email suffix test admits every account in the domain, including contractors and service mailboxes. Testing context.idc.groups has "<group-id>" plus user.email.verified == true, as the AWS examples do, ties access to a governed group.
• Use forbid for hard stops: a forbid for high device risk, or for a "suspended" group, overrides any permit added later by another team.
• Remember what is not validated: Verified Access checks policy syntax at creation, not whether the attributes exist. A typo in a claim name produces a policy that never matches, which fails closed for permit and fails open for forbid.
• Attribute names with colons: use bracket notation, for example context.oidc["namespace:groups"].contains("finance").

Admin roles and privileged access

Verified Access is configured through the Amazon EC2 API (the console lives under the VPC console), so its administrative actions carry the ec2: prefix, for example CreateVerifiedAccessEndpoint. Anyone who can modify an instance, trust provider or policy can grant themselves access to every application behind it, which makes these permissions equivalent to firewall administration.

• Service-linked role: AWSServiceRoleForVPCVerifiedAccess (policy AWSVPCVerifiedAccessServiceRolePolicy) is created automatically by CreateVerifiedAccessEndpoint. It can create network interfaces in any subnet and modify security groups, but can only delete or modify interfaces tagged VerifiedAccessManaged=true. Do not reuse that tag on your own interfaces.
• Shared VPCs: in a shared subnet, the participant who creates an endpoint owns it and only they can modify it; the VPC owner cannot. Record ownership in your inventory so incident responders know who can change an endpoint.
• Human admins: administer through federated, short-lived roles. See the AWS IAM Policies and Roles Guide and the AWS Organizations and SCPs Guide.

Integrations, API tokens and service accounts

Verified Access is an identity-aware proxy, so it is full of machine credentials that deserve the same care as user accounts.

• OIDC client secret: the trust provider holds a confidential client secret for your IdP. Treat it as a secret with an owner and a rotation date, and restrict the IdP client to the redirect URIs Verified Access uses. See the Secrets Management Guide.
• Connectivity Client tokens: the client uses ephemeral OAuth access tokens stored in an encrypted local SQLite database and continuously re-authorises while connected. Adding the offline_access scope (which AWS recommends) means refresh tokens on devices, so your IdP's refresh token lifetime and revocation process now govern how quickly a lost laptop loses access.
• Device provider tenants: the CrowdStrike, Jamf or JumpCloud tenant becomes an authority over access. An attacker who can mark a device low risk in that console satisfies the device half of your policy.
• Backend service accounts: Verified Access authenticates the human, not the application session. Databases behind an Amazon RDS endpoint still need their own authentication, and the application should not trust that every request is pre-authorised. See the Database Credential and Access Security Guide.
• Automation identities: pipelines that deploy endpoints or policies hold ec2:*VerifiedAccess* permissions. Scope them to specific groups with tags and keep them out of developer laptops. See the AWS Access Keys Security Guide.

Logging and detection

Verified Access logs every access attempt it evaluates, in Open Cybersecurity Schema Framework (OCSF) format, once you configure a destination on the instance. AWS documents two log versions, OCSF 0.1 and OCSF 1.0.0-rc.2, and three destinations: CloudWatch Logs, Amazon S3 and Amazon Data Firehose. Including trust context copies the provider's claims into the log record's data field (it is null otherwise) and requires the ocsf-1.0.0-rc.2 version. Trust context contains personal data such as email addresses and group names, so apply retention and access controls to the log store.

Relevant ATT&CK techniques are T1133 External Remote Services (what Verified Access replaces and must not recreate), T1078.004 Cloud Accounts, T1528 Steal Application Access Token and T1539 Steal Web Session Cookie. See the AWS CloudTrail Guide.

Metrics that show it is working

• Coverage: percentage of private web applications served through Verified Access rather than VPN or public load balancers.
• Device-checked policies: share of groups and endpoints whose policy requires a device trust signal, target 100% for sensitive applications.
• Logging completeness: instances with logging enabled and trust context on, target 100%.
• Policy change lead time: unapproved policy or trust provider changes detected and reviewed within 24 hours.
• Offboarding latency: time from IdP disablement to first denied request for that user.

Hardening baseline

1. Design groups by sensitivity: follow AWS's guidance to group applications with similar security requirements, and keep high-value applications in their own groups so a group policy cannot spill over.
2. Use the IdP you already govern: prefer IAM Identity Center with group IDs, or an OIDC provider whose groups come from your joiner-mover-leaver process. Enforce phishing-resistant MFA at the IdP; Verified Access trusts whatever the IdP asserts.
3. Add device trust for anything sensitive: require a device provider claim in the group policy, and add a forbid for high-risk devices.
4. Write layered policies: a strict group baseline (verified email, governed group, managed device), plus endpoint policies that narrow to the specific team. Remember that without an endpoint policy, only the group policy is evaluated.
5. Configure endpoints narrowly: load balancers must be internal ALBs or NLBs in the same VPC; use one subnet per Availability Zone, security groups that allow only the application ports, and a public TLS certificate from AWS Certificate Manager whose common name matches the application domain (AWS specifies RSA 1,024 or 2,048 bit keys; choose 2,048). See the AWS Certificate Manager and Private CA Guide.
6. Use network CIDR endpoints sparingly: a CIDR endpoint exposes a range rather than an application. Keep ranges small and pair them with strict endpoint policies.
7. Manage the Connectivity Client: deploy signed installers through device management, place the exported ClientConfig- file in C:\ProgramData\Connectivity Client or /Library/Application Support/Connectivity Client, owned by Admin or root, and tell users never to accept configuration files from anyone else. Windows devices need TPM support and the WebView2 runtime.
8. Turn on logging and trust context at instance creation, to a central log account, and guard the configuration with an SCP.
9. Shorten sessions: recreate OIDC trust providers made before 24 February 2025 to get the one-day default, and align IdP refresh token lifetimes with your offboarding target.

Rollout and rollback: start with one low-risk web application in a pilot group, keep the VPN path open while users move, compare denied requests in the logs for two weeks, then tighten the policy and add device trust. Rollback is a DNS change back to the previous path, so keep the old route documented until the VPN is decommissioned.

Choosing an endpoint type

Small organisations with a handful of web applications usually get most of the value from load balancer endpoints and IAM Identity Center alone. Large organisations should add device trust, separate group ownership by business unit and manage policies through infrastructure as code. Note that Verified Access endpoints accept IPv4 traffic only and cannot be created in Local Zones.

Common misconfigurations

• A domain-wide permit on a shared group: email.address.contains("@example.com") on a group that holds payroll and wiki apps gives every employee and every compromised mailbox the same reach. This is the flat-network problem the NIST SP 800-207 Zero Trust Architecture Guide warns against.
• Endpoint policy assumed to restrict: teams add a tight endpoint policy but leave a permissive group policy elsewhere; or they rely on an endpoint policy that was never attached, so only the group policy applies.
• Misspelt claim in a forbid: because data is not validated, a forbid on context.jamf.rsk never fires and high-risk devices are admitted.
• Logging never enabled, or enabled without trust context: responders can see that access was allowed but not which device or groups justified it.
• Long sessions on old OIDC providers: seven-day sessions mean a disabled user can keep working for days unless the application re-checks.
• Remote access credentials treated as a solved problem: stolen remote access credentials remain a common way in, so pair Verified Access with phishing-resistant MFA and device trust at the new front door.

Framework mapping

For maturity planning, see the CISA Zero Trust Maturity Model Guide.

Practitioner checklist

• Inventory every Verified Access instance, trust provider, group and endpoint with an owner, including endpoints created by participants in shared VPCs.
• Confirm every group has a policy based on governed group IDs and verified email, not an email domain alone.
• Require a device trust claim for sensitive groups and add a forbid for high-risk devices; test it with a deliberately non-compliant device.
• Restrict policy, trust provider and logging changes to separate small roles, and alert on every change in CloudTrail.
• Enable access logging with trust context on the ocsf-1.0.0-rc.2 version for every instance, with retention and access controls suited to personal data.
• Rotate the OIDC client secret on a schedule and limit the IdP client to the Verified Access redirect URIs.
• Recreate OIDC trust providers created before 24 February 2025 and align refresh token lifetimes with offboarding targets.
• Deploy the Connectivity Client and its configuration file only through device management, with correct file ownership.
• Review network CIDR endpoints quarterly and replace them with application-level endpoints where possible.

Standards and references

• AWS: How Verified Access works
• AWS: Verified Access policy evaluation
• AWS: User-identity trust providers for Verified Access
• AWS: Verified Access Connectivity Client
• AWS: Verified Access logs
• NIST: SP 800-207 Zero Trust Architecture
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: External Remote Services

Related NHI Mgmt Group resources: ZTNA Guide · AWS IAM Identity Center Guide · AWS Security Guide · ZTNA Buyer's Guide