NIS2 Cyber Hygiene: ‘Password’ Appears 0 Times in the CIR, ‘Phishing’ Only in a Recital — a 16-Practice Map to the Binding Annex Points

NIS2 makes cyber hygiene a binding duty but never defines it. Article 21(2)(g) of the Directive requires “basic cyber hygiene practices and cybersecurity training” and goes no further. Implementing Regulation (EU) 2024/2690, which sets the detailed rules for eleven types of digital provider, doesn’t define the term either. Its Recital 20 says hygiene practices “are a part of different technical and methodological requirements” across the Annex. So most of the practices people call hygiene are spread across the Annex instead of sitting in one section. We searched the full English text of the Regulation: “password” appears 0 times, and “phishing” appears twice, both in a recital. The rules are still there. Credential changes are in point 11.6.2(c), patching in 6.6, removable media in 12.3 and backups in 4.2. Section 8, the one titled “basic cyber hygiene”, covers the people side.

This hub maps 16 hygiene practices, drawn from the Directive’s recitals, the Regulation’s recitals and ENISA’s guidance, to the Annex point that enforces each one. For each it gives the wording that decides how firm the duty is, and the evidence an auditor can ask for. Training has its own deep dive in NIS2 cybersecurity training requirements.

This article provides general information only and does not constitute legal advice. NIS2 implementation varies by member state and sector — always verify requirements against your national transposition law and applicable authority guidance.

Who the Annex Map Binds — and Who Uses It as a Benchmark

In plain terms: every essential and important entity owes the hygiene duty. But the detailed Annex points are directly binding on only eleven provider types. Everyone else gets the duty through national law and can use the Annex as a well-documented benchmark.

Your organisation	Legal source of the hygiene duty	Status of the Annex points below
DNS service provider, TLD registry, cloud, data centre, CDN, managed service provider, managed security service provider, online marketplace, search engine, social network or trust service provider	Article 21(2)(g) NIS2 plus Implementing Regulation 2024/2690, Articles 1–2 and Annex	Directly binding. If you skip a point marked “where appropriate”, you must document your reasons (Article 2(2))
Any other essential or important entity (energy, health, transport, manufacturing, etc.)	Article 21(2)(g) NIS2 as transposed into your national law	Reference, not law at EU level. Article 21(5) says the Commission “may” adopt rules for these sectors. Your national law or authority may set its own detail
Organisation outside NIS2 scope	None under NIS2	Good practice only. Often requested anyway by NIS2-covered customers through supplier clauses

What failure costs is set out in the Directive. Under Article 21(4), an entity that finds it doesn’t comply must take corrective measures “without undue delay”. Under Article 34(4)–(5), national fine ceilings for breaching Article 21 must reach at least €10 million or 2% of worldwide turnover for essential entities, and €7 million or 1.4% for important entities. Under Article 20(1), management bodies approve the measures, oversee them and “can be held liable”. Actual amounts are subject to national implementing law and the authority’s discretion.

Note: national transposition laws can add hygiene detail, reference frameworks or reporting expectations. Confirm with your national competent authority.

Two Meanings of “Cyber Hygiene” — and Why Section 8 Only Holds One

In plain terms: ENISA splits the term in two. Hygiene for the organisation is the baseline of technical controls, and it is already spread across the Annex. Hygiene for users is the routine behaviour of staff, and that is what Section 8 governs.

The split comes from the glossary of ENISA’s NIS2 Technical Implementation Guidance (version 1.0, June 2025). It says hygiene practices for essential and important entities are “already covered by the technical and methodological requirements” of the Annex, so “no additional guidance … is deemed necessary”. Hygiene practices for users are “routine, proactive practices and behaviours”, and those go into the awareness programme under point 8.1.

That reading is the key to the whole map. A patching SLA isn’t a Section 8 obligation. It is point 6.6, under Article 21(2)(e). Staff knowing how to report a suspicious email is a Section 8 obligation. If you put both into one “hygiene policy” and file it under 21(2)(g), the auditor will look for the patching evidence in the wrong place.

The practices themselves come from three non-binding lists. The Directive’s recitals on legislative intent supply two of them. Recital 49 lists software and hardware updates, password changes, the management of new installs, limiting administrator-level accounts and backing up data. Recital 89 adds zero-trust principles, device configuration, network segmentation, identity and access management, user awareness, and threats such as phishing and social engineering. The Regulation’s Recital 20 adds practices for users: a clear desk and screen policy, multi-factor authentication, safe email use and web browsing, and secure remote working. ENISA’s list under 8.1.2 is “indicative, non-exhaustive”, and it adds event reporting, mobile device use and connected vehicles.

