Skip to main content

Introducing Real-Time Agent Commands

  • February 13, 2026
  • 11 replies
  • 951 views

vadirajs

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:

  1. Support HTTP/2 and TLS 1.2
  2. Allow outbound HTTPS traffic over port 443
  3. Avoid packet inspection of the persistent WebSocket connection
    1. 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.

 

 

11 replies

ProTruckDriver
Moderator

Thank you for the post ​@vadirajs 


TripleHelix
Moderator
Forum|alt.badge.img+63
  • Moderator
  • February 13, 2026

Thank you ​@vadirajs 


Jasper_The_Rasper
Moderator
Forum|alt.badge.img+54

Thank you ​@vadirajs 


Forum|alt.badge.img+35
  • Community Expert Advisor
  • February 13, 2026

@vadirajs ​@BradW 

Hey All,

Quick question that we want to ensure the answer is accurate with regards to network communications:

We have firewalls that run strict TTL on DNS. 

This might fail if new connections from endpoints, are made on Stale DNS data such as if connections are being attempted on destination IP addresses beyond their initial time to live.

The agent MUST honour the time to live that it gets over DNS or there’ll be issues as part of our zero trust network infrastructure, if it violates this, the connection is immediately terminated. 

Thoughts?

John H


Forum|alt.badge.img+35
  • Community Expert Advisor
  • February 13, 2026

Also… what is the expected uptick in bandwidth usage or “noise” in environments with hundreds, if not thousands of endpoints? We want to ensure that this will not overtake a more bandwidth constrained WAN connection in, say, a remote location with starlink/PTP Wireless/DSL etc… 


Ssherjj
Moderator
Forum|alt.badge.img+62
  • Moderator
  • February 13, 2026

Thank you    ​@vadirajs 😊 


vadirajs
  • Author
  • Senior Product Manager
  • February 17, 2026

Also… what is the expected uptick in bandwidth usage or “noise” in environments with hundreds, if not thousands of endpoints? We want to ensure that this will not overtake a more bandwidth constrained WAN connection in, say, a remote location with starlink/PTP Wireless/DSL etc… 

 

This is steady-state idle traffic.

Real-Time Agent Command maintains a lightweight outbound TLS connection from each endpoint to the backend. The connection operates on a persistent, low-bandwidth keep-alive model and does not continuously stream data.

Bandwidth increases only when a command is initiated, and only targeted endpoints exchange data.

For MQTT over TLS persistent connections:

Component Typical Size
MQTT keep-alive (PINGREQ) ~2 bytes payload
Protocol + TLS framing overhead ~70 - 120 bytes
Frequency 60 seconds (typical)

 

Conservative assumption: ~100 bytes every 60 seconds per device (~6 KB/hour, ~144 KB/day).

In steady state, worst-case idle traffic is under ~200 KB per day per endpoint. Even at 2,000 endpoints, this equates to ~4–5 KB/sec aggregate.


Example: 

Scenario A - 500 endpoints

144 KB/day × 500
= 72 MB per day total
≈ 0.83 KB/sec aggregate

Scenario B - 2,000 endpoints

144 KB/day × 2,000
= 288 MB per day total
≈ 3.33 KB/sec aggregate

 

 


BradW
Forum|alt.badge.img+18
  • Sr. Release Manager
  • February 17, 2026

@vadirajs ​@BradW 

Hey All,

Quick question that we want to ensure the answer is accurate with regards to network communications:

We have firewalls that run strict TTL on DNS. 

This might fail if new connections from endpoints, are made on Stale DNS data such as if connections are being attempted on destination IP addresses beyond their initial time to live.

The agent MUST honour the time to live that it gets over DNS or there’ll be issues as part of our zero trust network infrastructure, if it violates this, the connection is immediately terminated. 

Thoughts?

John H

Hi John,

Real time communication connections persist for 23 hours and then they are reset.  System restarts or agent restarts will generate new connections also. Agents will fall back to the legacy delivery system if the real-time system is not available.
I am interested to understand the TTL for DNS in customer environments and also actual behavior. 

Thanks,

Brad


Forum|alt.badge.img+35
  • Community Expert Advisor
  • February 17, 2026

Thanks ​@vadirajs 

@BradW 

We have a Zero Trust Connectivitiy (ZTc) firewall called AdamOne, that refuses all connections unless requested and adheres to very strict TTL and then immediately closes the connection to prevent any potential abuse by bad actors. 

I’d be happy to provide ya with the founders email and Signal number if ya wanna reach out. He also partners with Brightcloud for the threat intelligence. Or I can arrange a Zoom call if you are curious. 

Regards
John H


BradW
Forum|alt.badge.img+18
  • Sr. Release Manager
  • February 17, 2026

Hi John,

Yes, please send that contact information to me via email or PM.  I am interest to learn how that Adam ZTC system works with persistent connections.

Thanks,

Brad


Forum|alt.badge.img+35
  • Community Expert Advisor
  • February 17, 2026

@BradW 

Done. I have sent an email with his contact details. 

Regards
John