We've been running Proxmox VE clusters with Ceph storage in production, spread across several datacenters, since long before migrating off VMware became fashionable. And in all that time we've learned one uncomfortable thing: most "Proxmox hardening" guides are lists of commands with no judgment behind them. They tell you what to touch, but not what actually matters or what is security posturing that just makes your life harder.
This is not that list. It's what we apply to every cluster we put into production on Proxmox VE 9.2 (Debian 13.5, kernel 7.0), ordered by what actually moves the needle. If you're only going to do three things, do the first three.
1. Access: 2FA on root@pam and named accounts (non-negotiable)
Proxmox ships with 2FA out of the box. There's no excuse not to use it. The rules we follow:
- ✓Mandatory 2FA on
root@pam, and that user is not used for day-to-day work. It's the break-glass account. - ✓Named accounts for every administrator, also with 2FA. If someone leaves, you revoke their account — you don't rotate the root password for the whole team.
- ✓Host SSH: key-only,
PermitRootLogin prohibit-passwordandPasswordAuthentication no. The web panel and SSH are two different attack surfaces; both get locked down.
This isn't glamorous, but 90% of the incidents that reach us from third parties start with badly configured access, not with some exotic 0-day.
2. API tokens with least privilege
This is where almost everyone slips up: they create an API token with root permissions "so it works" and leave it there forever.
When we integrate a cluster with an external tool —monitoring, backup, automation— we create a dedicated user and a read-only token with the built-in PVEAuditor role, not a token with administrator permissions. If the tool only needs to read the cluster's state, don't give it permission to shut down a VM. Sounds obvious; it almost never gets done.
3. Firewall: default deny, and segment the Ceph networks
The Proxmox firewall works at three levels (datacenter, node, VM). Our stance:
- ✓Default deny at the datacenter level, and explicitly open what's needed (8006 for the panel, SSH, Corosync between nodes).
- ✓The management panel is not exposed to the Internet. You reach it over VPN or a management network. Period.
- ✓If you run Ceph —and if you're serious, you do— separate the traffic into VLANs: management, VM network, Corosync and Ceph, each on its own. Ceph's cluster network (replication) and its public network must not fight Corosync over the same cable. When Corosync loses latency because Ceph replication is eating its bandwidth, the cluster starts evicting nodes, and at 3 a.m. that's not something you feel like discovering.
4. fail2ban and the background noise
The moment a host peeks out onto the Internet, it starts receiving automated login attempts. fail2ban watching SSH and the Proxmox panel cuts that noise and, as a bonus, leaves you much cleaner logs for when you actually need to investigate something. It's cheap to set up and removes a lot of noise.
5. AppArmor and kernel hardening
Proxmox comes with AppArmor; make sure it's enforcing, not in complain mode. And we apply a set of hardening sysctl parameters (network stack protection, kptr_restrict, dmesg restriction, etc.). It's not magic, it's surface reduction: everything you switch off is one less thing someone can use.
One note on 9.2: it adds seccomp filtering to block privilege escalations via AF_ALG sockets in containers. If you use LXC, you get it out of the box — one more reason to stay up to date.
6. Backups: client-side encryption and immutability (or it's not a backup)
A backup an attacker can delete or read isn't a backup, it's a consolation. With Proxmox Backup Server:
- ✓Client-side encryption: data leaves the host encrypted. If someone gets into the PBS, they see noise.
- ✓Immutable backups: so neither a compromised administrator nor ransomware can delete restore points within their retention window.
And what isn't tested doesn't exist: we verify restores on a regular basis. An unverified backup is a hypothesis.
7. Patching: unattended-upgrades for the critical stuff
Keeping the cluster patched is boring, which is why it doesn't get done. We configure unattended-upgrades for critical security patches, and we plan major upgrades (like the jump to 9.2) in a maintenance window, one node at a time, with Ceph's ok-to-stop checked before touching anything.
What we DON'T do (and why)
Just as important as the list is what we leave out:
- ✗We don't turn the host into an unusable bunker. Security that prevents people from operating ends up disabled by the team itself. Striking that balance is the job.
- ✗We don't blindly chase 100% of a CIS benchmark. Benchmarks are a starting point, not a goal. Some controls add nothing on a virtualization hypervisor and do break things.
- ✗We don't rely on "security through obscurity". Changing the SSH port isn't hardening; it's window dressing.
A 9.2 extra that actually changes things
9.2 brings WireGuard and BGP as fabric protocols in the SDN stack, with route maps and prefix lists for fine-grained filtering. For anyone building real networks between sites, this matters: you can build the cluster fabric with the same tools you already use to route the rest of your network, instead of with a bolt-on workaround. We were already living on WireGuard and BGP; having it native in Proxmox removes moving parts for us.
In short
Proxmox hardening isn't a list of 40 commands you run once. It's a handful of well-placed decisions —access, least privilege, segmented networks, backups that hold up— and the discipline to keep them in place. Everything else is noise.
Sources (version data, verified): Proxmox VE 9.2 (May 21, 2026): Debian 13.5, kernel 7.0, dynamic CRS, SDN with WireGuard/BGP, seccomp AF_ALG in containers — proxmox.com; PVE 9 hardening best practices — HomeSecExplorer Proxmox-Hardening-Guide.
Putting Proxmox into production and want someone to review it before it's too late?
At everyWAN we design, deploy and operate Proxmox VE environments with Ceph in production. We review your design and hardening before the design reviews you.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN