Many companies revising their password policy get stuck between two camps. The audit checklist still says "upper case, lower case, digits and symbols, and change it regularly", while NIST SP 800-63B-4, finalized in July 2025, explicitly prohibits both practices and instead requires longer passwords, a blocklist of breached passwords, and support for pasting and password managers[1]. Meanwhile, after the 2026-01-07 amendment to Taiwan's Regulations Governing the Classification of Cyber Security Responsibility Levels[2], Annex 10, the information system protection baseline, still requires a "minimum password complexity" and password changes according to the agency's own expiry rules[3].

This article is for IT staff and managers writing or revising a company password policy. It sets out what NIST and the Taiwan rules actually say and how to satisfy both where they conflict, then covers choosing password managers and their risks, passkeys, and shared and service accounts, and ends with a policy outline you can adapt. For MFA types and rollout order, see the MFA rollout guide.

NIST SP 800-63B-4: what changed for passwords

NIST SP 800-63B-4 was published in July 2025 and supersedes the 2020 version of SP 800-63B[1]. It is written for US federal government information systems and has no legal force for Taiwanese companies, but it is often used as the technical basis for password policies. It distinguishes SHALL (mandatory) from SHOULD (recommended); here are the password rules at their original strength[1]:

  • Minimum length: at least 15 characters when the password is the only authentication factor; passwords used only as part of multi-factor authentication may be shorter but must be at least 8 characters (SHALL).
  • Maximum length and characters: allow at least 64 characters, and accept all printing ASCII characters, the space character and Unicode characters (SHOULD).
  • No composition rules: apart from the blocklist, do not impose rules such as requiring a mix of character types (SHALL NOT).
  • No periodic forced changes: do not require users to change passwords periodically (SHALL NOT), but force a change when there is evidence the password has been compromised (SHALL).
  • Blocklist check: when a password is set or changed, compare the entire password against a list of commonly used, expected or compromised values, such as passwords from previous breaches, dictionary words, and the service name, the username and their derivatives; if it matches, require a different password and explain why (SHALL).
  • No hints or security questions: do not let an unauthenticated person see a password hint, and do not prompt users to set knowledge-based questions such as "What was the name of your first pet?" (SHALL NOT).
  • Allow password managers and paste: allow password managers and autofill (SHALL), and permit the paste function (SHOULD).
  • Limit failed attempts: limit consecutive failed attempts on an account to no more than 100; agencies may set lower limits (SHALL).
  • Secure storage: salt and hash passwords with a suitable password hashing scheme so they resist offline attacks (SHALL).

NIST explains its reasoning in an appendix: analyses of breached password databases show that composition rules deliver less benefit than once thought while imposing a heavy usability and memorability cost, and users respond predictably, so someone who would have chosen "password" picks "Password1" when an upper-case letter and a digit are required, and "Password1!" when a symbol is added[1]. That is why NIST focuses on length and blocklists. The same appendix notes that keystroke logging, phishing and social engineering work just as well against long, complex passwords, and the main text states plainly that passwords are not phishing-resistant[1]. Those threats need MFA and endpoint protection; for passwords stolen in bulk by malware, see infostealers and leaked credentials.

Building the blocklist: checking against breached passwords

Collecting breached passwords yourself is not realistic, so a common approach is to query the Pwned Passwords service from Have I Been Pwned (HIBP). Its range API uses a k-anonymity model: the system computes the SHA-1 hash of the password locally and sends only the first 5 characters; the API returns the suffix of every hash that starts with those 5 characters, with a count of how many times each appears in the data set, and the comparison happens locally[4]. A range search typically returns about 800 suffixes; adding the Add-Padding: true header pads every response to between 800 and 1,000 results, so an observer cannot infer the searched prefix from the response size[4]. The API needs no API key, has no rate limit and also accepts NTLM hashes; if you would rather not depend on an online service, the full hash list can be downloaded for offline checks[4].

In practice, add this check to the registration, change and reset flows of systems you build yourself. If you use an off-the-shelf identity platform, first check whether it already offers a banned-password or breached-password check.

Taiwan's rules: Annex 10 and the listed-company guidelines

What Annex 10 requires

Article 11 of the Regulations Governing the Classification of Cyber Security Responsibility Levels requires government agencies and specific non-government agencies to classify the information systems they develop in-house or through outsourcing by protection need (high, moderate or low, 高/中/普) according to Annex 9, and to apply the controls in Annex 10, the information system protection baseline[2]. The obligations for levels A, B and C (Annexes 1 to 6) all include this item: levels A and B must complete it within one year of their level first being approved or changed; level C must complete the classification within one year and the controls within two years[2]. The regulations were last amended on 2026-01-07, and the amended provisions took effect on promulgation[2]. For which organizations count as specific non-government agencies, see Taiwan's Cyber Security Management Act.

