Creating a Password Policy: Requirements, Example, and Enforcement

Why a Password Policy Is Indispensable

Passwords remain the most widely used authentication method in businesses. Whether email inbox, ERP system, VPN access, or cloud service: almost everywhere, a password forms the first line of defense. At the same time, studies consistently show year after year that weak, reused, or compromised passwords are among the most common causes of security incidents. The Verizon Data Breach Investigations Report regularly attributes over 40 percent of successful attacks to stolen credentials.

A password policy creates binding rules for how credentials are created, managed, and protected within the organization. As a subordinate document to the information security policy, it is not optional for an ISMS under ISO 27001 but is explicitly required through Annex A.5.17 (Authentication information). NIS2 also requires affected organizations to take appropriate access control measures, and a documented password policy is part of the minimum standard.

This is not about bureaucratic paperwork. A well-crafted password policy serves three concrete functions: it gives employees clear guidance, it creates the basis for technical enforcement, and it serves as evidence for auditors and authorities.

What BSI and NIST Recommend Today

Password security recommendations have changed significantly in recent years. If you are still working with rules that force a password change every 90 days and require at least one special character, one number, one uppercase letter, and one lowercase letter, you are following an outdated model. Both the BSI and NIST (National Institute of Standards and Technology) have fundamentally revised their recommendations.

BSI Recommendations (IT-Grundschutz)

The BSI has moved away from blanket password complexity in its current IT-Grundschutz building blocks (ORP.4). The key points:

• Length over complexity: A long password (at least 12 characters, preferably 16+) is more secure than a short one with many special characters. The BSI recommends passphrases as a practical alternative.
• No regular forced rotation: Passwords should only be changed when there is a concrete suspicion of compromise. Routine rotation every 90 days demonstrably leads to weaker passwords because users develop predictable patterns (Password1!, Password2!, Password3!).
• MFA for critical systems: Multi-factor authentication is mandatory for administrative access and remote connections.
• Checking against blocklists: Passwords should be checked against lists of known compromised credentials.

NIST SP 800-63B

The NIST guideline SP 800-63B takes the same direction and is even more explicit:

• Minimum length 8 characters, recommended 15+: Systems should accept passwords up to 64 characters.
• No composition rules: The requirement for uppercase, lowercase, numbers, and special characters is explicitly assessed as counterproductive.
• No time-based rotation: Change only upon suspected compromise.
• Blocklists are mandatory: New passwords must be checked against a list of commonly used, compromised, and context-specific passwords (company name, username).
• Support password managers: Systems must allow copy-paste in password fields so that password managers can be used.

These recommendations do not contradict ISO 27001. On the contrary: the standard requires that authentication methods correspond to the state of the art, and that is exactly what BSI and NIST reflect.

Minimum Requirements for Your Password Policy

Based on current standards, your password policy should define the following minimum requirements:

Password Strength

Prohibited Passwords

Your policy should explicitly state that the following passwords are not permitted:

• Passwords from known breach databases (automated checking)
• The username or parts of it
• The company name, product names, or location names
• Simple keyboard patterns (qwerty, 123456, asdfgh)
• Unmodified dictionary words
• Passwords already used in other systems

Password Handling

Beyond password strength, the policy must also govern handling:

• Passwords must not be stored in plain text, written down, or shared.
• A unique password must be used for each system (no reuse).
• A company-provided password manager must be used for management.
• Passwords must not be transmitted via email, chat, or phone.
• Initial passwords must be changed at first login.
• If compromise is suspected, the password must be changed immediately and the incident reported.

Multi-Factor Authentication (MFA)

A modern password policy is incomplete without a clear chapter on MFA. Even a perfect password offers no protection against phishing, keyloggers, or credential stuffing. Multi-factor authentication adds a second factor that stops an attacker even when they already know the password.

Where MFA Should Be Mandatory

Your policy should mandate MFA for at least the following areas:

• All administrative and privileged access
• Remote access (VPN, webmail, cloud services from outside)
• Access to particularly sensitive data (HR data, financial data, health data)
• Self-service portals for password reset
• Single sign-on systems (SSO), since a compromised SSO password opens access to many systems

Accepted MFA Methods

Not every second factor offers the same level of protection. Your policy should define a clear hierarchy:

1. Hardware security keys (FIDO2/WebAuthn): Highest security, phishing-resistant
2. Authenticator apps (TOTP/HOTP): Good protection, widely deployed
3. Push notifications: Convenient, but susceptible to MFA fatigue attacks (therefore use number matching)
4. SMS-based codes: Acceptable only as a fallback, since SIM swapping is a real risk

Your policy should specify which methods are permitted in the organization and which are explicitly not. For privileged accounts, it is recommended to allow only hardware keys or authenticator apps.

Password Policy Example (Outline)

To give you a concrete idea of how a password policy can be structured, here is a practice-proven outline:

1. Introduction and Purpose

• Purpose of the policy
• Reference to the overarching information security policy
• Scope (all employees, external service providers, temporary access)

2. Scope

• Which systems and applications are covered
• Which user groups are included
• Exceptions and their approval process

3. Password Requirements

• Minimum length per account type
• Recommended passphrase method
• Prohibited passwords and blocklists
• No reuse (history of at least 10 passwords)

4. Multi-Factor Authentication

• Mandatory areas for MFA
• Permitted MFA methods
• Emergency procedures for loss of the second factor

5. Password Management

• Use of the enterprise-wide password manager
• Prohibition of plaintext storage
• Rules for shared accounts (avoid where possible)

6. Password Change and Compromise

• Change only for concrete reason
• Reporting obligation upon suspected compromise
• Password reset procedure

7. Technical Enforcement

• Implementation via Active Directory, identity provider, or MDM
• Automated checking against breach databases
• Monitoring of failed login attempts and account lockout

8. Awareness and Training

• Regular awareness sessions (at least annually)
• Content: passphrases, social engineering, phishing
• Attendance documentation

9. Responsibilities

• IT department (technical implementation)
• ISM (policy maintenance, review)
• Managers (enforcement within the team)
• Employees (compliance)

10. Violations and Consequences

• Escalation process for violations
• Employment law consequences
• Reference to works agreement (if applicable)

11. Review and Update

• Annual review cycle
• Event-driven updates (new threats, audit findings)
• Versioning and approval process

Common Mistakes in Password Policies

Even well-intentioned password policies frequently contain provisions that are either ineffective or even counterproductive. Here are the most common pitfalls:

Mistake 1: Excessive Complexity Rules

Requiring at least one uppercase letter, one lowercase letter, one number, and one special character sounds secure but leads in practice to predictable patterns. Most users put the uppercase letter at the beginning and the number and special character at the end. The result: "Summer2026!" meets all requirements but is trivial to crack. Better: long passphrases without composition requirements, combined with blocklists.

Mistake 2: Forced Rotation Without Cause

Regular password changes every 30, 60, or 90 days have been identified as counterproductive for years. Users respond by making minimal changes (incrementing a digit) or writing passwords down. Both behaviors undermine security more than they strengthen it. The policy should instead mandate event-based changes and run regular checks against compromised password lists.

Mistake 3: No Password Manager Required

If you expect your employees to use a unique, long password for every system but provide no password manager, you are creating an unsolvable problem. People cannot remember 30 different 16-character passphrases. The consequences: reuse, sticky notes, Excel lists. An enterprise-wide password manager belongs in the policy as a technical measure.

Mistake 4: MFA Is Not Mentioned or Only Recommended

In many password policies, MFA appears as an optional recommendation. That is not enough. For critical systems and privileged accounts, MFA must be defined as mandatory. The policy should also specify what happens when an employee loses their second factor (emergency procedures, temporary codes, admin reset).

Mistake 5: No Coverage for Service Accounts

Password policies often think only of human users. But service accounts, API keys, and technical credentials are at least equally critical. They often have extensive permissions and are rarely rotated. Your policy should contain explicit rules for technical accounts: minimum length, automated rotation, storage in a secrets management system.

Mistake 6: The Policy Exists Only on Paper

A password policy that appears in the ISMS document register but is not technically enforced is worthless. If Active Directory still accepts 8-character passwords without a blocklist, the policy is fiction. Technical and organizational enforcement must go hand in hand.

Enforcement: Technical vs. Organizational

The effectiveness of your password policy stands or falls with enforcement. There are two levers you should use in parallel.

Technical Enforcement

Technical measures enforce the policy automatically, without relying on individual employee behavior:

Active Directory / Identity Provider:

• Minimum length and history policy via Group Policy Objects (GPO) or Conditional Access Policies
• Integration of Azure AD Password Protection or comparable solutions for blocklists
• Automatic account lockout after multiple failed attempts (Account Lockout Policy)
• MFA enforcement via Conditional Access (e.g., for all access from outside the corporate network)

Password Manager (enterprise-wide):

• Provision of a licensed password manager for all employees
• Central management of team vaults for shared access
• Auditing of usage (are password managers actually being used?)

Breach Detection:

• Regular matching of corporate email addresses against HaveIBeenPwned or comparable services
• Automatic notification and forced password change on hits
• Integration into the onboarding process (initial password is changed at first login)

Monitoring and Alerting:

• Monitoring of failed login attempts via SIEM or centralized log analysis
• Detection of brute-force and password-spraying attacks
• Alerting on unusual login patterns (geo-anomalies, impossible travel speed)

Organizational Enforcement

Technology alone is not enough. Organizational measures ensure that employees understand and support the policy:

Awareness Training:

• Annual mandatory training on secure passwords and phishing recognition
• Practical examples instead of abstract theory (live demo of a brute-force attack, phishing simulation)
• Explanation of why specific rules exist and which attack scenarios they prevent

Acknowledgment and Confirmation:

• Every employee confirms acknowledgment of the policy in writing or digitally
• Upon updates, confirmation is repeated
• Confirmations are archived as evidence for audits

Regular Verification:

• Spot-check audits (are password managers being used? Do shared accounts still exist?)
• Policy review at least annually or upon relevant changes
• Incorporation of audit findings and security incidents into updates

Escalation for Violations:

• Clear escalation process (initial conversation, warning, further consequences)
• Confidential reporting possible (employees should be able to report violations without fear)
• Documentation of all incidents and measures

Password Policy and ISO 27001

For an ISMS under ISO 27001, the password policy is primarily anchored through Annex A.5.17 (Management of authentication information). But it touches on additional controls:

• A.5.15 (Access control): The password policy is part of the overarching access control.
• A.5.16 (Identity management): Passwords are tied to identities; the policy must align with identity management.
• A.8.2 (Privileged access rights): Elevated requirements apply to privileged accounts.
• A.8.5 (Secure authentication): The technical implementation must reflect the policy.
• A.6.3 (Information security awareness): Training measures related to the password policy.

An auditor will check whether the policy exists, whether it reflects the current state of the art, whether it is technically implemented, and whether evidence of training and acknowledgment is available. The mere existence of the document is not sufficient.

Passphrases: The Better Alternative

If you want to give your employees a practical method for secure passwords, recommend passphrases. A passphrase consists of several randomly chosen words that together form a long but memorable password.

Examples:

• "coffee mug hiking trail lightning rod penguin" (44 characters)
• "correct horse battery staple" (28 characters, the famous XKCD example)

Why are passphrases better?

• They are long, which exponentially increases the difficulty of brute-force attacks.
• They are memorable, reducing dependence on password managers for frequently used logins.
• They avoid the predictable patterns that arise from complexity rules.
• They can be spelled out over the phone in an emergency.

Your policy can include passphrases as the recommended method and provide guidance: at least four words, no connected sentences from known sources (song lyrics, movie quotes), ideally with a separator (space, hyphen).

Special Cases Your Policy Should Address

Shared Accounts

Shared accounts are problematic from a security perspective because individual accountability is impossible. Your policy should state as a principle that shared accounts are to be avoided. Where they are unavoidable (e.g., social media accounts, certain production equipment), the passwords must be managed in a password manager, access must be logged, and passwords must be changed immediately upon personnel changes.

External Service Providers

External partners and service providers who have access to company systems must also be subject to the password policy. This should be contractually secured through a non-disclosure agreement or a data processing agreement. For external access, MFA plus time-limited access is generally recommended.

Emergency Access (Break-Glass Accounts)

In case regular access does not work (e.g., during an identity provider outage), your organization needs documented emergency accounts. The passwords for these accounts are stored sealed (physically or in a separate vault), and every use is logged and automatically triggers a password change.

API Keys and Tokens

Technical credentials such as API keys, OAuth tokens, and SSH keys also fall under the password policy, even though they are not classical passwords. The policy should specify how they are generated, stored (secrets manager), rotated, and revoked.

Getting Started Pragmatically

You do not have to start from scratch. A pragmatic approach in five steps:

1. Inventory: Which systems exist, what password requirements currently apply, and where are the gaps?
2. Draft based on current standards: Use the outline from this article as a starting point and adapt it to your company. Base it on BSI IT-Grundschutz and NIST SP 800-63B.
3. Coordination with IT and works council: IT must confirm technical feasibility, and the works council has a say in behavioral monitoring (account lockout, monitoring).
4. Approval and communication: The policy is approved by top management and communicated to all employees, ideally with a brief training session. In ISMS Lite, the complete approval workflow including digital acknowledgment by all employees can be mapped.
5. Technical implementation and monitoring: The requirements are configured in the systems, and compliance is regularly checked.

The entire process should not take months. With a good template and clear responsibilities, you can bring a practical password policy from idea to approval in two to four weeks.

Conclusion

A password policy is one of the most impactful documents in your ISMS when done right. The days of "8 characters, uppercase letter, number, special character, change every 90 days" are over. Modern password policies rely on passphrases, blocklists, MFA, and technical enforcement instead of rules that drive employees to insecure workarounds.

Further Reading

• Writing an Information Security Policy: Structure, Content, and Example
• Mobile Device Usage Policy (BYOD/MDM)
• Access Control Policy: Physical and Logical
• Creating an Access Rights Concept: Roles, Rights, and Approval Workflow
• Policy Lifecycle: From Creation to Retirement

What matters is that the policy does not gather dust in a drawer but is technically enforced, trained, and regularly reviewed. Then it protects your company not only against attackers but also makes every audit a relaxed affair.