AWS Client VPN device posture: why switching to enforcement disconnects every session

Separate observing a policy from enforcing it

Device posture describes whether a device meets your organization's health and compliance requirements, such as encryption or security-risk conditions. AWS announced this capability on October 5, 2026. Administrators can use Cedar policies to decide which combinations of devices, users and connections may connect.

AWS calls the monitoring-only setting shadow mode. It evaluates the policy and logs its decisions without blocking connections because of that policy. Existing certificate, SAML or Active Directory authentication and network authorization remain in effect; shadow mode does not disable them.

Switching to enforcement is a separate action. AWS states that it disconnects every active session on that endpoint, including sessions from compliant devices. Shadow mode helps reveal unintended denials, but you still need to arrange for users to reconnect when you enforce the policy.

Check the client, provider and operating system first

You can configure device posture on an existing or new Client VPN endpoint. Each device needs the AWS provided client 6.2.0 or later and an installed, configured device trust provider. OpenVPN compatibility alone is insufficient: third-party OpenVPN clients do not support device posture.

AWS currently lists these combinations: CrowdStrike on macOS and Windows; Jamf on macOS; and JumpCloud on macOS, Windows and Ubuntu. Ubuntu support does not establish support for every Linux distribution, and one provider's operating-system coverage does not apply to the others.

You also need an account with the relevant provider and its configuration on every device. Health information arrives in the provider's signed token. AWS does not operate these providers or independently verify device health; administrators remain responsible for provider configuration, policy conditions and device compliance requirements.

Prepare the endpoint configuration and readable logs

When creating or modifying the endpoint, configure DevicePostureOptions with Enabled set to true and one or more entries in TrustProviders. Follow the selected provider's documentation for its type, TenantId and other settings so the endpoint can validate tokens sent by devices.

AWS's configuration example enables connection logging and sets IncludeAuthorizationPolicyContext to true. Confirm that you can read the relevant logs before observing your policy. Test policy uses connection logs to load decisions and their context.

Use describe-client-vpn-endpoints and inspect DevicePostureOptions in the response to confirm the registered providers. Then check the provider configuration and AWS client version on each device. A populated endpoint setting does not establish that device configuration is complete.

What does Test policy use as its input?

Cedar is a policy language for expressing allow and deny conditions. Client VPN evaluates the combination of a device token, the authenticated user's identity and connection details. Inspect the fields the provider actually supplies before writing conditions that depend on them.

Open the Amazon VPC console, select the endpoint ID under Client VPN endpoints, and choose Test policy on the Authorization tab. This test uses real context from connection logs, rather than a synthetic device sample whose values you can freely change.

Set the required Authorization decision filter to select the most recent allow or deny decision from the logs. Device identifier, User and Operating system are optional filters. Choose Search connections to load the provider's trust context, the user identity context and the current Cedar policy.

Review the context, edit the Cedar policy, and choose Test policy to evaluate it against that input. Trust and identity contexts are static and read-only; you cannot change their values here. A test helps check whether conditions express your intent, but does not establish that they are already enforced across every device.

Attach the policy in shadow mode and inspect both decisions

The documented shadow-mode procedure attaches a policy with modify-client-vpn-endpoint-authorization-policy and explicitly sets --shadow-mode enabled. Use get-client-vpn-endpoint-authorization-policy to confirm the attached policy afterward. Your local policy file alone does not prove the endpoint is using it.

Inspect allow and deny decisions in connection logs. Check both whether eligible devices would be denied and whether devices you intend to reject would be allowed. This stage logs device-policy decisions without interrupting connections because of those decisions; existing authentication and access rules still constrain users.

For example, suppose an organization requires device encryption before access. This is an illustrative scenario that has not been executed. Inspect the provider's actual encryption-related fields, then evaluate representative connections in shadow mode. If a field is missing, resolve the provider configuration or policy assumption before enforcing the rule.

Who disconnects, and when are sessions checked again?

Once shadow-mode results meet your expectations, the documented procedure sets shadow mode to disabled. Client VPN disconnects every active session on the endpoint both when you make that switch and when you add or update a Cedar policy while shadow mode is disabled. Notify connected users and schedule a reconnect window.

Under enforcement, users complete their existing authentication and the AWS client obtains a device token before establishing the connection. Client VPN validates the token and evaluates the policy. A denied request never establishes a connection; the client displays Authorization policy evaluation failed. Start this investigation separately from troubleshooting a resource that is unreachable after a successful VPN connection.

Active sessions are re-evaluated every five minutes against the most recent token. If a device no longer meets the policy requirements, Client VPN ends that session; this is not a check every second. The AWS client refreshes tokens independently on its own schedule, so the five-minute interval is not a deadline for refreshing provider health signals.

If a device stops supplying tokens, Client VPN evaluates against the last received token for up to 15 minutes, then drops it. That is a token-reuse limit, not a guaranteed access grace period. It also does not establish an exact disconnect time for every device; the available context and policy still matter.

No feature surcharge does not make the VPN service free

The announcement says device posture has no additional feature charge and is available in all AWS Regions where AWS Client VPN is available. This does not restrict international readers to the United States or add Client VPN to an otherwise unsupported region. Confirm service availability in the region you actually use.

Client VPN endpoint associations and VPN connections still incur hourly charges, and applicable data transfer, CloudWatch logging and other costs need separate review. Provider accounts and device-management requirements also remain. No feature surcharge is not a promise that the VPN or third-party services are free.

Before rollout, confirm supported clients and device providers, readable logs and real context, the decisions observed in shadow mode, and a reconnect plan for the enforcement switch. These steps are based on public AWS documentation and have not been executed on a real VPN endpoint; they are not a record of successful validation for any organization.