NIST Password Guidelines vs NIS2 Access Control: Annex 11.6.2(c) Contradicts ‘Never Expire’

Search the regulation that spells out NIS2’s technical security requirements and you will not find the word “password”. Not once. Commission Implementing Regulation (EU) 2024/2690 contains zero occurrences of “password”, “passphrase”, “character”, “minimum length”, “complexity”, “blocklist”, “phishing-resistant” or “password manager” [1]. The parent Directive uses “password” exactly once, in Recital 49 — an interpretive recital that creates no obligation [5].

The regulation does bind one rule about credentials, and it is close to the one rule NIST’s current guidance tells verifiers never to implement. Annex point 11.6.2(c) requires relevant entities to “require the change of authentication credentials initially, at predefined intervals and upon suspicion that the credentials were compromised” [1]. NIST SP 800-63B-4 states: “Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically” [2].

Most articles on NIS2 passwords reproduce NIST’s advice — drop rotation, use 15 characters — and present it as the EU requirement. That is good security, but it is not what the binding text says, and a policy that copies it without addressing 11.6.2(c) has an unexplained gap. Here is what each instrument binds, where they collide, and the wording that survives both.

Which Instrument Actually Binds You

In plain terms: three documents are in play and only two create obligations. The Directive sets the measure headings. The Implementing Regulation turns them into technical requirements, but only for eleven named types of entity. ENISA’s guidance explains implementation and is explicitly advisory.

Article 21(2)(i) of the Directive requires “human resources security, access control policies and asset management”, and Article 21(2)(j) requires multi-factor or continuous authentication “where appropriate” [5]. Neither says anything about how a password should be built. Our guide to NIS2 access control and human resources security covers the Article 21(2)(i) obligations in full.

Instrument	Who it binds	What it says about credentials
Directive (EU) 2022/2555 (NIS2)	All essential and important entities, via national transposition	Art. 21(2)(i) and (j) only — headings, no technical detail. “Password” appears once, in non-binding Recital 49 [5]
CIR 2024/2690 (Implementing Regulation)	Directly binds only the eleven Article 1 categories — DNS, TLD registries, cloud, data centres, CDN, managed service and managed security service providers, online marketplaces, search engines, social platforms and trust service providers [1]	Annex Section 11, headed “(Article 21(2), points (i) and (j))” — the only detailed authentication rules in EU law [1]
ENISA Technical Implementation Guidance v1.0, June 2025 — the current version [6]	Nobody — “not legally binding and is only of an advisory character” [4]	The actual numbers: character minimums, blocklists, phishing-resistant MFA ranking [4]

Outside those eleven categories — a manufacturer, a hospital, an energy operator — the Annex does not bind you directly; your obligations come from your member state’s transposition of Article 21. It is still the best available benchmark for what “appropriate” looks like, so treat it as the standard you will be measured against rather than text that automatically applies. The full CIR 2024/2690 technical requirements guide covers scope in detail.

The Collision: 11.6.2(c) vs “SHALL NOT Change Periodically”

In plain terms: the binding EU text requires scheduled credential changes; NIST’s guidance forbids them. If the Annex applies to you, you cannot adopt the NIST position silently.

11.6.2(c) carries no escape hatch. CIR Article 2(2), second subparagraph, provides that where the Annex qualifies a requirement with “where appropriate”, “where applicable” or “to the extent feasible” and an entity considers it not so, the entity “shall in a comprehensible manner document its reasoning to that effect” [1]. That route is real — it covers 11.7.1 on multi-factor authentication, qualified “where appropriate”, and 11.6.3 on state-of-the-art methods, qualified “to the extent feasible” [1]. It does not cover 11.6.2(c), which is unqualified. There is no documented-reasoning exit from the periodic-change duty.

The compromise trigger also differs. The CIR requires change “upon suspicion” of compromise; NIST requires it where there is “evidence” of compromise [1][2]. Suspicion is the lower threshold, so a policy written to NIST’s standard of proof will under-trigger against the EU text. Write your trigger to suspicion and you satisfy both.

How to resolve it. The clause demands a predefined interval but names none, and no EU instrument does. A long interval — annual, or tied to the access-review cycle the Annex already requires at 11.2.3 and 11.6.4 — satisfies 11.6.2(c) while avoiding what NIST objects to: the 30-to-90-day treadmill that pushes users toward predictable increments. Pair it with event triggers on suspicion of compromise, on termination or role change, and at first login. That is what ENISA’s own guidance describes — the password system should “enforce password changes as necessary, for example after a security incident or upon termination or change of employment”, and “force users to change their passwords at first login” [4]. Notably, ENISA’s implementation bullets for 11.6.2 never propose a calendar interval for user passwords — so the regulation and its own official guidance are not quite aligned, and guidance cannot override a regulation.