The password-related controls in Annex 10's identification and authentication domain are[3]:

  • Low (also required at moderate and high): change a default password immediately after the first sign-in with it; do not transmit authentication information in clear text; after five failed sign-in attempts, block further attempts on the account for at least 15 minutes, or use a failed-authentication mechanism the agency builds itself; when passwords are used, enforce a minimum password complexity and change passwords according to the agency's password expiry rules; when a password is changed, it must differ from at least the last three; for external users, the agency may set its own rules for the last two items.
  • Additional at moderate and high: the authentication mechanism must guard against automated sign-in or password-change attempts; password reset must re-verify the user's identity and then send a one-time, time-limited token.
  • User identification: at every level the system must identify and authenticate users and must not allow shared accounts; high systems must also use multi-factor authentication.
  • Protection of authentication information: at every level, authentication feedback must be masked; moderate and high systems must also store passwords hashed or otherwise suitably processed.

Annex 10 does not say which characters "complexity" must include, nor how many days a password may last. Before the 2026 amendment, the expiry wording was "enforce minimum and maximum password lifetimes"; it now reads "change passwords according to the agency's password expiry rules", and the explanatory notes say internal users should "change or extend their passwords" under the expiry rules the agency defines, while external users may be handled under the agency's own rules[5].

Listed companies

Article 22 (formerly Article 21) of the Cybersecurity Control Guidelines for Listed and OTC Companies, as revised by the Taiwan Stock Exchange in November 2026, asks companies to set operating rules for user password management covering, for example, default passwords, password length, password complexity, password history, minimum and maximum password lifetimes, lockout after failed sign-ins and a change at first sign-in, and to evaluate multi-factor authentication and other zero-trust measures for core systems; the explanatory notes say the revision drew on the protection baseline in the classification regulations[6]. The article lists what the rules must cover; it does not set any values.

Reconciling the conflicts with NIST

Item by item, the five-attempt lockout, not reusing the last three passwords, changing default passwords at first sign-in and hashed storage are all compatible with NIST, which only caps failed attempts at 100 and allows lower limits[1][3]. The real conflicts are two: Annex 10 requires enforcing a minimum password complexity, which NIST forbids as a composition rule; and Annex 10 requires changing passwords on an expiry schedule, which NIST forbids as periodic forced change[1][3]. An agency bound by Annex 10 can handle this as follows:

  • Keep the required items; do not drop them on your own: systems must be able to enforce complexity and password expiry, and the policy must say so, or the audit will record a missing control.
  • Use NIST where the text leaves room: Annex 10 does not define the content of complexity or the number of days[3], so you can raise the minimum length, add a breached-password blocklist, allow long passwords and password managers, and avoid a short expiry period; the explanatory notes explicitly mention that passwords may be "extended"[5]. Write the specific wording and period into your risk assessment together with the basis (the NIST text, the blocklist and the breach monitoring already in place), and confirm it with your auditors or the competent authority in advance.
  • Apply NIST directly to external users: for external users, the agency may set its own rules on complexity and expiry and on password history[3], so member and customer sign-in can follow NIST's length and blocklist rules.
  • Reduce the number of systems that rely on passwords: the complexity and expiry controls apply "when passwords are used"[3]; once a system moves to SSO with MFA or passkeys, there are fewer places where the password rules apply.
  • Handle genuine exceptions formally: where a particular system has clear difficulty implementing a control because of technical limitations or similar factors, Article 11 provides an exemption with the consent of the authority that submits or approves the agency's level and a filing with the competent authority[2]; do not just skip it.
  • Check for sector rules: a sector's central competent authority may set its own baseline for particular types of systems, which applies once the competent authority approves it[2].

For ordinary companies outside the Cyber Security Management Act, Annex 10 does not apply directly and NIST can be the reference. But if you develop systems for a government agency or a specific non-government agency, Annex 10 requires the commissioning agency to write the security requirements for each development stage into the outsourcing contract[3], so these controls may reach you through the contract.

Password managers and passkeys

Personal, enterprise and browser-built-in

