How we reach your switches

A small agent runs as a Windows service on a machine on your network. It connects out to the portal over HTTPS and asks for work every few seconds, so nothing on the internet needs to reach in and there is no firewall rule to open. It talks to your switches over SSH from inside your network. Firmware images go the same way: over SCP to AOS-S, and over the REST API to AOS-CX, where the switch’s certificate must match the one it reports over its pinned SSH login.

The portal never writes switch commands. It sends the name of an operation and its settings; the agent builds the commands from a reviewed catalogue, validates every input, and returns them for approval. The one exception is a show command someone types, which only reads: the portal and then the agent check it against the agent’s own list of show commands for that switch family, and anything else is refused.

The first time the agent meets a switch it records the switch’s SSH host key. If a different key ever answers at that address, the agent refuses to log in and the portal flags it. Clearing that is a deliberate, recorded action — never automatic.

Where your data lives

The portal and database run in London. Supporting services are in the UK or EU; the full list of sub-processors is in our Data Processing Agreement.

Configuration backups are encrypted before they are stored. Opening or searching them is limited to people who can change switches, and every view is recorded.
We don’t keep MAC address tables, ARP tables, switch logs or SNMP output. If a show command you run prints one, the answer is held encrypted, shown only to you and deleted as it is shown; one not opened within ten minutes can no longer be read and is then deleted.
Finding a device by MAC address is done by the agent on site; only the matching line comes back.
Show commands are read-only. Anything that would print the configuration, a password, a key or captured traffic is refused, and the agent blanks the password and key formats it recognises in an answer. An optional filter is applied by the agent, so only the matching lines leave your network. The command is recorded in the audit log, with any device address in it masked.
Alert emails name the switch and the time window — never config text. You read the change in the portal.
Firmware images you upload are HPE’s software and hold no personal data. Each is checked before use, and deleted once no change has used it for 90 days.
DHCP leases are read from the switch when you look at them. The list is held encrypted, shown only to you and deleted as it is shown; one not opened within ten minutes can no longer be read and is then deleted.

Passwords and secrets

Switch logins, and secret values in a change such as a new admin password or SNMP community, are stored encrypted. The agent fetches them for one command, while that command is running, within a short window — and they are never written into the command history, which is kept.

Opening a PuTTY session from the portal uses a single-use ticket that expires in 90 seconds. The installer on your PC redeems it, and the password is handed to PuTTY in a temporary file that is deleted once PuTTY has read it — never on a command line, where other programs could read it.

How a change is controlled

Previewed exactly. You approve the literal commands for each switch, and those are what run.
Saved only if clean. If the switch rejects any line, the configuration isn’t saved.
School hours. Anything that can interrupt the network needs a recorded reason between 08:00 and 16:00 on weekdays.
Schedules re-check. A scheduled change is checked again when it fires, and cancelled rather than sent if it is more than 30 minutes late.
Recurring runs are bound to what you approved. If the commands a schedule would send ever differ from the ones you approved, it doesn’t run and you’re emailed.
Bulk runs are paced. Each switch waits its turn, and the run stops if too many fail.
Firmware restarts are gated. In a run, each switch must be back on the new version before the next one restarts; if one isn’t, the run stops and the rest are left alone.
Restores check themselves. Restoring a backup runs under the switch’s own undo timer, and the switch is saved only once it reads back exactly as the backup. If the agent loses the switch part way, the switch undoes the restore itself when the timer ends (an AOS-S switch by restarting into its saved configuration).
Unproven operations are refused. Anything not yet verified on real hardware for that OS is shown as not available yet, and the agent won’t send it until it is.

The offline installer

The installer has no licence key. On first run it shows a code, and someone in your organisation approves it from the portal, signed in as themselves — so your single sign-on applies and no password is typed into the program. That laptop then holds a signed lease that works offline for 14 days and renews itself when online.

Each approval uses one of your organisation’s seats. Revoke a seat and that laptop locks the next time it goes online, and within 14 days regardless.
The activation is tied to that computer and encrypted for that Windows account. A copy made to work anyway is detected on renewal and the seat is revoked.
The installer only listens on the laptop itself, behind a random access key, and site profiles drop passwords unless you choose to keep them.

What we don’t claim

Nothing that runs offline can stop someone who modifies the program itself. A modified installer loses renewal and anything recorded against your organisation, but we won’t pretend it can’t exist.

Change alerts come from comparing nightly backups, so we see that a config changed and roughly when — not who typed it at the console. Nothing rolls back by itself: a restore runs only when someone asks for it and approves its commands.

Questions a security review needs answered? Ask us directly.