The network diagram arrives as a photo of a whiteboard. Three VLANs, a management network the auditor insisted on last year, forty laptops that are mostly in hotels, and a line in the client contract that says the monitoring plane may not be reachable from the networks it monitors. The technician who has to write the change request is not asking whether the product is secure. He is asking where to put it so the request is approved on the first pass and does not come back with questions in the margin. Most platforms give you one topology and expect the network to accommodate it. We document three, and this post is about choosing between them.
The same thing in all three: outbound HTTPS on port 443 to the management server, and the ability to validate its certificate. Every managed endpoint dials out over TLS and keeps one authenticated socket open; browser terminal, remote desktop, monitoring data and commands all ride it. Nothing listens on the endpoint, so the endpoint side of the change request is identical in every posture. Only the plane moves. The agent itself has its own post, the agent never accepts a connection.
When the management plane and the endpoints already share a security boundary and nobody is asking you a questionnaire about it. A single office or a single data centre, with the plane inside the same boundary as the machines it manages. The only rule is the outbound one the endpoints already have. It is the simplest of the three to stand up, and it is the right answer more often than security teams like to admit.
The endpoints leave the boundary and the console does not. Laptops at home, in hotels and on client sites dial out over 443 from wherever they are; the management console itself stays restricted to your office network or VPN. Agents reach in from any network, console access stays behind your perimeter, and no endpoint is ever exposed to the internet. Choose it when technicians and machines travel but the people who administer the platform do not need to.
The monitoring plane sits on a private network with exactly one inbound rule. That pinhole is optional: close it, and you trade nothing but a delay of up to an hour before a revoked session stops working. Choose it when a regulator, a client contract or your own policy says the management plane cannot be reachable from the networks it manages. This is the posture the whiteboard in the first paragraph needs, and it is the one the platforms assembled from acquisitions usually cannot offer, because their modules each want their own path in.
Ask two questions in order. Does a regulator, a contract or your own policy forbid the plane being reachable from the networks it manages? If yes, posture 3, and the rest of the decision is whether the pinhole stays open. If no, do the machines or the technicians leave the boundary? If the machines do and the administrators do not, posture 2. If neither does, posture 1, and resist the urge to build posture 3 for a single office because it sounds more serious. The posture should match the constraint you actually have, because every rule you add is a rule you maintain.
Endpoint side, all postures: outbound TCP 443 to the plane’s address, TLS validated, no proxy re-signing the certificate. No inbound rules.
Plane side, posture 1: nothing beyond what the boundary already permits.
Plane side, posture 2: agents in from any network on 443; console access from the office network or VPN only.
Plane side, posture 3: agents in on 443; one inbound rule into the management network, or none, with the one-hour tail written into the request so nobody is surprised.
The optional listeners, any posture: a collector for the devices that cannot run an agent binds a local port on a machine you choose; a trap receiver you designate listens for SNMP traps; remote desktop on macOS and Linux uses the operating system’s own screen sharing on loopback, relayed out over the agent’s socket. Name the machines, and the reviewer has nothing left to ask.
Our deployment documentation includes a written threat model for total compromise of the management plane: what an attacker would reach, what stays out of reach, and what each posture costs you if it happens. We will not summarise it in a blog post, because a summary is exactly the kind of vague claim that costs a security team a week. Ask for the document during evaluation, and bring the whiteboard. A technical deep-dive is sixty minutes on your own network diagram: which posture fits, what the change request says, and what the threat model means for you.
For posture 3 it matters a great deal. Every customer gets their own deployment: on your hardware, in your cloud account, or hosted by us on infrastructure dedicated to you. Your database, your keys, your instance. Self-hosting is a deployment choice, not a licensing one: install with the OS installers on Rocky, Ubuntu or SUSE, or run the container images, and nothing phones home except a daily licence check. A management plane you run on your own private network is a management plane you can actually isolate. A slot in someone else’s shared instance is not.
The wrong posture costs you in change requests. Each one that bounces is a week, and a posture that does not match the constraint bounces every time the estate changes. The right posture costs you once: posture 3 with the pinhole closed carries the documented tail, up to an hour before a revoked session stops working, and that hour is the price of a plane nothing can reach. Write it into the request rather than discovering it in an incident review.
All three postures, the endpoint requirements, where a port does open, and the bad day, as a PDF written for the person who answers the firewall change request.