Device support matrix

Skans covers a device across four capability lanes — and cert-deploy is only one of them. The most important devices in an enclave often can’t hold a certificate at all; for those, the monitor/ingest lane is the entire story.

123 device drivers — 120 cert-deploy · 75 credential-rotate · 10 NAC/802.1X · 1 SCEP · 15 firmware-read · 26 config-backup · 1 AP-LSC · 2 config-read (API) · 2 monitor-push.

A ✓ means the driver implements that lane — its declared capability, read straight from the signed pack. It is not a claim that the lane has been validated on a device. For what’s actually been proven per driver — hardware, emulation, or still spec-verified — see Driver validation status, where most cells are honestly still 📋 spec-verified.

Manage/read key — Cert-deploy: issue + install + bind a TLS cert. Rotate: change the device admin password on a schedule (“LAPS for cameras”). NAC: write RADIUS + 802.1X/MAB to the fabric. SCEP: on-device CSR enrolment. Firmware: read the running version for CVE-matching. Config-backup: pull the running-config over SSH, versioned + change-detected. AP-LSC: provision locally-significant certs onto wireless APs through the controller. Config-read (API): config snapshot over the management API (API-managed gear with no SSH show-run). Monitor-push: at enrol the driver configures the device itself to send syslog + SNMP at the Skans collector. Some drivers carry additional lanes gated behind per-vendor env flags (off by default); each cell reflects the capability set advertised by the running build.

A few platforms accept a certificate but expose no API to bind it to their web service — OPNsense is the notable one (upstream limitation). Skans imports the cert and reports the mismatch honestly; the one-time selection is manual (System → Settings → Administration → SSL Certificate). See Troubleshooting → certificate mismatch. Certificates live on the device, so a factory-reset or replaced unit shows a mismatch until you re-enroll it.

Monitor / ingest lane — the OT/IoT coverage the table above can’t show #

The devices that matter most in an enclave — PLCs, UPS/PDUs, sensors, meters, controllers, cameras — often can never hold a certificate, so they are blank in the manage table. That is not a gap: it is the boundary between the manage lane and the monitor/ingest lane, which is a separate collector process (Skans.Collector). These collectors are built:

Every active collector is OT-safe: per-target maintenance windows, poll rate-limiting, source-IP allowlists, read-only probing.

Each has its own page: Syslog ingestion, SNMP monitoring (poll + traps), and Industrial protocols (OT/ICS) (EtherNet/IP + Modbus). Config-backup and off-box archiving are in Backup & recovery.

Coverage reality: the SNMP profile pack carries ~484 vendor enterprise profiles; the large majority of them — power/UPS (Vertiv, Eltek), environmental (Stulz, Carel, AKCP), industrial/OT (Moxa, Hirschmann, ABB, Schneider), optical, wireless, storage, VoIP, time/GPS — have no cert driver at all. For them, SNMP + syslog is the entire Skans coverage, and it is largely zero-touch (auto-matched by sysObjectID, with a generic floor for any SNMP device).

Honest built-vs-designed: syslog, SNMP poll/trap, EtherNet/IP, Modbus, config-backup, LLDP topology, and the notify lane (SMTP/webhook/SIEM-forward) are built. BACnet telemetry, OPC-UA telemetry, and ICMP-as-a-collector are designed-not-built — BACnet/SC and OPC-UA exist today only as manage-lane certificate issuance, not monitoring.

Neighbor-discovery decode (LLDP/CDP/EDP/FDP/NDP/UBNT) is a pack-level READ capability (a shared decoder), not per-driver.