Where NIST and the EU Agree — Which Is Most of It

In plain terms: rotation is the outlier. On length, composition, breach screening, password managers and storage the two point the same way — and ENISA cites NIST as the reason.

ENISA’s footnote 96 settles an argument people still have in policy reviews: “Password complexity can be a good cybersecurity practice, but it is not the only factor to consider. Recent guidelines, such as those from NIST, emphasise password length over complexity” [4]. The EU’s own cybersecurity agency points the reader at SP 800-63B — which is the licence to write a length-first, complexity-free policy in a European compliance context, provided you handle 11.6.2(c) separately.

Control	NIST SP 800-63B-4 [2]	EU position [1][4]	Aligned?
Minimum length, single-factor	SHALL be at least 15 characters	ENISA advises 14; the CIR is silent	Near — one character apart
Minimum length, with MFA	SHALL be at least 8 characters	ENISA advises 8	Identical
Maximum length	SHOULD permit at least 64 characters	Silent	No conflict
Composition rules	SHALL NOT be imposed by verifiers	CIR silent; ENISA advises users to “try to include alphanumerical and special characters” as personal selection advice, not a system-enforced rule	Compatible, with care
Breach and common-password screening	Verifiers SHALL compare against a blocklist of known common, expected or compromised passwords	ENISA: prevent “commonly used passwords, and compromised combinations of usernames and password from hacked systems”	Yes — NIST is the stronger verb
Password managers	Verifiers SHALL allow password managers and autofill	ENISA endorses an “approved password vault tool”	Yes
Storage	SHALL be salted and hashed, salt at least 32 bits	ENISA: hash and encrypt per approved cryptographic techniques	Yes — NIST is more specific
Periodic change	SHALL NOT be required	CIR 11.6.2(c): shall be required “at predefined intervals”	No — direct conflict

The 14-versus-15 divergence runs the opposite way to how it is usually reported: the widely repeated “NIS2 requires 15 characters” is NIST’s number, not the EU’s. Use 15 if you want one figure that satisfies both — but if an auditor asks where it came from, the honest answer is NIST via ENISA’s footnote, not the regulation. For the wider framework comparison, see our NIS2 vs NIST CSF 2.0 function-by-function gap map.

Four Requirements NIST Does Not Give You

In plain terms: these clauses catch policies written from US guidance alone. Each binds Article 1 entities and each needs its own paragraph in your document.

1. Authentication strength must track asset classification. Annex 11.6.2(a) requires “the strength of authentication is appropriate to the classification of the asset to be accessed”, and 11.7.2 repeats the test for MFA [1]. Classification is defined at 12.1.2(b), which requires assets to be associated with a level “based on confidentiality, integrity, authenticity and availability requirements” [1]. The consequence is structural: without a classification scheme, an authentication policy has no defensible basis for treating any account differently from any other.

2. Lockout must reset credentials, not just block. Annex 11.6.2(d) requires “the reset of authentication credentials and the blocking of users after a predefined number of unsuccessful log-in attempts” [1]. NIST instead rate-limits to no more than 100 consecutive failed attempts and disables the authenticator, 100 being an upper bound agencies may lower [2]. The EU clause bundles a forced credential reset into lockout, which NIST does not require — and an attacker can trigger it by deliberately failing logins, so pair it with NIST’s rate-limiting and bot-mitigation techniques rather than a bare counter.

3. Inactive sessions must terminate. Annex 11.6.2(e) requires entities to “terminate inactive sessions after a predefined period of inactivity” [1]. Again no number is given — you set it, document it, apply it consistently.

4. Privileged accounts need separate credentials. Annex 11.6.2(f) requires “separate credentials to access privileged access or administrative accounts” [1], reinforced by 11.3.2(a) on “strong identification, authentication such as multi-factor authentication, and authorisation procedures” for those accounts [1]. Sharing one credential between a daily-driver and an admin account breaches this directly. Related: 11.5.3 permits shared identities only where necessary and only “subject to an explicit approval process and documentation” [1], so every service account and break-glass credential needs a written approval record. Our guide to NIS2 MFA and secure communications requirements covers the Article 21(2)(j) side in depth.

What Your Password Policy Should Actually Say

In plain terms: nine clauses, each mapped to an Annex point so an auditor can trace your document to the regulation without interpretation.