Recitals explain intent; they don’t create obligations. The obligation is wherever the Annex says “shall”.

The Map: 16 Hygiene Practices and the Annex Point That Enforces Each

In plain terms: find the practice, read the Annex point and how firm its wording is, then check you hold the evidence. The table covers the provider types the Regulation binds. Other entities can use it as a benchmark (see the scope table above).

Hygiene practice (where it’s named)	Binding Annex point	How firm the wording is	Evidence to hold
1. Software updates (NIS2 Rec. 49, 89; CIR Rec. 20)	6.6.1: security patches applied “within a reasonable time”, tested, from trusted sources	Shall. 6.6.2 allows skipping a patch only with documented, substantiated reasons	Patch procedure, deployment records, signed exceptions
2. Password changes (NIS2 Rec. 49)	11.6.2(c): credentials changed “initially, at predefined intervals and upon suspicion” of compromise	Shall, with no qualifier	The stated interval, change logs
3. Managing new installs (NIS2 Rec. 49)	6.3.2(b): enforce secure configurations “for newly installed systems”; 6.9.2: prevent unauthorised software	Shall	Build baselines, allow-list or software-control settings
4. Limiting administrator accounts (NIS2 Rec. 49)	11.3.2(b)–(d): dedicated admin accounts, privileges restricted “to the highest extent possible”; 11.2.2(a): least privilege	Shall	Privileged account list, review records (11.3.3)
5. Backing up data (NIS2 Rec. 49)	4.2.1–4.2.6: backup plans, copies “not in the same network”, integrity checks, recovery tests	Shall	Backup plan, integrity-check and restore-test results
6. Zero-trust principles (NIS2 Rec. 89; CIR Rec. 20)	6.2.2(b): “zero-trust architectures” named only as an example of secure engineering	Shall apply secure engineering principles; zero trust itself is an example	Secure development rules
7. Device configuration (NIS2 Rec. 89)	6.3.1–6.3.3: documented security configurations for hardware, software, services and networks	Shall; review at planned intervals	Configuration baselines, review dates
8. Network segmentation (NIS2 Rec. 89)	6.8.1–6.8.3: zones based on risk, separate admin network, production kept apart from development and testing	Shall	Network zone diagram, access rules
9. Identity and access management (NIS2 Rec. 89)	11.1–11.2 and 11.5: access policy, rights management, unique identities linked to a single person	Shall	Access control policy, access reviews
10. User awareness (NIS2 Rec. 89)	8.1.1–8.1.3: programme for employees, management bodies and, where appropriate, direct suppliers	Shall; effectiveness testing “where appropriate”	Programme outline, materials, attendance records
11. Phishing and social engineering (NIS2 Rec. 89; CIR Rec. 20)	No named point. Covered by 8.1.2(c) “relevant cyber threats” and 8.2.3(b) “known cyber threats”	Implied by the shall-duties to cover threats	Module content showing phishing is covered
12. Multi-factor authentication (CIR Rec. 20, 23)	11.7.1: multiple factors or continuous authentication; 11.3.2(a): strong authentication “such as” MFA for privileged accounts	“Where appropriate”, by asset classification. Document any decision not to use it	MFA coverage list, documented reasoning for gaps
13. Clear desk and screen (CIR Rec. 20; ENISA)	None. 11.6.2(e), ending inactive sessions, covers only the screen half	Session timeout: shall. Clear desk: policy choice	Session timeout setting
14. Safe email and web use (CIR Rec. 20)	Users: 8.1.2(c). Organisation: 6.7.2(k) plan for modern email standards; 6.9.2 detection software	Shall (6.9.2 detection-and-response software “where appropriate”)	Awareness content, email-standards plan
15. Secure remote working (CIR Rec. 20)	6.7.2(d): controls for remote access; 8.2.3(a): role training on configuration “including mobile devices”	Shall	Remote access controls, role training records
16. Removable media (named in no recital)	12.3.1–12.3.3: technical prohibition unless there is an organisational reason, autorun disabled, media scanned	Shall; encryption on media “where appropriate”	Removable media policy, device-control configuration

