ImplementationNIS2DORAISO 27001

How to Create an Effective Password Policy

13 minUpdated 2026-03-18

Practical guide to creating an effective password policy covering modern principles from NIST 800-63B and ENISA, the EU regulatory context under NIS2 and DORA, the complexity vs length debate, MFA and passwordless authentication integration, and policy template structure.

Key Takeaways

1
Modern password policy, aligned with NIST 800-63B and ENISA guidance, prioritises minimum length (12-16 characters) over complexity rules and eliminates mandatory periodic rotation.
2
NIS2 Article 21(2)(j) and DORA Article 9(4) both mandate multi-factor authentication — MFA is a baseline regulatory requirement, not an optional enhancement.
3
Screen all new passwords against compromised-password databases (HIBP Pwned Passwords or equivalent) at creation time to eliminate the most commonly exploited credentials.
4
Phishing-resistant MFA (FIDO2/WebAuthn hardware keys) should be required for privileged access and administrative accounts, with passwordless authentication as the strategic direction.
5
Non-human identities — service accounts, API keys, machine credentials — are frequently the weakest authentication link and must be addressed explicitly in the password policy.

1. Modern Password Policy Principles

The landscape of password security guidance has shifted dramatically in recent years, driven by research demonstrating that many traditional password policies actively undermine security rather than improving it. NIST Special Publication 800-63B (Digital Identity Guidelines: Authentication and Lifecycle Management) represents the most influential revision, explicitly recommending against several practices that were considered standard for decades. ENISA (the EU Agency for Cybersecurity) has incorporated much of this guidance into its own recommendations for EU organisations, creating a converged set of principles that inform modern password policy design.

The core modern principles are: require a minimum length rather than complexity rules, do not mandate periodic password rotation, screen passwords against known-compromised password lists, do not use knowledge-based authentication questions, allow all printable characters including spaces, and implement rate limiting and account lockout to prevent brute-force attacks. These principles reflect empirical evidence that complexity rules (requiring uppercase, lowercase, numbers, and symbols) lead to predictable password patterns (Password1!, Summer2026#) that are easily guessed, while mandatory rotation drives users to increment passwords (Winter2025, Spring2026) or write them down, both of which increase rather than decrease risk.

For EU organisations, adopting NIST 800-63B-aligned password policies is not just best practice — it positions you well for regulatory compliance under NIS2 and DORA. Both frameworks require appropriate access control measures, and supervisory authorities increasingly judge the quality of those measures against current best practice rather than legacy conventions. A password policy that still mandates quarterly rotation and complex character requirements in 2026 signals to an auditor that the organisation is not tracking the evolution of security guidance — an unfavourable impression regardless of the specific regulatory framework under assessment.

NIST 800-63B explicitly recommends against mandatory periodic password changes. Forced rotation leads to predictable increment patterns and weaker passwords. Require password changes only when there is evidence of compromise.

2. EU Regulatory Context: NIS2 and DORA Requirements

NIS2 and DORA both establish obligations that directly implicate password and authentication policy, though neither prescribes specific password rules at the character level. NIS2 Article 21(2)(i) requires human resources security, access control policies, and asset management — the access control component necessarily includes authentication mechanisms. Article 21(2)(j) explicitly mandates the use of multi-factor authentication or continuous authentication solutions, secured voice, video, and text communications, and secured emergency communication systems. Together, these provisions require organisations to implement access control policies that include both strong authentication and MFA.

DORA addresses authentication through its ICT security framework requirements. Article 9(4) requires financial entities to implement strong authentication mechanisms, including multi-factor authentication, based on current standards and best practice. The European Supervisory Authorities' Regulatory Technical Standards (RTS) under DORA provide more granular requirements, including the use of robust authentication tokens, protection of authentication credentials in transit and at rest, and regular review of access rights. For financial entities, the combination of DORA RTS requirements and EBA Guidelines on ICT and security risk management (EBA/GL/2019/04) creates a detailed authentication compliance baseline.

ISO 27001:2022 Annex A control A.5.17 (Authentication information) requires that allocation and management of authentication information is controlled through a management process, including advising users on appropriate handling. Control A.8.5 (Secure authentication) requires that secure authentication technologies and procedures are established and implemented based on information access restrictions and the access control policy. Organisations pursuing ISO 27001 certification must demonstrate that their password policy reflects current best practice — auditors familiar with NIST 800-63B will question legacy complexity and rotation rules. The convergence across NIS2, DORA, and ISO 27001 is clear: all three frameworks demand access control measures aligned with current standards, which in 2026 means NIST 800-63B-aligned password policy plus mandatory MFA.

3. Password Complexity vs Length: Current Best Practice

The complexity vs length debate is effectively settled in the professional security community, though many organisations have yet to update their policies accordingly. Research — including Carnegie Mellon University's password research group, Microsoft's empirical analysis of compromised credentials, and NIST's own evidence review supporting 800-63B — consistently demonstrates that password length is a stronger predictor of resistance to cracking than character-class complexity. A 16-character passphrase using only lowercase letters provides significantly more entropy than an 8-character password with uppercase, lowercase, numbers, and symbols.

The recommended approach in 2026 is to set a minimum length of 12 to 16 characters for standard user accounts and 16 to 20 characters for privileged/administrative accounts, with no maximum length below 64 characters. Do not impose character-class requirements — allow users to create passphrases using natural language patterns, which are both longer and more memorable than complexity-constrained passwords. Screen all new passwords against a compromised-password database (the HIBP Pwned Passwords API or an equivalent dataset) at creation time, blocking any password that appears in known breach corpuses. This single control eliminates the most commonly exploited passwords regardless of their length or complexity.

For organisations transitioning from legacy complexity policies, the change management aspect is as important as the technical implementation. Users accustomed to mandatory complexity rules and quarterly rotation will need education about why the policy is changing and what constitutes a strong passphrase. Provide guidance and examples: "correct horse battery staple" (the classic XKCD example) illustrates the principle, but in practice encourage passphrases that are personal and memorable without being guessable from social media. The transition is also an opportunity to deploy a password manager enterprise-wide — users who generate and store unique credentials in a password manager produce stronger authentication outcomes than any character-level policy can achieve.

Deploy an enterprise password manager alongside your updated policy. Users who generate and store unique 20+ character passwords in a managed vault produce better security outcomes than any character-level policy can achieve.

4. MFA Integration and Passwordless Authentication

Multi-factor authentication is no longer an enhancement — it is a baseline requirement under both NIS2 and DORA. NIS2 Article 21(2)(j) explicitly mandates MFA or continuous authentication solutions. DORA RTS requirements similarly require strong multi-factor authentication for access to ICT systems. Any modern password policy must integrate MFA as a mandatory component rather than treating it as an optional addition. The policy should specify which authentication factors are acceptable (hardware security keys, authenticator apps with TOTP/HOTP, push notifications to registered devices) and which are not (SMS-based OTP, which is vulnerable to SIM-swapping and SS7 interception and is explicitly deprecated in NIST 800-63B for high-assurance scenarios).

The MFA policy should differentiate by risk level. For standard user access to non-sensitive systems, app-based TOTP (Google Authenticator, Microsoft Authenticator, or equivalent) provides adequate assurance. For privileged access, administrative accounts, and access to critical systems or sensitive data, require phishing-resistant MFA — specifically FIDO2/WebAuthn hardware security keys (YubiKey, SoloKeys, or equivalent) or platform authenticators (Windows Hello for Business, Apple Touch ID/Face ID). Phishing-resistant MFA eliminates the most common MFA bypass vectors: real-time phishing proxies (Evilginx, Modlishka) that intercept TOTP codes, and social engineering attacks that trick users into approving fraudulent push notifications.

Passwordless authentication represents the strategic direction for enterprise authentication. FIDO2/WebAuthn enables authentication without passwords entirely — users authenticate with a biometric (fingerprint, face recognition) backed by a hardware-bound cryptographic credential that cannot be phished, replayed, or extracted. For organisations building their authentication roadmap, the recommended progression is: (1) enforce MFA across all accounts immediately, (2) deploy phishing-resistant MFA for privileged access and high-risk scenarios, (3) pilot passwordless authentication for a defined user population, (4) expand passwordless to all users as platform maturity allows. This progression is compatible with NIS2 and DORA requirements at every stage, and positions the organisation for the eventual elimination of password-based attack vectors entirely.

5. Policy Template Structure and Enforcement

An effective password policy document should be structured for both human readability and audit defensibility. The policy should open with scope and applicability (which systems, users, and account types are covered), followed by the governing standards and regulations it addresses (NIS2 Article 21(2)(i)(j), DORA Article 9(4), ISO 27001 A.5.17 and A.8.5, NIST 800-63B). The core sections should cover: password creation requirements (minimum length, screening against compromised lists, prohibition of context-specific passwords containing the username or organisation name), password storage requirements (hashing algorithms, salting, key stretching — bcrypt, scrypt, or Argon2id), MFA requirements by account type and risk level, password reset and recovery procedures, and account lockout and rate-limiting thresholds.

Enforcement is where policy becomes operational reality. Technical enforcement controls should be implemented at the identity provider level: configure your Active Directory, Azure AD (Entra ID), Okta, or equivalent IdP to enforce minimum length, screen against compromised password lists (Azure AD Password Protection, or HIBP integration for other IdPs), disable periodic rotation, and require MFA registration for all accounts. For privileged access, implement just-in-time (JIT) access provisioning through a privileged access management (PAM) solution that requires MFA approval for each elevation request. Monitor for policy bypass — users who disable MFA, service accounts with static credentials, and legacy applications that do not support modern authentication all create enforcement gaps that must be tracked and remediated.

The policy must also address non-human identities: service accounts, API keys, machine-to-machine credentials, and application tokens. These are frequently the weakest authentication link, as they are often exempted from MFA requirements and assigned static, long-lived credentials. Define rotation schedules for service account passwords (quarterly or more frequently for high-privilege accounts), require certificate-based or OAuth 2.0 client-credential authentication for machine-to-machine communication where supported, and implement monitoring for service account credential exposure. Document exception processes for legacy systems that cannot meet the full policy requirements, including risk acceptance sign-off by the system owner and the CISO, compensating controls, and a remediation timeline.

Service accounts and API keys are frequently exempt from MFA and use long-lived static credentials. These non-human identities are increasingly targeted by attackers — your password policy must address them explicitly.

6. Implementation and Governance

Rolling out a modernised password policy requires careful change management, particularly when the new policy reverses long-standing practices. Communicate the rationale clearly to all stakeholders: explain that mandatory complexity and rotation rules are being retired because research demonstrates they produce weaker security outcomes, not because the organisation is relaxing its security posture. Position the transition as a security improvement — longer passphrases, compromised-password screening, and mandatory MFA collectively provide far stronger protection than the legacy approach.

Implementation should follow a phased approach. Phase one (weeks 1-4): configure technical controls at the identity provider level — set minimum length to 12 characters, enable compromised-password screening, disable forced rotation, and verify that MFA enforcement is active for all user populations. Phase two (weeks 5-8): deploy enterprise password manager to all users, provide training on passphrase creation and password manager usage, and begin monitoring adoption metrics. Phase three (weeks 9-12): address exceptions — legacy systems, service accounts, and third-party applications that require policy accommodation — and document residual risk with CISO sign-off. Phase four (ongoing): review policy effectiveness quarterly through metrics including password reset frequency, MFA adoption rate, account lockout frequency, and credential compromise incidents.

Governance of the password policy requires formal ownership and review cadence. Assign policy ownership to the CISO or equivalent security leadership role. Schedule annual policy reviews that assess alignment with current NIST, ENISA, and regulatory guidance — authentication best practice evolves, and the policy must evolve with it. Maintain an audit trail of policy versions, change rationale, and approval records. For organisations subject to NIS2, this governance documentation supports Article 21(2)(a) risk analysis and information system security policies, and Article 21(2)(f) policies and procedures for assessing the effectiveness of cybersecurity risk-management measures.

Frequently Asked Questions

Should we still require password changes every 90 days?

No. NIST 800-63B, ENISA, and Microsoft all explicitly recommend against mandatory periodic password rotation. Research demonstrates that forced rotation leads to predictable password patterns (incrementing numbers, seasonal words) that are easier to guess than stable, long passphrases. Require password changes only when there is evidence or suspicion of compromise — for example, when credentials appear in a known breach database, when a user reports a phishing incident, or when anomalous authentication activity is detected. This approach produces stronger passwords and reduces help desk load from password reset requests.

Is SMS-based two-factor authentication still acceptable?

SMS-based OTP is better than no MFA, but it is the weakest commonly deployed MFA method and is explicitly deprecated by NIST 800-63B for high-assurance authentication. SMS is vulnerable to SIM-swapping attacks, SS7 signalling interception, and social engineering of mobile carrier staff. For regulatory compliance under NIS2 and DORA, organisations should use app-based TOTP (Google Authenticator, Microsoft Authenticator) as a minimum and FIDO2/WebAuthn hardware security keys for privileged access. If you currently use SMS-based MFA, plan a migration to app-based or hardware-based MFA within your next policy review cycle.

How do we handle legacy systems that cannot enforce the new password policy?

Legacy systems that cannot enforce minimum-length passphrases, compromised-password screening, or MFA require a documented exception process. For each exception, document the specific policy requirements that cannot be met, the technical reason for the limitation, compensating controls in place (network segmentation, enhanced monitoring, restricted access scope), the risk acceptance sign-off from the system owner and CISO, and a remediation timeline (system upgrade, replacement, or migration to a modern authentication architecture). Review exceptions quarterly — they should diminish over time as legacy systems are modernised, not accumulate indefinitely.

What is the recommended minimum password length in 2026?

The recommended minimum password length for standard user accounts is 12 to 16 characters, depending on your risk profile and regulatory context. For privileged and administrative accounts, set the minimum at 16 to 20 characters. Do not set a maximum length below 64 characters — long passphrases should be encouraged, not truncated. These lengths assume that passwords are also screened against compromised-password databases and that MFA is mandatory. The combination of a long passphrase, breach screening, and MFA provides robust protection against both online and offline attack scenarios.

How does passwordless authentication work with NIS2 compliance?

NIS2 Article 21(2)(j) requires multi-factor authentication or continuous authentication solutions — passwordless authentication based on FIDO2/WebAuthn satisfies this requirement because it inherently combines possession (the hardware security key or device) with inherence (biometric verification). Passwordless authentication is actually a stronger compliance posture than traditional password-plus-MFA because it eliminates the password as an attack vector entirely. There are no known regulatory obstacles to passwordless authentication under NIS2, DORA, or ISO 27001 — all three frameworks are outcome-focused (secure authentication) rather than prescriptive about specific mechanisms.

Related Guides

Strategy

Ready to Operationalise This?

Turn this guide into working compliance workflows. Create an account or schedule a personalised demo.

Create Account Schedule Demo