
We have begun rolling out Real-Time Agent Communication (RTAC) - Agent Commands for Webroot Business Agents. This enhancement replaces the existing 15-minute polling mechanism with a persistent real-time communication model, significantly improving command delivery speed and responsiveness.
What Is Changing
Today, Agent Commands are delivered using a polling mechanism that checks in every 15 minutes.
With Real-Time Agent Communication enabled:
- Agent Commands are delivered almost instantly
- Command execution latency is significantly reduced
- No workflow changes are required in the Console
- No configuration changes are required from MSPs or administrators
The feature will be automatically enabled as agents upgrade.
Agent Rollout Plan
The rollout will occur in phased waves to ensure platform stability and performance validation.
- Windows agents have already begun deploying and will continue rolling out in phases
- macOS agents will follow in the coming weeks
As endpoints upgrade to the latest supported agent version, Real-Time Agent Communication will automatically become active. No manual enablement is required.
How It Works

RTAC establishes a persistent outbound secure communication channel between the agent and backend services. This eliminates polling and enables near real-time message delivery.
The communication layer uses:
- MQTT messaging protocol
- Secure WebSocket over HTTPS port 443
- HTTP/2 communication
- TLS 1.2 encryption
This architecture enables scalable, secure, and reliable bidirectional communication between endpoints and the platform.
Network Impact and Bandwidth Profile
Real-Time Agent Communication maintains a lightweight persistent outbound TLS connection using a low-bandwidth keep-alive model. It does not continuously stream data and does not generate broadcast traffic.
In steady state, idle usage is conservatively ~100 bytes per minute per endpoint (~6 KB/hour, ~144 KB/day).
Example:
- 500 endpoints ≈ 72 MB/day (~1 KB/sec aggregate)
- 2,000 endpoints ≈ 288 MB/day (~3 KB/sec aggregate)
Even using a higher-bound estimate (~200 KB/day per endpoint), 2,000 endpoints equate to ~4–5 KB/sec aggregate idle traffic.
Bandwidth increases only when commands are initiated, and only targeted endpoints exchange data.
Fallback and Reliability
The existing Agent Commands delivery module remains operational as a fallback mechanism.
If real-time delivery is temporarily unavailable:
- Commands will be delivered through the legacy polling system
- Delivery may take up to 15 minutes
This ensures uninterrupted command functionality during the transition.
Supported Operating Systems
- Windows 8 and above
- Windows Server 2012 and above
- macOS 14 and above
System Requirements
To successfully establish real-time connections, endpoints must:
- Support HTTP/2 and TLS 1.2
- Allow outbound HTTPS traffic over port 443
- Avoid packet inspection of the persistent WebSocket connection
- If a proxy is used, it must tunnel traffic without inspection
Windows Server 2012 TLS Configuration Note
Windows Server 2012 and 2012 R2 do not enable TLS 1.2 by default and may require manual configuration to support RTAC connectivity.
Administrators should verify TLS 1.2 is enabled at the OS level prior to rollout.
What MSPs and Security Teams Should Do
- No action is required for most environments
- Review proxy and SSL inspection configurations
- Verify TLS 1.2 is enabled on Windows Server 2012 systems
- Monitor agent upgrade progress
Frequently Asked Questions
Do I need to enable this feature manually?
No. Real-Time Agent Communication is automatically enabled as agents upgrade.
Will this change how I send commands from the Console?
No. There are no workflow changes in the Console.
What happens if real-time delivery fails?
The system automatically falls back to the legacy polling mechanism. In this case, delivery may take up to 15 minutes.
Do I need to open additional firewall ports?
No new ports are required. Communication uses outbound HTTPS over port 443.
Will SSL inspection or proxy inspection affect this?
Yes. Packet inspection can interfere with the persistent WebSocket connection. Proxies must tunnel traffic without inspection.
How can I confirm my environment supports this?
Ensure endpoints support HTTP/2 and TLS 1.2, and verify that outbound HTTPS traffic over port 443 is not being inspected.
