No standing access paths
The recommended deployment is a pull agent service on the server, for both Windows and Linux. The service connects outbound to sslbrain over HTTPS and fetches its tasks. The appliance therefore holds no SSH key, no password, and no sudo right for the server, and no inbound ports are opened. There is simply no standing access path to steal.
The security boundary is the signature, not the network
The agent only executes task packages that are signed and verified against a pinned trust anchor. A task without a valid signature from a key you chose to trust is rejected, no matter where it came from. That moves the security boundary from the network path to the signature: what matters is not who can reach the server, but which code you approved.
There is a precise limit to this guarantee, and we state it plainly. A compromised appliance can still direct your agents to run FairSSL-signed scripts with attacker-chosen inputs, including installing an attacker-supplied certificate, and only ever at the privilege you granted the agent. What it cannot do is introduce new or unsigned code.
You choose the privilege level
How much privilege the service runs with is decided locally on the server. Run it as root or LocalSystem if simplicity matters most. Or run it as a scoped service user that only has write access to one service’s certificate files and permission to run one reload command. sslbrain works in both models and never requires more than the task at hand.
Push as the fallback, still least privilege
Devices that cannot run a service, such as network equipment and appliances, are handled via push over SSH or API. There too the account can be scoped: a dedicated user with access to the certificate paths and, where required, a narrowly scoped sudo rule for exactly the commands the installation needs. The signing and approval principles are described under policy management.