CIS Benchmark for Proxmox VE: applying CIS Debian

What CIS publishes

As of 12 October 2026, the CIS catalogue contains no CIS Benchmark for Proxmox VE itself. It does list Debian Linux 13 (version 1.1.0), Debian Linux 12 (2.0.0) and Debian Linux 11 (2.0.0). Recommendations are grouped into levels: Level 1 aims at a reasonable baseline, Level 2 at deeper hardening, with Server and Workstation profiles; for a hypervisor, the Server profile applies. Officially tailoring the recommendations to your context goes through a CIS SecureSuite membership.

Proxmox VE 9 is based on Debian 13 “trixie”, so the Debian 13 benchmark is the one to use. For a cluster still on Proxmox VE 8, use the Debian 12 benchmark.

Why CIS Debian is not enough as is

A Debian benchmark describes a generic Debian server. A Proxmox VE node differs on structural points:

/etc/pve is a user-space file system based on FUSE, replicated in real time to all nodes through corosync: disabling FUSE to reduce the attack surface breaks Proxmox VE;
the nodes of a cluster talk to each other over SSH, with the keys in /etc/pve/priv/authorized_keys;
Proxmox VE has its own firewall, which generates the host’s rules;
the default local storage, in /var/lib/vz, holds ISO images, container templates and backups that the hypervisor must be able to use.

Applying Level 1 “as is” with a script can therefore break Proxmox VE on these points. On the Proxmox forum, an administrator reports roughly 75% compliance measured with Wazuh on a host hardened along CIS Debian, with false positives, before even configuring the firewall; the thread contains no official reply from Proxmox.

CIS recommendations to adapt on Proxmox VE

The community Proxmox-Hardening-Guide (HomeSecExplorer) lists the exceptions to plan for. The numbers below are those it cites for CIS Debian 13 version 1.0.0; check the mapping in the version you apply.

Root SSH login (§ 5.1.21). Do not forbid it on a cluster: the guide says not to set PermitRootLogin no and to apply the compensating measures it describes instead. Limiting root to keys (prohibit-password) and filtering SSH to the management network, as in our checklist, go in that direction.
SSH forwarding (§ 5.1.8, DisableForwarding). Set aside on a cluster, with a documented compensating measure.
File system modules (§ 1.1.1.11). Do not disable fuse, which Proxmox VE needs, nor file systems you actually use, such as ceph.
Host firewall (section 4). When the Proxmox VE firewall is enabled, it replaces the benchmark’s host firewall controls: do not manage the same rules with two tools.
Partitions. The guide recommends a dedicated file system for /var/lib/vz, without noexec, since hooks and maintenance tools may need to run from it.

What CIS does not cover

The benchmark stops at the operating system. The whole Proxmox VE layer must be checked separately:

Proxmox VE accounts, realms, roles, ACLs, second factor and API tokens (pveum);
Proxmox VE firewall rules for the host and guests, management IPSet;
corosync redundancy and cluster network separation;
Proxmox VE repositories and version consistency across nodes;
unprivileged containers, bind mounts, guest protection;
backups, client-side encryption to Proxmox Backup Server, tested restores.

The Proxmox VE hardening checklist covers these points with their commands, and the Proxmox VE security audit guide explains how to verify them.

A method that holds in production

Pick the benchmark and level. Debian 13 for Proxmox VE 9, Server profile, Level 1 first; the community guide says the same (“Level 1 first”).
Apply it on a test node. Keep out-of-band console access or an open SSH session, and a backup of the configuration.
Measure. Run a CIS-compatible assessment tool and record the score before and after; keep each report, dated, to show the auditor how things progressed.
Check Proxmox VE. Web interface, migration, replication, backup and restore must all work before moving to the next node.
Roll out node by node. A cluster whose nodes are not hardened the same way becomes hard to troubleshoot.
Move to Level 2 one recommendation at a time, once the impact of each is understood.

Documenting deviations: the exception register

An auditor does not expect 100%: they expect every recommendation you did not apply to be explained. For each exception, record:

the recommendation number and benchmark version;
the Proxmox VE-specific reason (for example, SSH between nodes);
the compensating measure in place, and how to verify it;
the owner and the date of the next review.

Example entry, for root SSH login:

Recommendation : 5.1.21, CIS Debian 13 v1.0.0
Reason         : SSH between the nodes of the Proxmox VE cluster
Compensation   : root limited to keys (prohibit-password), SSH filtered
                 by the management IPSet, keys of former nodes removed
                 from /etc/pve/priv/authorized_keys
Verification   : sshd -T, pve-firewall status
Owner          : infrastructure team; quarterly review

This register also serves as NIS2 evidence, under configuration management: see Proxmox VE and NIS2: what evidence to provide.

What about virtual machines and Proxmox Backup Server?

Hardening the host does not cover the guests: each guest operating system (Debian, Ubuntu, Windows Server…) falls under its own CIS benchmark, to be applied and measured separately. ProxTrace does not see inside virtual machines; it sees their configuration on the Proxmox VE side, such as the QEMU guest agent, protection against removal or the firewall on their interfaces.

The same reasoning applies to Proxmox Backup Server, which is also built on Debian: the community guide has separate guides for it.

Existing tools

Proxmox-Hardening-Guide: guides for Proxmox VE 9 and 8 and Proxmox Backup Server 4 and 3, licensed CC BY 4.0, organised in three levels and tied to the CIS Debian benchmark. The project describes itself as under active development and flags controls not yet validated: treat it as a working basis, not an official reference. It is not supported by Proxmox.
PegaProx has announced, since version 0.9.1.1, a CIS audit and vulnerability scanning, along with a feature that applies hardening. Before using it on a cluster, check which recommendations it applies and which it sets aside.
Generic assessment tools, such as Wazuh mentioned on the forum, measure the Debian host; they do not know the Proxmox VE-specific exceptions and will report expected deviations.

What ProxTrace adds

ProxTrace does not assess the CIS Debian benchmark line by line and applies no hardening: its agent installed on the nodes only reads. It complements a CIS audit where the latter stops:

its 115 Proxmox VE best-practice checks cover the Proxmox VE layer (accounts and roles, second factor, tokens, firewall, cluster, storage, backups, containers) and part of the host judged against CIS Debian values (SSH policy, kernel parameters, /dev/shm and /tmp mounts, kernel modules, core dumps, AppArmor, auditd, fail2ban, PAM lockout, password quality and lifetime, TMOUT, banners, permissions of sensitive files and logs, AIDE, disk encryption, repositories, critical services, log persistence), re-evaluated every five minutes;
change history with before and after values shows when an exception was introduced or a setting undone, and by whom;
sealed reports keep a date’s state exactly as it was assessed.