Industrial Raspberry Pi hardening: reduce risk without pretending it disappears

A Raspberry Pi can collect signals, bridge protocols, or analyze data at the edge. Linux in a control cabinet, however, is not automatically an industrial controller. Hardening narrows attack paths and limits damage; it cannot compensate for an unsuitable power supply, enclosure, storage device, or network design. Treat the following as an operating-system baseline, and rehearse every change on representative lab equipment before deployment.

1. Start with a threat model

List what the node holds, what can reach it, and what failure would affect. Plausible events include stolen credentials, an exploitable service, physical loss, a compromised peer on the same VLAN, unauthorized configuration changes, and filesystem damage after power loss. Record the application flows that are genuinely necessary, the people allowed to administer the host, and the amount of state the process may lose.

Turn that inventory into enforceable statements: SSH arrives only from a jump host; telemetry leaves only for named destinations; field services are not reachable from the corporate network; and operators can rebuild from a known image. Remove every user, package, listener, and route that serves no statement. Revisit the model whenever software, connections, ownership, or consequences change.

2. Patch on a supported Raspberry Pi OS cadence

Raspberry Pi documents apt update followed by apt full-upgrade for Raspberry Pi OS. It warns against routine rpi-update, which installs pre-release firmware. Debian likewise recommends regular upgrades for security fixes. Apply that guidance through a controlled window, not unattended hope: test the same OS branch, retain the prior image, and define health checks and rollback criteria first.

sudo apt update
apt list --upgradable
sudo apt full-upgrade
sudo reboot

Monthly review is a reasonable starting cadence, with an out-of-cycle assessment for applicable vulnerabilities. Log packages, date, reboot, and results. Confirm that the installed Raspberry Pi OS/Debian release remains supported; when support ends, schedule migration instead of collecting permanent exceptions.

3. Use SSH keys and least privilege

Give each administrator a named account and public key. Open a second session successfully before disabling password authentication and direct root login in /etc/ssh/sshd_config.d/:

PasswordAuthentication no
PermitRootLogin no
AllowUsers operator

Validate before reload with sudo sshd -t && sudo systemctl reload ssh. Run the application under a separate account without an interactive shell or blanket sudo. Grant only required device groups and narrowly defined administrative commands through a sudoers file checked by visudo. Keep private keys away from the node and document local recovery from a broken SSH policy.

4. Combine nftables with network segmentation

Segmentation at the switch or upstream firewall controls which systems can approach the node. A local firewall limits mistakes and lateral movement inside that segment. One does not replace the other. Write an allow matrix of source, destination, protocol, and port; then default-deny after permitting established traffic, loopback, jump-host administration, and explicit application flows.

Keep the nftables ruleset versioned. Check it with nft -c -f /etc/nftables.conf, apply it with nft -f, and inspect nft list ruleset. Maintain console access during rollout. Site-specific IPv6, DHCP, DNS, NTP, and industrial protocols make copied generic rules dangerous.

5. Sandbox services with systemd

Let systemd start the application as its dedicated user. Add restrictions incrementally, such as NoNewPrivileges=yes, PrivateTmp=yes, ProtectSystem=strict, ProtectHome=yes, and precise ReadWritePaths= entries. systemd-analyze security app.service exposes potential weaknesses, but its score proves neither correct behavior nor adequate policy.

After each restriction, test devices, name resolution, time, TLS credentials, files, and restart behavior. Restart=on-failure handles a terminated process, not bad data or a missing dependency. Bound restart storms with StartLimitIntervalSec= and StartLimitBurst=.

6. Make secrets replaceable

Do not bake passwords, private keys, or tokens into an image, repository, unit file, or command line. Provision an identity per device, restrict access to the service account, and separate development credentials from operational ones. EnvironmentFile= keeps values out of a unit but does not encrypt them. Use the secret mechanism available in your infrastructure, track owner and expiry, rotate credentials, and rehearse revocation for a lost node.

7. Choose persistent writes or OverlayFS deliberately

Raspberry Pi OS can enable OverlayFS with:

sudo raspi-config nonint enable_overlayfs

The temporary upper layer reduces persistent writes and discards changes on reboot. That same property can discard upgrades, rotated keys, configuration, and local logs while consuming RAM. Maintenance must explicitly disable or manage the overlay. Classify each path as immutable, temporary, or persistent. A read-only root does not replace suitable storage, controlled shutdown, backups, or restore testing.

8. Retain useful evidence

Set journald limits and inspect consumption with journalctl --disk-usage. If root storage is temporary, forward required events to an authenticated collector or reserve quota-controlled persistent storage. Exclude secrets, synchronize time from an authorized source, and make alerts identify node, service, version, and condition. Unlimited noisy logs can fill storage and conceal the first failure.

9. Understand watchdog boundaries

A hardware watchdog resets a host that stops feeding it; RuntimeWatchdogSec= lets the system manager feed that timer. A compatible service can use WatchdogSec= for periodic notifications. Neither mechanism establishes that telemetry, outputs, or dependencies are healthy. Test a hung process, high load, and unavailable dependency. Prevent repeated resets from erasing evidence or worsening an unsafe physical output.

10. Back up, roll back, and run a recovery drill

Store versioned configuration, inventory, image checksums, persistent data, and reprovisioning material away from the device. Protect backed-up secrets or issue replacements. Before changing packages or policy, capture required state and state exactly when to roll back. An unread, untested backup is only an assumption.

Periodically remove the lab medium, install the known image, apply configuration and fresh credentials, restore data, join the test network, and verify ports, services, logs, watchdog behavior, and application flow. Measure recovery time and repair ambiguous manual steps. The result is evidence for that rehearsed scenario, not proof against every failure.

Minimum predeployment checks

sudo sshd -t
sudo nft -c -f /etc/nftables.conf
sudo nft list ruleset
systemctl --failed
systemd-analyze security app.service
journalctl -u app.service --since today

Also inspect users, groups, listening ports, pending packages, persistence after reboot, and restoration from backup. Record who accepted the result and repeat these checks after material changes.

Primary references

Accessed 2026-07-24:

Industrial Raspberry Pi Hardening: An Honest Guide