Why we designed the Nexus monitoring agent to be outbound-only

Most legacy RMM tools ask you to open something. A port for the agent to listen on, a VPN tunnel back to a management console, a firewall rule scoped "just for monitoring." Every one of those is a small, permanent increase in a client site's attack surface, and every one of those is something an already-stretched MSP has to remember to lock back down, audit, and justify at the next security review.

The Nexus on-prem agent does not listen for anything. It initiates every connection outbound, on a schedule, over an authenticated encrypted channel, and reports what it finds — device health, network status, firewall posture across FortiGate, Omada, Meraki, and UniFi gear — back to the platform. There is no inbound rule to add, because there is nothing for an inbound rule to reach.

Why this was a hard requirement

• A listening agent is a target. If it has a vulnerability, it is reachable from the network it sits on — an outbound-only agent has no listening surface to exploit remotely.
• MSPs manage dozens of sites with different firewall admins, different policies, different comfort levels. "No changes needed" removes an entire category of deployment friction and security sign-off.
• Client-side security teams increasingly ask vendors directly: "what inbound access does your agent require?" The honest answer for Nexus is none.

This is also why the compliance mapping in Nexus tracks it explicitly: outbound-only monitoring is one of the concrete architectural facts you can cite in your own SOC 2 or NIST CSF network-security narrative, not a marketing claim you have to take on faith.

None of this requires trusting a vendor's claim blindly, either — ask any RMM vendor, including us, to show you the actual firewall rule diff before and after agent install at a test site. That is the level of specificity "zero inbound exposure" should hold up to.