Proxmox VE compliance and NIS2: what evidence to provide

What NIS2 asks for

Directive (EU) 2022/2555, known as NIS2, applies to essential and important entities across many sectors. Three articles shape what an auditor or authority will expect:

Article 21: cybersecurity risk-management measures, including a minimum list of ten points (a to j), from access control to backups to multi-factor authentication.
Article 20: management bodies approve these measures, oversee their implementation, can be held liable and must follow training.
Article 23: a significant incident triggers an early warning within 24 hours, an incident notification within 72 hours, then a final report no later than one month after the notification.

For certain digital entities, including cloud computing, data centre and managed service providers, Implementing Regulation (EU) 2024/2690 details these measures. Its annex speaks directly to a Proxmox VE administrator: monitoring and logging (3.2), backup and redundancy (4.2), configuration management (6.3), change management (6.4), patch management (6.6), privileged accounts (11.3), multi-factor authentication (11.7) and asset inventory (12.4).

In France, as of 12 October 2026, the directive has not yet been transposed: the bill on the resilience of critical infrastructure and the strengthening of cybersecurity, passed by the Senate on 12 March 2025, was due before the National Assembly on 7 October 2026; that debate was postponed with no new date. The technical measures below do not depend on that timetable.

From measures to Proxmox VE evidence

Not every point of Article 21 concerns the hypervisor. Risk analysis (a), supply chain security (d), assessing the effectiveness of measures (f) and training (g) are organisational first. The others have concrete evidence in Proxmox VE.

Access control and privileged accounts (point i)

Expected evidence: the list of accounts, their roles and effective rights at a given date, and the record of their changes.

pveum user list --full
pveum acl list
pveum user permissions john@pve --path /

Keep these outputs, dated, at each access review, and justify every account holding Administrator on /.

Multi-factor authentication (point j)

pveum user tfa list

Expected evidence: every administrative account has a second factor. If a second factor is enforced at realm level, keep the realm configuration as well.

Technical accounts and API tokens

pveum user token list monitoring@pve
pveum user token permissions monitoring@pve grafana

A token is privileged access like any other: its owner, its rights and its expiry date belong in the access review.

Business continuity and backups (point c)

Expected evidence: backup jobs (/etc/pve/jobs.cfg), their retention (prune-backups), the result of recent runs and, above all, tested and dated restores. A configured job does not prove that a restore works.

pvenode task list --typefilter vzdump --errors

Maintenance and patches (point e)

Expected evidence: the configured repositories (/etc/apt/sources.list.d/*.sources) and the date of each node’s updates, done with apt full-upgrade. A lasting version gap between nodes needs an explanation.

Configurations and changes (point e; regulation, 6.3 and 6.4)

Expected evidence: a reference configuration for hosts and guests, and a controlled record of each change. Guest configurations are text files in “option: value” format on the cluster file system: /etc/pve/qemu-server/<VMID>.conf for VMs, /etc/pve/lxc/<CTID>.conf for containers. Copying them regularly and comparing versions gives a baseline; these files still do not say who made a change or why. A change procedure (request, approval, implementation, verification) links each observed deviation to a decision, and that link is what an auditor will look for.

Cryptography (point h)

Expected evidence: the web interface certificate (pvenode cert info) and client-side encryption of backups to Proxmox Backup Server, with where the key is kept outside the cluster.

Asset inventory (point i)

Expected evidence: the list of nodes, VMs and containers with their role and owner. pvecm nodes lists cluster members; the guest inventory must be matched with what the guests host, which Proxmox VE does not know.

Network security

Expected evidence: firewall state (pve-firewall status), the content of the management IPSet and the restrictions on web interface access. The Proxmox VE hardening checklist details these settings and their precautions.

Incidents: rebuilding the timeline

Notifying within 72 hours means finding out quickly what happened. On Proxmox VE, each node’s task history gives who started what and when. Here, since 5 October 2026 at 00:00 UTC (seconds since the Unix epoch):

pvenode task list --since 1791158400 --userfilter john@pve
pvenode task log <UPID>

What is missing is the changed value and its previous value: you will know a machine was reconfigured, not what changed. The Proxmox VE change history guide covers this gap.

Making evidence admissible

Dated: command output without a date proves nothing about the period under review.
Retained: do not rely on a node’s task history to cover the whole review period; export what you will need.
Comparable: an auditor asks for the state at two dates and what changed in between.
Tied to a measure: each piece of evidence answers a point of Article 21 or of your internal policy; otherwise it is just one more document.

The Proxmox VE security audit guide gives the full method to produce these records node by node.

The file to prepare for the auditor

For each review period, a Proxmox VE evidence file fits in a few items, each dated and tied to its point of Article 21:

the list of accounts, ACLs and effective rights of administrative accounts, at the start and end of the period;
the list of second factors and of API tokens, with their owner and expiry;
backup jobs, their retention, their failures over the period and the report of at least one real restore;
the configured repositories and the update dates of each node;
the state of the firewall and of the management IPSet;
the inventory of nodes and guests, with their role and owner;
the list of changes over the period, each linked to an approved request.

The first six items can be produced with the commands above; the seventh is the one native logs cannot rebuild on their own.

What ProxTrace brings, and what it does not cover

ProxTrace turns these one-off records into continuous evidence for the Proxmox VE part:

change history with before and after values, which supports change management and incident reconstruction;
for the access review (point i), changes to Proxmox VE users, groups, roles and permissions (ACL), detected from one collection to the next with the before and after state, and notified: the record Proxmox VE does not keep itself;
115 Proxmox VE best-practice checks (accounts and roles, second factor, tokens, SSH, firewall, repositories, backups…) re-evaluated every five minutes, with four statuses including “Not assessable”: missing data is never counted as a success;
a framework view that links these checks to the ten measures of article 21.2, ISO 27001 annex A and the CIS Controls, requirement by requirement, with an export for the audit file;
sealed reports, which keep a date’s state exactly as it was assessed, and their export from the console;
a read-only agent on the nodes, which changes nothing.

ProxTrace does not cover risk analysis, notification to authorities, supplier security, training, or what happens inside virtual machines. It does not make an organisation meet NIS2: it provides part of the material the organisation will have to present.

What this page is not

This page is a technical guide, not legal advice. The exact scope of your obligations depends on your sector, your size and the applicable national law; in France, follow ANSSI publications and the progress of the bill.