Password Policy: Template Based on NIST and BSI

In July 2025, the US standards agency NIST published SP 800-63B-4 as the final version; it replaces the previous SP 800-63B. It is aimed at US government information systems and is not binding for companies in Austria, but it is suitable as a benchmark. SHALL means mandatory, SHOULD means recommended. For authentication systems, the following applies, among other things: at least 15 characters if the password is the only factor, no rules on character types, no change after a set period, a blocklist, and no more than 100 failed attempts (3.1.1.2, 3.2.2).

The IT-Grundschutz Compendium of the German BSI (Edition 2023) requires that password use be regulated in a binding manner (ORP.4.A8). Purely time-based changes SHOULD be avoided; instead, measures MUST be taken to detect compromised passwords (ORP.4.A23). Basic requirements are to be met first; together with them, standard requirements constitute the state of the art. On its consumer page, the BSI recommends long passwords, such as five to six randomly chosen words with spaces, also mentions shorter passwords with four character types, and advises using a password manager.

Mandatory or recommended? NIST and IT-Grundschutz are standards, not laws in Austria. Multifactor authentication is named by law for essential and important entities in § 32 para. 4 lit. j NISG 2026 (Austrian Network and Information Systems Security Act 2026); the authentication requirements in the annex to Implementing Regulation (EU) 2024/2690 also apply to them (§ 2 NISV 2026, Austrian NIS Regulation 2026), see section 02. The template in this document is a TOMORIS recommendation based on these sources.

NIS2 entities: Under annex point 11.6.2 of Implementing Regulation (EU) 2024/2690, which § 2 NISV 2026 declares applicable, authentication credentials must be changed at the outset, at predefined intervals, and on suspicion (lit. c); after a defined number of unsuccessful sign-in attempts, a reset of the authentication credentials and a lockout must be required (lit. d); inactive sessions must be terminated (lit. e); and separate credentials must be used for privileged accounts (lit. f). You set the interval yourself and justify it with the risk analysis; the annex does not specify a minimum value.

For essential and important entities, § 32 para. 4 lit. j NISG 2026 has, since October 1, 2026, included the "use of multifactor authentication or continuous authentication solutions" among the minimum contents of the risk management measures. They must be appropriate and proportionate (paras. 1 and 3). Details are set out in the NISV 2026 (BGBl. II No. 290/2026): its § 2 extends the annex of Implementing Regulation (EU) 2024/2690 to all essential and important entities not already covered by the regulation itself. Accordingly, users must be authenticated with multiple factors or continuously, where appropriate and depending on the classification of the assets (annex point 11.7.1).

The Microsoft requirement applies to all user accounts, including emergency accounts; for these, Microsoft recommends a passkey (FIDO2) or certificate-based authentication. Managed identities and service principals are not affected, but user accounts that run scripts as service accounts are. In IT-Grundschutz, accounts with far-reaching privileges SHOULD be protected with multifactor authentication (ORP.4.A10), and generally so where protection requirements are high (ORP.4.A21). At level AAL2, NIST requires offering at least one phishing-resistant method (2.2.2).

TOMORIS recommendation: MFA for all accounts, at least for email, cloud services, remote access, and administration. This goes beyond the obligations named here.

How to adapt the template: replace all information in square brackets, choose one option where alternatives are separated by |, and delete what does not apply. Numbers such as [15] characters are TOMORIS suggestions based on the sources. Citations in parentheses show what a rule is based on; rules without a citation are organizational additions by TOMORIS.

For accounts created and managed directly in Entra ID, a fixed password policy applies: 8 to 256 characters, three of four character types (lowercase and uppercase letters, digits, symbols), no Unicode characters. Only the expiration can be changed. For accounts synchronized from on-premises Active Directory, it applies only if the cloud password policy for synchronized users is explicitly enabled.

Entra ID therefore cannot technically enforce a minimum length of 15 characters and the elimination of character type rules for cloud accounts. TOMORIS recommendation: govern length through the policy, instruction, and the password manager's generator, and base protection on MFA and passkeys.

