NIS2 and privileged access: what the auditor will ask you to show

In a compliance audit, one simple question often catches an organisation off guard: "Who logged in with the production server's admin account last Tuesday, and what did they do?" When the answer is silence, the problem is no longer only technical. It becomes a compliance finding.

A scenario we see regularly

Take a mid-sized organisation that has been covered by NIS2 since the Belgian law of 26 April 2024 came into force. Its IT looks in good shape: firewall up to date, antivirus deployed, backups tested. Yet a review of privileged access reveals a familiar picture.

The domain "admin" account is shared by three in-house technicians. The password of an industrial device has not changed since it was installed. Two maintenance contractors connect over VPN with credentials emailed years ago, one of them for a contract that has ended. And no recording shows what was done during those connections.

None of this is spectacular negligence. It is the ordinary build-up of practical decisions taken over time. But from an auditor's point of view, each of these items is a finding.

What the text says

Article 21(2) of the NIS2 Directive sets out a baseline of risk-management measures. Several of them bear directly on privileged access: access control and asset management policies (point i), the use of multi-factor authentication (point j), supply chain security, including relationships with service providers (point d), and incident handling (point b), which presupposes being able to reconstruct what happened.

In Belgium, the Centre for Cybersecurity Belgium's CyberFundamentals (CyFun) framework turns these requirements into concrete measures that an organisation can use to show it has taken appropriate and proportionate steps. ISO/IEC 27001:2022 covers the same ground, notably through its controls on privileged access rights and logging.

What the auditor will want to see

An auditor will not settle for a written policy. They ask for verifiable evidence. In practice, five items come up almost every time:

• an inventory of privileged accounts, each with a named owner;
• evidence that MFA is enforced on those accounts, not just enabled for email;
• a record of administrative sessions: who, on which system, when, and ideally what was done;
• a process for contractors: time-limited access, revoked at the end of the contract, with no shared password;
• a periodic review of those rights, dated and documented.

The item most often missing is the third. System logs sometimes show that a connection took place, rarely what happened next. Yet that is exactly the information that is lacking on the day an incident has to be analysed.

The bastion as a structural answer

The most effective way to close these gaps consistently is to route all administrative access through a single control point: a privileged access management (PAM) bastion. Users authenticate there with a second factor, can only reach the systems their role allows, and every session is recorded.

Such tools were long reserved for large organisations because of licence costs. Open-source options such as Vauban change that: the code can be audited, the tool runs on the organisation's own infrastructure, and the budget goes into deployment rather than licences.

The tool is not enough on its own. You first need to know which accounts to protect, decide who may access what, and then organise the review of rights. But once in place, it provides several pieces of the evidence an auditor expects in one go.

Key takeaways

Privileged access concentrates risk: it is what an attacker looks for, and what an auditor examines first. Before a NIS2 or CyFun audit, the useful question is not "do we have an access policy?" but "can we show, with evidence, who accessed our critical systems and what they did there?".

Cyber Praxis carries out CyFun audits and helps put these controls in place, from the inventory of access rights to the bastion.