How the Atlas Reach Agent Connects to Atlas AVD

How the Atlas Reach agent on a Windows device connects to Atlas AVD: what it sends and how often, how it is secured, and what your network needs to allow.

The agent only connects out

The agent always starts the connection. It calls out over HTTPS (port 443) to your Atlas AVD address, the same address you sign in to. Nothing connects in to the device and no inbound ports are opened, so the agent works from behind NAT, home routers and VPNs without port forwarding.

How a device joins your tenant

  1. You install the agent with an enrollment token minted on the Enrollment tab of Atlas Reach. The token decides which tenant the device joins; the agent never chooses its own.
  2. On first start the agent swaps the token for its own device credential. The credential is stored encrypted on the device under C:\ProgramData\AtlasAVD\Agent, and the token is removed.
  3. The device appears on the Devices tab, waiting for approval unless Auto-approve enrolled devices is on.

What the agent sends

  • Health and performance: a sample every 60 seconds. Azure VMs send each sample straight away; other devices send them in batches every 5 minutes, or every minute while someone has the device open in Atlas.
  • Inventory: hardware, operating system, installed software and security posture, about once a day. When nothing has changed, the agent only confirms that.
  • Live work: remote sessions, scripts, software installs and other actions you start from Atlas travel over one secure connection the agent keeps open. This connection is also how Atlas knows the device is online, and the agent reconnects on its own if it drops.
  • Updates: once a day the agent asks whether a newer version is published, and installs it only after checking the download against a SHA-256 hash.

How the connection is secured

  • All traffic uses TLS, checked against the device's trusted certificates.
  • Each device has its own credential. Atlas uses it to place the device's data in its own tenant only, and revoking or deleting the device ends its connection straight away.
  • Optionally, you can pin your Atlas AVD certificate at install time so the agent refuses any other certificate.

What your network needs to allow

  • Outbound HTTPS (port 443) from each device to your Atlas AVD address. This includes a long-lived WebSocket connection, so a proxy or firewall must allow WebSocket upgrades and keep idle connections open.
  • Outbound HTTPS to the address agent updates are downloaded from, if you use automatic updates.
  • On Azure VMs, the Azure Instance Metadata Service (169.254.169.254), which the agent uses to identify the VM.
  • Only if you turn on Regional Relays or Direct Connections: the extra relay addresses or the direct-connection traffic those features use. Both are off by default.

If your firewall inspects TLS traffic and you have pinned your certificate, the agent refuses the inspected connection by design. Exclude your Atlas AVD address from TLS inspection.

Next steps