Security and TLS
4 minute read
The management platform is penetration tested before every release. If your organization requires security evidence for procurement or compliance reviews, test reports are available on request.
Authentication
Password
The board uses a single shared password for dashboard and API access. On first boot, the default password is admin and must be changed before any features are accessible.
Password requirements:
- Minimum 8 characters
- Changing the password invalidates all active sessions (all users must log in again)
Sessions
- Login returns a Bearer token valid for 24 hours
- Tokens are invalidated on password change or logout
- Login is rate-limited to 10 attempts per minute per IP address
Changing Your Password
- Click Settings or the gear icon in the dashboard
- Enter your current password
- Enter and confirm your new password
- Click Change Password
All existing sessions are invalidated. You will be redirected to the login page.
TLS Certificates
The dashboard is served over HTTPS. Three certificate modes are available:
Self-Signed (Default)
A self-signed certificate is generated automatically on first boot. The dashboard works immediately. Browsers will show a certificate warning, which is expected and can be safely accepted for local network use.
Custom Certificate Upload
Upload your own certificate for trusted HTTPS without browser warnings:
- Obtain a certificate from your Certificate Authority (or internal CA)
- Go to the TLS settings in the dashboard
- Upload the certificate file (
.crtor.pem) and private key file (.key) - The certificate is applied immediately with no service restart
The hot-swap is atomic. Active connections continue on the old certificate; new connections use the new one.
ACME (Let’s Encrypt) - HTTP-01
For boards with a public DNS name and inbound internet access:
- Assign a DNS name to the board’s IP address
- Go to the TLS settings and select ACME mode
- The platform requests a certificate from Let’s Encrypt
- Certificates auto-renew before expiry
Requirements:
- The board must have a public DNS name
- Port 80 must be accessible from the internet (HTTP-01 challenge)
DNS-01 Challenge for Air-Gapped Deployments
For boards on private networks, air-gapped environments, or deployments where the board cannot be exposed to the internet, use the DNS-01 challenge method. This is the recommended approach for government, defense, and enterprise environments.
With DNS-01, the board never needs inbound internet access. A separate machine with internet access handles the certificate request:
- Run certbot on any machine with internet access:
sudo certbot certonly --manual --preferred-challenges=dns \ -d board.yourdomain.com - Certbot displays a TXT record value to add to your DNS
- Add the
_acme-challenge.board.yourdomain.comTXT record at your DNS provider - Verify propagation:
dig +short TXT _acme-challenge.board.yourdomain.com - Press Enter in certbot to complete validation
- Push the certificate to the board:
curl -k -X POST \ -H "Authorization: Bearer <token>" \ -F "cert=@/etc/letsencrypt/live/board.yourdomain.com/fullchain.pem" \ -F "key=@/etc/letsencrypt/live/board.yourdomain.com/privkey.pem" \ https://<board-ip>/api/v1/system/tls/upload
The certificate is hot-swapped atomically. No service restart required.
For fleet deployments, this process can be fully automated if your DNS provider offers API access for programmatic TXT record creation. Supported providers include Cloudflare, DigitalOcean, AWS Route 53, and Google Cloud DNS. Not all DNS providers support API automation (for example, name.com does not), but the manual workflow above still works with any provider. Wildcard certificates (*.boards.example.com) are also supported with DNS-01, allowing a single cert to cover an entire fleet.
Let’s Encrypt certificates expire after 90 days. Set up a cron job on the renewal machine to automate the process.
Viewing Certificate Info
The dashboard shows the current certificate details including:
- Subject (CN and SANs)
- Issuer
- Expiry date
- Current mode (self-signed, upload, or ACME)
Audit Logging
Every action that changes board state is recorded in the audit log:
| Field | Description |
|---|---|
| Timestamp | When the action occurred |
| Action | What was done (e.g., port_disable, password_change, fleet_pair, reboot) |
| Actor | IP address of the user who performed the action |
| Target | What was affected (e.g., pse0/port3, fleet/CRU-000012) |
| Detail | Additional context |
Viewing the Audit Log
The most recent entries appear in the Recent Activity section at the bottom of the dashboard. Click to expand and see more entries.
The full audit log is available via the API with pagination:
curl -k -H "Authorization: Bearer <token>" \
"https://<board-ip>/api/v1/system/audit?limit=50&offset=0"
Log Retention
Audit logs are stored in the board’s SQLite database and included in backup exports. Logs persist across reboots and service restarts.
Network Security
Local-Only by Default
The management platform listens on the board’s network interfaces. It is accessible to any device on the same network. There is no cloud component, no external account, and no outbound data transmission (except ACME certificate requests if enabled).
HSTS
HTTP Strict Transport Security headers are enabled by default with a 1-year max-age. This tells browsers to always use HTTPS when connecting to the board.
No External Dependencies
The platform requires no internet connectivity for normal operation. All features work on air-gapped networks. The only feature that requires internet access is ACME (Let’s Encrypt) certificate provisioning.
Fleet Security
Fleet communication between paired boards uses Ed25519 digital signatures. Each request includes a signed timestamp with a 5-minute replay window. Board identity is verified against stored public keys from the pairing process.
Last modified April 9, 2026