NIST notes that password managers have been shown to make users more likely to choose stronger passwords, especially when they include a password generator[1]. The UK National Cyber Security Centre (NCSC) says in its password manager buyers guide that password managers are not perfect but that their benefits outweigh the risks[7]. The NCSC distinguishes on-device managers, which keep data on a single device, from cloud-sync managers, which sync across devices; either can be a standalone application or built into the browser or operating system, and cloud-sync managers add considerations such as the security of passwords in transit and a remote attacker gaining access to the password manager account[7].

The difference between personal and enterprise products is central management: access control and logging for shared passwords, auditing of administrator access, mandatory MFA to open the vault, separation of work and personal vaults, and full usage logs are all enterprise considerations the NCSC lists[7]. A browser's built-in manager is convenient for personal accounts, but if company credentials sit in an employee's personal browser sync account, the company cannot easily manage them centrally or take them back when the employee leaves. Put company credentials in a company-managed enterprise product; for the risk of browser-saved passwords and how to turn them off, see infostealers and leaked credentials.

Protecting the vault: master password plus MFA

The vault is the master key to every credential in it. The master password must be long and not reused anywhere, because the key that decrypts the vault is usually derived from it; the NCSC recommends MFA on all cloud-sync password managers and on any manager that stores passwords for privileged or other sensitive accounts[7]. Decide in advance how a forgotten master password is recovered: the NCSC warns that the recovery method itself may be exploited to reach the credentials[7].

Lessons from the LastPass incident

In its notice of 22 December 2022, LastPass said the attacker used information obtained in the incident disclosed in August that year to target another employee and obtain credentials and keys, then copied from cloud storage both customer account data (company names, end-user names, billing addresses, email addresses, telephone numbers and IP addresses) and a backup of customer vault data[8]. Usernames, passwords, secure notes and form-filled data in the vault were encrypted and can only be decrypted with a key derived from each user's master password, but data such as website URLs was not encrypted[8]. LastPass said it has required a 12-character minimum master password since 2018; a master password that does not follow its defaults would need significantly fewer guesses to crack, and those users should consider changing the passwords of websites stored in the vault; it also warned that the attacker might target customers with phishing, credential stuffing or other brute-force attacks[8]. Its update of 1 March 2023 added that the attacker targeted a senior DevOps engineer by exploiting vulnerable third-party software to deliver malware, and that the data taken included backups of all customer vault data and a backup of the MFA/Federation database[9].

Four lessons for organizations:

  • Once a vault backup leaks, only the master password stands in the way: encrypted fields can only be decrypted with a key derived from the master password[8], so the attacker can guess offline at leisure, and sign-in MFA does not help in this scenario.
  • Unencrypted metadata is intelligence too: URLs reveal which services you use and can be used to craft targeted phishing. When choosing a product, check which fields are encrypted; the NCSC also suggests considering whether fields such as saved domains are encrypted[7].
  • People and devices holding key privileges are targets: the attacker went after a senior DevOps engineer[9], so administrators' and engineers' endpoints and vaults need the same protection as privileged accounts.
  • Know your rotation order if the vendor is breached: change high-value accounts first (administrators, finance, cloud consoles), along with the API keys and certificates stored in the vault.

What to look for when choosing one

Without recommending any product, here are evaluation points drawn from the NCSC guide[7]:

  • data at rest is encrypted with sound algorithms, and only the user holds the decryption key, not even the service provider;
  • export is protected, and administrators can disable or audit it;
  • the vendor's speed in fixing vulnerabilities and its disclosure policy, and whether its update mechanism fits your patching process;
  • autofill offers credentials only to the site they were saved for, and the password generator can meet each system's rules;
  • it supports every operating system and browser you use;
  • in enterprise products, administrators cannot see or use individual passwords, and administrator actions are audited.

Passkeys: moving away from passwords

The FIDO Alliance defines a passkey as a sign-in credential based on FIDO standards that replaces passwords; it uses public key cryptography, and because the user and the service share no secret, passkeys are always strong and phishing-resistant[10]. Passkeys can be synced across a user's devices or bound to a single device, and the "passkey provider" that creates and manages them can be the operating system, the browser or a third-party password manager[10]. In other words, when you choose a password manager you can also check whether it can store passkeys. For the trade-off between synced and device-bound passkeys, which kind administrators should use, and how to design account recovery, see the MFA rollout guide.

Shared and service accounts

