VPN clients live deep in the operating system, which makes them the least forgiving software on Windows on ARM. Cisco AnyConnect on a Snapdragon laptop can fail in ways regular apps never do: installers that roll back, virtual adapters that never appear, connections that drop under load. Unlike a chat app, a VPN driver cannot simply run translated and hope for the best — it must integrate with the ARM64 network stack directly. VPN clients run as kernel drivers, not ordinary apps — they cannot be emulated into working, which is why the ARM64 build is a hard requirement rather than a recommendation.

The single most important fact: you need the ARM64 build of AnyConnect, ideally the version your IT department certifies. This is stricter than the general VPN not working on Windows on ARM situation, where protocol-level workarounds sometimes suffice. If your machine also shows Recall snapshot storage issues , treat that as unrelated housekeeping. And when Live Captions font size needs adjusting for your workflow, that is a separate accessibility tweak.

Below: getting the right AnyConnect build, fixing installs, stabilizing connections, and the fallback options when AnyConnect will not cooperate. Each fix respects managed-device realities — some steps need your IT team.

Why this happens

  • x64 AnyConnect on ARM64 network stack: The x64 VPN driver cannot bind properly to ARM64 networking, causing install failures or phantom adapters. VPN filter drivers must bind to the ARM64 network stack at kernel level; translated drivers simply cannot attach.
  • Outdated AnyConnect version: ARM64 support and Windows 11 24H2 compatibility arrived in specific releases; older ones predate both. ARM64 support and current Windows compatibility landed in specific AnyConnect releases — older builds predate both.
  • Organization blocking ARM clients: Some VPN headends fingerprint clients and reject unrecognized ARM64 builds. Headend policies sometimes whitelist client fingerprints, and ARM64 builds may not be on the list yet.
  • Certificate store issues: Machine certificates provisioned for x64 images may not transfer cleanly. Machine certificates issued during x64 imaging may not validate correctly on the ARM64 network stack.
  • Conflicting VPN or security software: Multiple VPN clients fight over the same virtual adapter and routing tables. Each VPN client installs filter drivers; two clients means competing filters and corrupted routing tables.
  • Windows update breaking the driver: Feature updates can invalidate the VPN driver’s signature or compatibility until Cisco updates. Feature updates can invalidate driver signatures, leaving a previously working client suddenly broken.

How to fix it

Work through these in order — diagnose first, then act.

Fix 1: Install the ARM64 AnyConnect build

Non-negotiable for VPN drivers: native architecture or nothing.

  1. Ask your IT department for the certified ARM64 AnyConnect installer.
  2. Uninstall any existing AnyConnect completely first.
  3. Install the ARM64 package with administrator rights.
  4. Confirm the virtual adapter appears in Device Manager without warnings.
  5. Test a connection to your organization’s VPN headend.

Fix 2: Clean up conflicting VPN software

Two VPN drivers on one machine is a recipe for routing chaos.

  1. Uninstall other VPN clients you no longer need.
  2. Remove stale virtual adapters from Device Manager.
  3. Reset the Windows network stack if routing looks corrupt.
  4. Restart and reinstall AnyConnect cleanly afterward.
  5. Keep exactly one VPN client installed going forward.

Fix 3: Fix certificate and profile issues

Auth failures after a good install usually live in certificates or profiles.

  1. Reimport your organization’s VPN profile from IT.
  2. Check that machine certificates are present and valid.
  3. Verify the system clock — skewed time breaks certificate validation.
  4. Test with a fresh profile rather than a migrated one.
  5. Ask IT to confirm your account is provisioned for VPN access.

Fix 4: Stabilize dropping connections

Drops under load point at power management or driver maturity.

  1. Disable Wi-Fi power saving in the adapter’s Device Manager properties.
  2. Set the VPN to reconnect automatically on drop.
  3. Test on both Wi-Fi and wired connections to isolate the medium.
  4. Update to the latest AnyConnect release for driver fixes.
  5. For network troubleshooting references, see Microsoft’s Windows support .

Fix 5: Handle post-update breakage

Feature updates and VPN drivers have a rocky history; a routine exists for it.

  1. After any Windows feature update, check AnyConnect’s version against Cisco’s compatibility list.
  2. Reinstall AnyConnect if the virtual adapter shows warnings.
  3. Ask IT whether a newer certified build is available.
  4. Use the built-in Windows VPN client temporarily if protocols allow.
  5. Document the working combination for the next update cycle.

Fix 6: Use fallback access methods

When AnyConnect cannot be made to work, business continuity matters more than the client brand.

  1. Ask IT for an IKEv2 profile for the native Windows VPN client.
  2. Check whether your organization offers a browser-based VPN portal.
  3. Use remote desktop to an x64 machine as a temporary bridge.
  4. Keep AnyConnect updated in the background for when support lands.
  5. Report ARM64 gaps to IT so they prioritize certification.

Fix 7: Verify split tunneling and DNS behavior

Some AnyConnect problems only appear after connection — intranet reachable but internet dead, or hostnames resolving wrongly. These are split-tunneling and DNS symptoms, governed by profiles your IT department controls. Knowing how to describe them precisely gets you a faster fix from IT than a vague VPN is broken report ever will.

  1. Connect and test both intranet and internet resources.
  2. Note exactly which destinations work and which fail.
  3. Check which DNS servers are assigned while connected.
  4. Screenshot the AnyConnect statistics panel for IT.
  5. Ask IT whether your profile intends full or split tunneling.

Closing

Cisco AnyConnect on ARM64 Windows is entirely workable — provided you run the ARM64 build your IT team certifies and keep it aligned with Windows updates. VPN drivers leave no room for emulation shortcuts, so get the native client, clear out conflicts, and keep a fallback access method documented for update season. Document your working client version alongside each Windows feature update — that pairing is the knowledge that makes the next update season boring instead of stressful.

Frequently asked questions

Does Cisco AnyConnect support Windows on ARM?
Cisco has added ARM64 support to recent AnyConnect releases. Older x64-only versions may install under emulation but VPN kernel drivers are far less forgiving than apps — always get the ARM64 build from your IT department or Cisco.
Why does AnyConnect install but fail to connect?
Common causes are an emulated VPN driver that cannot bind to the ARM network stack, certificate issues, or the organization’s VPN headend blocking ARM clients. Check with IT whether ARM64 clients are explicitly allowed.
Can I use the built-in Windows VPN client instead?
Sometimes. If your organization supports standard protocols like IKEv2, the native Windows VPN client works on ARM without Cisco’s software. Ask IT for the manual configuration profile.
Will AnyConnect work after a Windows feature update?
Major updates occasionally break VPN drivers until Cisco ships a compatible release. Keep AnyConnect updated and check Cisco’s release notes after each Windows feature update.