• Check password expiration: tenants created before 2021 have 90 days by default. For cloud-only accounts, Microsoft recommends never letting passwords expire.
• Enforce MFA for all users: with Conditional Access (Entra ID P1 or P2) or, without this license, with security defaults.
• The global banned password list is always active; according to Microsoft, it is based on its own telemetry on password spray attacks. Add the custom list under Entra ID › Authentication methods › Password protection: company, product, and location names, internal terms; only base terms, the algorithm detects variants; at most 1,000 terms; Entra ID P1 or higher.
• With on-premises Active Directory: roll out password protection with the agent on the domain controllers so that the same banned lists apply there too (Entra ID P1 or P2).
• Check smart lockout: the default is a lockout after 10 failed attempts for 60 seconds with increasing duration; adjust it in the same place (Entra ID P1). With pass-through authentication: Entra threshold lower, Entra lockout duration longer than in on-premises AD.
• Enable passkeys (FIDO2) in the authentication methods policy, in all editions without an additional license; for admin roles and sensitive resources, require phishing-resistant sign-in via authentication strength in Conditional Access (Entra ID P1).
• Equip emergency accounts with a passkey (FIDO2) or certificate-based authentication; switch user accounts that run scripts to managed identities or service principals.
• Enable Identity Protection risk policies (Entra ID P2) and combine password reset with an authenticator app, as Microsoft recommends for Microsoft 365.

• Blocklist: check new passwords in full against common, expected, and compromised passwords, such as passwords from data breaches, dictionary words, the name of the service, and the user name; explain the rejection and offer help with choosing (NIST 3.1.1.2).
• Length: at least 15 characters as the only factor, at least 8 only in combination with MFA; allow at least 64 characters, all printable ASCII characters, and spaces, and Unicode where possible; check the entire password, never truncate it (NIST 3.1.1.2; ORP.4.A23).
• Failed attempts: at most 100 consecutive attempts per account, lower limits are permitted; in addition, increasing wait times, for example 30 seconds to one hour (NIST 3.2.2). The BSI recommends increasing delays and a lockout after a defined number (ORP.4.A13).
• Input: allow password managers, autofill, and pasting, show the password on request; no hints, no security questions (NIST 3.1.1.2). On a failed sign-in, do not reveal whether the account name or the password was wrong (ORP.4.A23).
• Transmission and change: passwords only over encrypted, authenticated connections; after a change, no longer allow old passwords (NIST 3.1.1.2; ORP.4.A23).
• Storage: salted with a password hashing scheme with a cost factor according to NIST SP 800-132, salt at least 32 bits, cost factor as high as possible without performance loss and increased over time; an additional step with a secret key, stored separately, for example in a hardware security module, is recommended (NIST 3.1.1.2; ORP.4.A12).

• Abolishing forced changes without being able to detect compromises: the BSI makes dropping them conditional on measures that detect compromised passwords (ORP.4.A23).
• Abolishing changes entirely as a NIS2 entity: annex point 11.6.2(c) Implementing Regulation 2024/2690 requires a change at predefined intervals. Choose the interval deliberately and with reasons instead of omitting it.
• Raising the minimum length in the policy but keeping systems with a short maximum length: check whether every system accepts and checks the full length (ORP.4.A23; NIST 3.1.1.2).
• Introducing a password manager without assessing synchronization via third-party online services: anyone working according to IT-Grundschutz MUST disable such functions (ORP.4.A8).
• Considering MFA with a one-time code via app or SMS to be phishing-proof: codes entered by hand are not considered phishing-resistant; only cryptographic methods such as passkeys achieve this (NIST 3.2.5).
• Exempting emergency accounts from MFA: Microsoft explicitly applies mandatory MFA for admin portals to emergency accounts as well.

Passkeys are based on FIDO2 and WebAuthn: instead of sending a password, the device proves possession of a private key, unlocked with a PIN or a biometric feature. NIST cites WebAuthn as an example of phishing resistance: the secret is bound to the authenticated domain name of the service, so a fake site receives nothing usable (SP 800-63B-4, 3.2.5).

• Passwords are not phishing-resistant, nor are methods with a manually entered code such as one-time codes or codes via SMS (NIST 3.1.1, 3.2.5).
• NIST permits syncable passkeys, whose keys are copied to other devices via a cloud service, subject to conditions, for example that the key is stored there only in encrypted form; they are excluded for the highest level, AAL3 (NIST 2.3.2, Appendix B).
• Entra ID supports device-bound passkeys on FIDO2 security keys and in Microsoft Authenticator as well as synced passkeys; according to Microsoft, the latter should be treated as phishing-resistant but like other non-attested methods. Guest accounts cannot register passkeys.

1. 1

   Take stock

   List systems with password sign-in, their current rules, and administrator, service, and emergency accounts.

2. 2

   Adapt and approve the template

   Fill in placeholders, decide on alternatives, obtain approval from executive management.

3. 3

   Switch the technology

   Implement expiration, blocklist, failed attempt limits, MFA, and passkeys, first for administrators, emergency accounts, and remote access.

4. 4

   Instruct and review

   Instruct all employees (ORP.4.A19) and check [annually] whether systems enforce the rules and whether requirements have changed.