Planning
Work through this before you unbox anything. It settles which deployment model you are running and what network access to arrange with whoever manages your switches and firewalls, so the actual install in Sensor is just wiring things up.
Choose a deployment model
See Architecture for how the sensor and the console talk to each other and what crosses the facility boundary. In short, the sensor always runs in your facility. The console either runs in the Safetybits cloud, or on your own IT infrastructure if you need to keep everything on premises.
If you already have an account, your deployment model is decided for you, an on-prem console is provisioned once, at signup. If you are planning a new facility, the deciding factor is usually whether your organization is comfortable with security posture data leaving the facility at all, or has an existing multi-plant on-prem console that a new facility should report into.
Where the sensor sits
The sensor never sits inline. It reads a copy of your OT network’s traffic from a mirrored (SPAN) port on the switch closest to the segment you want visibility into, and it never sends packets into that segment on its own. Plan for a switch with a free SPAN capable port near the OT network, and involve whoever manages that switch early, since configuring port mirroring is a change to switch configuration even though it does not touch any OT device. See Sensor operations for what happens if that mirrored feed is incomplete.
The sensor also needs a second, routable connection directly into the OT network itself, separate from the mirrored feed. It uses this to actively identify devices: checking which addresses are reachable and asking each one for its model, firmware, and serial number using its own native protocol. Without this connection, resources still appear from the mirrored traffic alone, but with far less detail, and vulnerability matching depends on knowing a device’s firmware and version. See Discovery and the inventory for the difference between passive observation and active identification.
Network and port requirements
The sensor needs the following connections:
| Connection | Direction | Purpose |
|---|---|---|
| Management | Outbound, TCP 443 | Reports discovery results, alerts and baselines to the console, and receives rule and command updates. |
| OT network | Outbound, ARP, ICMP, TCP and UDP to device ports | Active identification: reachability, hostnames, open ports, and vendor specific queries for model, firmware, and serial number. See Discovery and the inventory. |
| Port mirroring | Inbound, receives a mirrored copy of traffic | The SPAN feed the sensor listens to. It never originates traffic on this connection. |
| Time | Outbound, UDP 123 (NTP) | Keeps the appliance’s clock synchronized. Flow timestamps, TLS, and log correlation all depend on it. |
For a SaaS deployment, the management connection reaches connect.safetybits.io on TCP 443. For an on-prem console, it reaches your console’s address on the same port, or on the port your administrator assigned to the agent manager service if it is not proxied behind your console’s default HTTPS port.
The management connection also needs general outbound internet access, not just to the console, since the appliance pulls its own software updates over it. See Upgrade.
Sizing
Appliance sizing depends on how many resources the facility has and how much traffic the mirrored port carries. Your Safetybits contact confirms the right appliance model with you during onboarding, based on the facility you are deploying into. The on-prem console has the same conversation for a multi facility deployment, since it takes traffic from every sensor that reports into it.