Network & firewall requirements
What Arcturus does and does not need from your network: nothing for cloud-connected BMSes; a firewall opening for Niagara MQTT.
For most sites Arcturus needs nothing from your network — no VPN, no inbound connections, no firewall openings. The platform talks to your BMS through the BMS vendor's cloud (the same cloud the BMS already uses), and to indoor sensors through the sensor vendor's cloud. Both connections are outbound from those clouds, not from your building.
The cloud-BMS case (most common)
IWMAC, Airthings, Disruptive Technologies, and similar cloud-managed providers all work this way: the device on site sends readings out to its vendor cloud over your existing internet connection, and Arcturus reads from that cloud. Your firewall sees only outbound HTTPS from the device to its vendor — nothing new, nothing from us.
The Niagara N4 (MQTT) exception
Niagara N4 sites that integrate via MQTT are different. Either the Niagara station hosts an MQTT broker on the building network, or you stand up a dedicated broker. In both cases the broker has to be reachable from our cluster, which means the customer side opens a port on the firewall and exposes the broker on a stable hostname (typically over TLS). The "no firewall changes" line on the security overview applies to cloud-connected BMSes only — for Niagara MQTT, expect a coordinated firewall change with your IT team.
What to give your IT team
- For cloud BMSes (IWMAC, sensor providers): nothing. The existing outbound HTTPS path that the device uses to its vendor is the only path involved.
- For Niagara MQTT: the broker hostname / IP, the TCP port to open inbound, and a request to enable TLS if it is not already on. Our cluster will connect outbound to that endpoint.
- For all sites: no static IP from us, no Arcturus-issued certificates to install, no agent to deploy on the building network.