Annex point	What to write	Effort	Audit evidence
11.6.2(a), 11.7.2, 12.1	Minimum length by classification tier — e.g. 15 characters single-factor, 8 where MFA is enforced	High — needs a classification scheme first	Classification scheme plus the tier table
11.6.2(a)	No system-enforced composition rules; length and blocklist screening instead	Low	Identity provider configuration export
11.6.2(c)	Predefined interval stated explicitly, aligned to the access-review cycle, plus first-login change	Low	The stated interval and dated change logs
11.6.2(c)	Event triggers: on suspicion of compromise, on termination or role change, on shared-identity exposure	Medium	Incident records showing the trigger fired
11.6.2(b)	Issuance and handling process for secret authentication information, including advising personnel	Medium	Process document and acknowledgements
11.6.2(d)	Failed-attempt threshold, blocking, and credential reset — all three named	Low	Lockout policy configuration
11.6.2(e)	Session inactivity timeout, stated as a number	Low	Session configuration
11.6.2(f), 11.3.2	Separate credentials for privileged and administrative accounts, with MFA	Medium	Privileged account register
11.5.3	Shared-identity approval process and documentation	Medium	Approval records per shared identity

The three roles that own this read the table differently. The CISO owns rows 1, 2, 6 and 7 — identity-provider settings, gated by the classification scheme in row 1, which usually does not exist yet. The compliance officer owns rows 3, 4, 5 and 9: none is a technical control, all are documentary duties, and these fail audits quietly because nobody was assigned to write them. An SME owner without a security function should start with rows 3, 6, 7 and 8 — configuration changes in one identity provider — then treat row 1 as a project, not a policy edit.

One drafting note. ENISA recommends phishing-resistant MFA and ranks the options: “Strong” for FIDO and W3C WebAuthn or X.509 PKI, “Medium” for push notification or number matching, “Last resort” for SMS or email one-time passcodes [4]. The CIR Annex says nothing about phishing resistance — another term returning zero hits [1]. Naming SMS as an acceptable second factor is compliant with the regulation and at odds with the guidance: defensible, but make it deliberately.

Frequently Asked Questions

Does NIS2 require a 15-character minimum password? No EU instrument states 15. NIST requires 15 for single-factor use [2]; ENISA’s advisory guidance suggests 14 without MFA and 8 with it [4]. The binding regulation states no length at all [1].

Do I have to expire passwords under NIS2? If you are one of the eleven entity categories in CIR Article 1, yes — Annex 11.6.2(c) requires change at predefined intervals and is not qualified [1]. Other entities should check their national transposition. A long interval aligned to your access-review cycle satisfies the clause without short-cycle rotation.

Can I use “where appropriate” to opt out of periodic change? No. CIR Article 2(2), second subparagraph, only permits documented reasoning where the Annex itself uses “where appropriate”, “where applicable” or “to the extent feasible” [1]. Point 11.6.2(c) uses none of those. The route is open for 11.7.1 on MFA, not for the change interval.

Is ENISA’s technical guidance binding? No — it is “not legally binding and is only of an advisory character” [4]. It is the best available interpretation from the EU’s own agency and useful in a policy rationale, but it cannot relax the regulation.

Which version of the NIST guidance should I cite? SP 800-63B-4, published July 2025, superseding the March 2020 SP 800-63B [3]. Policies citing the 2017 or 2020 revisions are out of date.

The Short Version

The binding EU text is thinner than the market says and stricter in one specific place. It sets no password length, bans no composition rule and mandates no blocklist — all of that lives in advisory guidance or in NIST. But it does require credential change at predefined intervals, with no qualifier and therefore no documented-reasoning exemption, on a suspicion trigger rather than an evidence trigger.

So write the policy NIST would endorse — long passwords, no composition theatre, blocklist screening, password managers allowed, no 60-day treadmill — then add the two clauses NIST would never have prompted: a stated predefined interval, and a suspicion-level compromise trigger. Anchor every clause to its Annex point. A policy an auditor can trace line by line to 11.6.2 is worth more than one that is merely modern.

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.

Sources

1. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex. Article 1 scope, Article 2(2), and Annex Sections 11 and 12.
2. NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management — National Institute of Standards and Technology. Sections 3.1.1 and 3.2.2.
3. SP 800-63B-4 publication record — NIST Computer Security Resource Center. Publication date and superseded revision.
4. Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0 (June 2025) — ENISA. Section 11.6 guidance, footnotes 95 and 96.
5. Directive (EU) 2022/2555 (NIS2) — EUR-Lex. Article 21(2) and Recital 49.
6. NIS2 Technical Implementation Guidance — ENISA publication record. Current version confirmation.