Annex 10 requires information systems to identify and authenticate users and not to allow shared accounts[3], and the NCSC does not recommend sharing passwords between individuals[7]. Where an account can be split into individual accounts with delegated privileges, split it first. For the ones you cannot split yet, such as the only admin account on a device or a break-glass emergency account, at minimum:

  • Keep them in a shared vault in the enterprise password manager: not in spreadsheets, chat groups or sticky notes; have a designated person control who can access each one, and log who used it and when[7].
  • Change them when people move or when there are signs of compromise: change the password when someone leaves, changes role or finishes a project; an enterprise password manager can sync the new password automatically to those who still have access[7]. Change it immediately on evidence of compromise, consistent with NIST's rule for individual passwords[1].
  • Keep a register: record each shared account's purpose, owner and storage location, and review regularly whether it can be split into individual accounts.

Service accounts and secrets used by software (database connection passwords, API keys, certificates) are not passwords anyone needs to remember, and they are managed differently. The OWASP Secrets Management Cheat Sheet recommends[11]:

  • centralizing and standardizing secrets management, not hardcoding secrets in source code or configuration files, and detecting secrets before code is committed;
  • automating rotation where possible so stolen credentials only work for a short time, and using dynamic or short-lived secrets where you can;
  • auditing who accessed which secret and when, and alerting on unexpected access;
  • when a secret leaks, revoking it immediately, issuing a replacement, and removing it from code and logs.

So "don't rotate people's passwords on a schedule, do rotate machine secrets" is not a contradiction: machine secrets are generated and rotated by systems, and nobody has to remember them. In a Windows domain, service accounts can be replaced with group Managed Service Accounts (gMSA), where Windows manages the password instead of an administrator changing it by hand[12]; for domain admin and local admin accounts, see Active Directory privileged accounts.

Sample password policy outline

You can adapt this outline directly into your company's password rules. The parts marked "if bound by Annex 10" apply to organizations that must implement Annex 10; other companies can use the NIST version.

  • Scope: all employee, contractor and vendor accounts, and every system that uses passwords to sign in; member and customer accounts are covered separately.
  • Length: at least 15 characters for accounts that sign in with a password alone, and at least 8 characters for accounts that also use MFA; allow at least 64 characters, accept spaces and all printing characters, and encourage passphrases made of several words[1].
  • Composition: no mandatory mix of character types; rely on the blocklist instead. If bound by Annex 10, define what "minimum complexity" means in your rules and confirm it with your auditors in advance[3].
  • Blocklist: when a password is set or changed, check it against breached passwords, dictionary words, and the service or company name, the username and their derivatives, and explain any rejection[1].
  • When to change: no periodic forced changes; force a change immediately on signs of breach or compromise[1]. If bound by Annex 10, change or extend passwords according to the expiry rules your organization sets[5].
  • Password history: a new password must differ from at least the last three[3].
  • Lockout: if bound by Annex 10, lock the account for at least 15 minutes after five consecutive failures[3]; elsewhere, cap failures at no more than 100 and consider increasing wait times between attempts[1].
  • Default passwords: change immediately after the first sign-in with a default password[3].
  • Hints and input: no password hints and no knowledge-based security questions; allow paste, autofill and password managers[1].
  • Storage and transmission: salt and hash passwords with a password hashing scheme, and never transmit authentication information in clear text[1][3].
  • Reset: re-verify identity first, then send a one-time, time-limited reset token such as a link or code[3].
  • Password manager: use the company-designated enterprise product, require MFA on the vault, never reuse the master password elsewhere, and keep work and personal vaults separate[7].
  • MFA: require MFA on every external sign-in point and every privileged account, with phishing-resistant MFA first for administrators, as set out in the MFA rollout guide.
  • Shared and service accounts: shared accounts are prohibited by default, and exceptions must be registered and kept in a shared vault; service account secrets are managed centrally, rotated automatically and never written into source code[11].

Action checklist

  • Work out which rules apply to you: whether you are an agency covered by the Cyber Security Management Act and at what level, whether you are a listed company, and whether any customer contract references Annex 10.
  • Compare your current password policy line by line with NIST SP 800-63B-4 and Annex 10, mark the conflicts, and record how you handle each and why in your risk assessment.
  • Add a breached-password check to the registration, change and reset flows of systems you build, and check whether your identity platform already offers banned-password protection.
  • Check that every system accepts at least 64 characters, spaces and paste, and remove password hints and security questions.
  • Choose an enterprise password manager, require MFA to open the vault, and set up a vault handover process for joiners and leavers.
  • Inventory shared and service accounts: split what you can into individual accounts, move the rest into a shared vault or a secrets management system, and write down when each is rotated.
  • Start rolling out passkeys or hardware security keys with administrators and high-value accounts, and steadily reduce the number of systems that rely on passwords.
  • If you need outside help reviewing accounts and authentication settings, see our security health check service.