NIS2 and credential security: what Article 21 actually requires, and how you prove it works

NIS2 moved credential security from a “good practice” to a legal obligation. In Romania, Directive (EU) 2022/2555 is transposed through GEO 155/2024 and Law 124/2025, with DNSC as the authority (details on scope, deadlines and penalties in our article NIS2 in Romania). But the law does not tell you what to buy. It tells you what outcomes to achieve. That difference is the whole subject below.

This material is informational, not legal advice: for your specific situation, check with DNSC and a consultant.

What Article 21 actually requires

Article 21 lists minimum risk-management measures, proportionate to exposure. For credentials and access, the relevant ones are:

• basic hygiene and training for staff (21(2)(g)), including how passwords are created, used and changed;
• access control, human resources security and asset management (21(2)(i)), who has access to what, for how long, and the inventory of what must be protected;
• multi-factor or continuous authentication, where appropriate (21(2)(j));
• cryptography and encryption policies (21(2)(h)), relevant to how secrets are stored, not just traffic;
• procedures that assess whether the measures work (21(2)(f)), the part most people ignore.

Notice what is missing: the name of any product. The law describes properties of your system, not a shelf in a store.

“Where appropriate” does not mean “optional”

The “where appropriate” wording on MFA is often misread as a loophole. It is not. It means proportionality: you decide where risk justifies the control, but the decision must be a conscious, documented, defensible one.

On an internet-facing access or a privileged account, the absence of MFA is hard to justify in front of an incident. Cost can sequence the rollout in time, it can defer a low-risk segment, but it cannot be the excuse for a critical access left on a plain password. The question you must have an answer to is not “do you have MFA everywhere?”, it is “can you show why you put MFA here and not there?”.

Secrets are not just people’s passwords

When they hear “credentials”, many organizations think of employee passwords. The dangerous part is elsewhere: API keys, tokens, service accounts, SSH keys and certificates. These are credentials that often carry more rights than any human user, live in config files, environment variables, scripts and version history, and do not expire on their own.

The access control and asset management in Article 21 include them explicitly. You cannot protect what you do not know exists, so the first step is an inventory: what secrets you have, where they live, who uses them and for what. A secret forgotten in a repository or a config file is exactly the kind of access opportunistic groups look for first.

The proof that it works, not just the policy

Here is the core, and in fact the thesis we keep repeating: a control you cannot demonstrate is, to an auditor, a control that does not exist. Article 21(2)(f) requires procedures that assess the effectiveness of the measures. In practice, at a DNSC inspection it does not matter that you have a password policy in a document, it matters that you can show:

• access logs proving who got in, where and when;
• review dates for rights, with evidence that unnecessary access was removed;
• recorded exceptions, with reason and deadline, not silent derogations.

A policy with no evidence is a claim. The evidence turns it into a control. We developed this idea separately, because it holds beyond NIS2, in the control that passes the test.

What to do concretely, proportionate to risk

Without buying anything specific, the order that survives an inspection:

1. Inventory credentials and secrets, human and technical, and where they live.
2. Apply least privilege and review rights periodically, with evidence of the review.
3. Put MFA on exposed and privileged access first, then extend, documenting the decisions.
4. Take secrets out of code and config files and treat them as managed assets.
5. Log access and rotate credentials, especially after departures (see also the person who leaves).
6. Collect the evidence as you work, not the day before an audit.

What we take away

NIS2 does not ask you for a product, it asks you for a verifiable property: access is controlled, authentication matches the risk, secrets are managed, and all of it can be demonstrated. Whoever reads Article 21 as a shopping list misses the point. Whoever reads it as a list of outcomes they must be able to prove ends up both compliant and actually safer.

Want to know where you stand against the NIS2 requirements on access control and credentials, and what to fix first? Contact us and we start from an audit.

Sources

• EUR-Lex: Directive (EU) 2022/2555 (NIS2), Article 21
• DNSC, Romanian National Cyber Security Directorate
• ENISA: implementation of NIS2 technical measures