Onboarding devices¶
Onboarding is how you tell the appliance which switches, firewalls, and access points to actively monitor. There are two levels:
- Discovered (read-only, unlimited). The appliance runs an
nmapsweep of the subnet and lists every host it finds, with a best-guess OS and vendor. Discovered devices cost nothing and don't count against your plan. - Managed (credentialed). When you onboard a device, you give it a type and store credentials in the vault. The appliance then polls it deeply (ports, sessions, neighbors, health) and — on Pro and above — can stage approved config changes. Only managed devices count against your tier device limit.
Step 1 — find the device¶
- Open The Floor and go to your site's device list.
- Newly discovered hosts appear automatically from the appliance's
nmapsweep. You can also run a ping sweep from the dashboard, which uses the subnet the appliance reported on check-in. - Find the switch / firewall / AP you want to manage.
Step 2 — set the device type¶
Onboard (register/enroll) the device and set its device type so the appliance knows which protocol and parser to use. Supported types:
| Vendor / family | Device type | How the appliance talks to it |
|---|---|---|
| Cisco IOS / IOS-XE | cisco_ios |
SSH (netmiko), NAPALM where available |
| Cisco NX-OS | cisco_nxos |
SSH / NAPALM |
| Cisco IOS-XR | cisco_xr |
SSH / NAPALM |
| Palo Alto (PAN-OS) | paloalto_panos |
HTTPS XML API (key-based) |
| Juniper Junos | juniper_junos |
SSH / NAPALM |
| Fortinet FortiGate | fortinet |
SSH / NAPALM |
| Arista EOS | arista_eos |
SSH / NAPALM |
| Ubiquiti / UniFi | ubiquiti_edge |
Controller API / SSH |
| pfSense | (generic) | SSH |
| Linux host | linux |
SSH |
| SNMP-only devices | (SNMP) | SNMP polling |
| Proxmox / ESXi / XCP-ng / Hyper-V | hypervisor types | Vendor API / WinRM |
Protocol is chosen for you
You don't pick SSH vs. NETCONF vs. REST vs. NAPALM vs. SNMP — the appliance auto-selects the best available protocol per vendor and falls back gracefully (e.g. NAPALM for normalized facts, dropping to raw show commands if a driver isn't available). Palo Alto always uses the XML API.
Step 3 — store credentials in the vault¶
A managed device needs credentials, kept in the on-prem credential vault:
- In the device's panel, choose Store credential.
- Enter the username and secret, and pick the auth method:
password— a login password (SSH / SNMP community / PAN-OS keygen). Username required.api_key— the secret is a device API key used directly (e.g. a pre-minted PAN-OS XML API key). Username optional — PAN-OS keys need none.
- Save. The secret is encrypted before it's stored (salted, encrypted blob) and never returned in any list view.
The appliance fetches these credentials at poll time from the vault over its authenticated backend channel — credentials are keyed by the backend's real device id, scoped to your tenant.
Read-only is enough to monitor
For pure visibility, a read-only account on the device is all you need. You only need write-capable credentials if you intend to use the AI assistant's approve-and-deploy config changes (Pro+).
Step 4 — confirm it's polling¶
Within a poll cycle or two the device flips from discovered to online and its rich telemetry — interfaces, neighbors, sessions, health — populates The Floor. If it doesn't, see Troubleshooting.
The credential vault & MFA-gated reveals¶
The vault is the heart of the appliance's security model:
- Encrypted at rest. Every secret is stored as a salted, encrypted blob. List views return metadata only — never the password.
- Role-gated. Technicians and admins can add, modify, and reveal credentials (all audited). Deletes are stricter: an admin deletes immediately, but a technician can only request a delete, which becomes an approval card for an admin.
- Break-the-glass reveals. Revealing a plaintext credential ("break the glass") requires a written reason (5+ chars) and, if the user has step-up enabled, an MFA code (
X-MFA-Token). Every reveal is recorded — who, what, when, why, and from which IP. - Tamper-evident audit log. Every vault action (store, modify, reveal, delete-request, delete-approve) is written to a hash-chained audit trail. Each row's hash includes the previous row's hash, so editing or removing any entry breaks the chain — and an admin can run a verify that pinpoints exactly where. Admins can review recent events and verify the chain from the dashboard.
See Security for the full model and what does (and doesn't) leave your building.
Next: The AI smart collector.