Label: the table is our mapping of non-binding recital lists to binding Annex text. The Annex wording is quoted from the Regulation; matching each practice to a point is interpretation.

Five Things the Map Shows That a Generic Hygiene Checklist Hides

In plain terms: once each practice is tied to an exact clause, five details stand out. Each one changes what you should write in your policies.

1. The Regulation never says “password”, yet it rules out “never expire”

Point 11.6.2(c) requires the change of authentication credentials “initially, at predefined intervals and upon suspicion that the credentials were compromised”. It has no “where appropriate” qualifier. That puts covered providers at odds with NIST’s current advice against routine expiry. We cover the conflict and a policy that handles both in NIST password guidelines vs NIS2 access control. The same point also requires lockout after “a predefined number of unsuccessful log-in attempts” (11.6.2(d)) and an inactivity timeout (11.6.2(e)). Neither sets a number, so your policy must.

2. Phishing reaches the Annex only through the word “threats”

Both mentions of “phishing” in the Regulation are in Recital 20. In the Annex, phishing is covered because awareness must cover “relevant cyber threats” (8.1.2(c)) and role training must include “briefing on known cyber threats” (8.2.3(b)). Nothing requires simulated phishing campaigns. Point 8.1.3 says the programme “shall, where appropriate, be tested in terms of effectiveness”. A simulation is one way to test it, not the only one.

3. Removable media gets the strictest hygiene rule, and no recital mentions it

Point 12.3.2(a) requires “a technical prohibition of the connection of removable media unless there is an organisational reason for their use”. Banning by default is a much higher bar than “use USB sticks carefully”. Removable media isn’t in Recital 49, Recital 89, Recital 20 or ENISA’s user list, so it is the item most hygiene checklists leave out. It is filed under asset management, Article 21(2)(i) (see asset management under NIS2).

4. “Reasonable time” for patches is a number you must set

Point 6.6.1(a) asks for patches “within a reasonable time after they become available” and gives no day count. Two things follow. Your procedure needs its own deadlines, usually tiered by severity. And any patch you choose not to apply needs a written, substantiated reason under 6.6.2, plus additional measures and accepted residual risk under 6.6.1(d). Our vulnerability and patch management guide sets out tiered deadlines.

5. Backups: separate network, and recovery that is tested and documented

Point 4.2.2(c) requires copies stored “online or offline” in a location “not in the same network as the system” and far enough away to survive a disaster at the main site. Point 4.2.6 requires regular recovery testing with documented results. Section 4.2 doesn’t require backups to be encrypted. It asks for “physical and logical access controls” in line with asset classification (4.2.2(d)). Your cryptography policy under point 9.2(a) still sets the protection for “data at rest” by classification, and that can extend to backup copies. Details are in NIS2 backup and recovery requirements.

What Section 8 Actually Requires on the People Side

In plain terms: Section 8 asks for two separate things. One is an awareness programme for everyone, including the board and, where appropriate, direct suppliers. The other is role-based training for staff whose jobs need security skills.

• Who: point 8.1.1 covers employees “including members of management bodies, as well as direct suppliers and service providers”. That goes alongside Article 20(2) of the Directive, which requires management-body members to “follow training”. For suppliers, 8.1.2 routes the programme through the 5.1.4 contract point; our guide to bringing supplier staff into your awareness programme follows that chain to a sample clause.
• What: 8.1.2(c) requires coverage of relevant threats, the measures in place, contact points, and “cyber hygiene practices for users”.
• When: 8.1.2(a) requires activities “scheduled over time” that are repeated and reach new employees. 8.1.3 requires updates “at planned intervals”. The Annex doesn’t say “annually” for training.
• Who else: 8.2.1 requires “regular training” for roles that need security skills, and 8.2.3 requires its effectiveness to be assessed. Point 8.2.2 wants those roles chosen “based on criteria” it never defines; our role-based security training guide supplies six tests and a matrix for helpdesk, finance, OT and developers.
• Link to HR: point 10.1.2(a) requires mechanisms to ensure that staff and, where applicable, suppliers “understand and follow the standard cyber hygiene practices” defined under 8.1. This is the only place outside Section 8 where the Annex says “cyber hygiene”.

ENISA suggests the evidence: a programme outline covering objectives, content, frequency, syllabus and schedule, plus copies of materials and attendance records. Its AR-in-a-Box package, which includes an SME edition, is a reasonable starting library. To compare what a training platform proves against what you have to write yourself, see awareness training platform vs policy template.

Role by Role: What to Do With the Map

In plain terms: the same 16 rows mean different work for different people.

Role	What the map changes	First action
CISO / IT security manager	Most hygiene evidence lives under 6.x, 11.x, 12.3 and 4.2, not under 21(2)(g)	File each control’s evidence under the Annex point in the table, not in one “hygiene” folder
SME owner	In our view, five rows (patching, credentials, backups, admin accounts, MFA) give the most protection for the effort	Write down a patch deadline, a credential-change interval and a backup restore test date
Compliance officer / legal	“Where appropriate” points need documented reasons when you don’t apply them (CIR Article 2(2))	Keep a short register of every qualified point you decided not to apply, and why
Board / management body	Article 20 makes approval and oversight personal, and 8.1.1 puts board members inside the awareness programme	Attend the training yourselves and minute your approval of the measures

Building a Hygiene Evidence File in Six Steps

In plain terms: this is a practical sequence (our recommended internal practice, not legal text) for turning the map into something an auditor can follow.

1. Confirm your legal route (effort: Low). Are you one of the eleven provider types in CIR Article 1? Check our Implementing Regulation guide. If you aren’t, read your national law first.
2. Gap-check the 16 rows (effort: Medium). For each practice, compare where you are with the Annex point, and mark it Low, Medium or High effort to close.
3. Turn the undefined values into your own numbers (effort: Low). Patch deadlines, credential-change interval, lockout threshold, session timeout, backup retention. The Annex expects you to set them.
4. Write the qualified-point register (effort: Low). List every “where appropriate” point you don’t apply, with your reasoning in plain language.
5. Separate user hygiene from technical hygiene (effort: Medium). Put the user practices (rows 10–15) into the 8.1 awareness programme. Keep the technical rows in their own policies.
6. Test and record (effort: Medium–High). Backup restores (4.2.6), awareness effectiveness where appropriate (8.1.3), training effectiveness (8.2.3) and the review dates for configurations, segmentation and removable media.

Frequently Asked Questions

What does cyber hygiene mean under NIS2?

The law doesn’t define it. Article 21(2)(g) requires “basic cyber hygiene practices”, and Recitals 49 and 89 give examples such as updates, password changes, backups, segmentation and user awareness. ENISA treats it as two layers: baseline technical controls already spread across the Annex, and routine user behaviour covered by point 8.1.

Is cyber hygiene the same as security awareness training?

No. Article 21(2)(g) names them together, but they are two duties. Training is in Annex Section 8. Most technical hygiene, such as patching, credentials and backups, sits under other Article 21(2) points.

Does NIS2 require password expiry?

For the eleven provider types bound by the Regulation, point 11.6.2(c) requires credential changes “at predefined intervals”. For other entities it is a risk-based decision under national law.

Are phishing simulations mandatory?

No. The Annex never names them. Point 8.1.3 requires effectiveness testing of the awareness programme “where appropriate”, and a simulation is one way to do it.

How often must awareness activities be repeated?

At “planned intervals”, repeated over time and including new employees (8.1.2(a), 8.1.3). No annual rule exists in the Annex for training. Your national authority may expect a specific cadence.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

How This Guide Was Verified

We searched the official English texts of Directive (EU) 2022/2555 and Implementing Regulation (EU) 2024/2690 on 9 October 2026. That search produced the word counts above. For example, “cyber hygiene” appears 10 times in the Regulation: 4 times in Recital 20 and 6 times in the Annex. ENISA’s guidance was read in its full June 2025 PDF. Matching each practice to an Annex point is our interpretation and is labelled as such.

Sources

1. Directive (EU) 2022/2555 (NIS2): Articles 20, 21 and 34(4)–(5), and Recitals 49 and 89 — EUR-Lex
2. Commission Implementing Regulation (EU) 2024/2690: Articles 1–2, Recitals 20 and 23, and Annex points 4.2, 6.2, 6.3, 6.6–6.9, 8.1–8.2, 9.2, 10.1, 11.1–11.3, 11.5–11.7 and 12.3 — EUR-Lex
3. ENISA, NIS2 Technical Implementation Guidance, version 1.0, June 2025 (point 8.1 and Annex II glossary)
4. ENISA, AR-in-a-Box awareness-raising package