The Password Rules Your Business Follows Are the Ones NIST Tells You to Stop Using

Three rules the guidance now tells systems not to impose

The current NIST guidance states that verifiers shall not require periodic password changes, shall not impose composition rules such as requiring mixed character types, and shall not prompt for security questions. All three of those remain standard practice in a great many small business systems today.

Start with the caveat, because it changes how to read everything below. NIST SP 800-63B is written for federal agencies and the digital identity systems they operate. It is not law for a Naples business, and nobody is going to audit your login screen against it. It is a benchmark, and a good one, because it is the document most security advice is ultimately derived from, usually at second or third hand.

The first prohibition is the one that will surprise people most. The guidance states that verifiers shall not require subscribers to change passwords periodically, and that a change shall be forced only where there is evidence the authenticator has been compromised¹. The quarterly password reset, still standard in a great many businesses, is the specific practice being ruled out.

The second concerns complexity theater. Verifiers shall not impose composition rules, with the guidance giving the example of requiring mixtures of different character types¹. The requirement for a capital, a number and a symbol produces predictable results, because people satisfy it in predictable ways, and it makes passwords harder to remember without making them meaningfully harder to guess.

The third is security questions. The guidance states that verifiers shall not prompt subscribers to use knowledge-based authentication, giving the example of asking the name of a first pet, or use security questions when choosing passwords¹. The answers are frequently discoverable, sometimes from the business own website, and they function as a weaker parallel password that bypasses the strong one.

The number that moved, and what it implies

The July 2025 revision requires a minimum of 15 characters where a password is the only factor, and permits eight only where the password is part of a multi-factor process. The widely quoted eight-character minimum comes from the superseded revision.

Here is the change almost nobody has reported. The guidance requires passwords used as a single-factor authentication mechanism to be a minimum of 15 characters, and allows passwords that are only used as part of multi-factor authentication processes to be shorter, with a minimum of eight¹. Read that as a trade: the second factor is what buys you the shorter password.

That reframes the MFA decision usefully. Turning on a second factor is not only a security upgrade, it is what makes a normal-length password acceptable in the first place. If you have no second factor on your website administrator account, the current bar for that password alone is nearly double the figure most people are working from.

Length is also where the guidance is generous rather than restrictive. It says verifiers should permit a maximum password length of at least 64 characters¹, and its own appendix advises allowing at least 64 characters to support passphrases and encouraging people to make passwords as long as they want, using any characters they like including spaces. A short maximum length is a defect, not a security measure.

The practical consequence for a small business is a simpler policy than the one it probably has. Long passphrases, no forced expiry, no composition rules, and a second factor wherever the platform offers one. That is less work to administer than the quarterly reset cycle, which is worth saying because security advice usually asks for more effort rather than less.

What to check a password against instead

Rather than composition rules, the guidance requires comparing a new password against a blocklist of commonly used, expected or compromised values, with the whole password compared rather than substrings. That is a check against reality instead of a check against a pattern.

If the rules are gone, something has to replace them, and the replacement is better targeted. When a password is set or changed, the guidance requires the verifier to compare it against a blocklist containing known commonly used, expected or compromised passwords¹. The question changes from whether the password looks complicated to whether it is already known to attackers.

One detail in that requirement is worth noting because it prevents a common implementation mistake. The entire password shall be subject to comparison, not substrings or words that might be contained within it¹. A passphrase containing a common word is not thereby a bad passphrase, and systems that reject anything containing a dictionary word are solving a problem the guidance does not describe.

The guidance also notes that excessively large blocklists give little incremental benefit, because the blocklist defends against online attacks that are already limited by rate limiting¹. And where a password is rejected, verifiers shall offer guidance to help the person choose a strong one, which the document notes is particularly important after a rejection because it discourages trivial modifications of a weak password¹.

For a small business none of this requires buying anything. Most password managers and several platforms already check new credentials against known breach corpora. The useful shift is conceptual: stop grading passwords on how they look and start checking whether they have already appeared in a breach, which is the only property an attacker actually exploits.

Not all second factors are equally useful

CISA states that MFA forms differ in strength and names the attacks each is exposed to: phishing, push bombing, SS7 interception of text messages, and SIM swap. It ranks phishing-resistant methods highest, app-based authenticators next, and codes sent by text or voice lowest of all.

Turning on multi-factor authentication is the single highest-value change most businesses can make, and the version you choose still matters. CISA states plainly that not all forms of MFA are equally secure, and that some are vulnerable to phishing, push bombing attacks, exploitation of SS7 protocol vulnerabilities, and SIM swap attacks².

The two attacks worth understanding are the ones aimed at your phone number rather than your phone. SS7 vulnerabilities in communications infrastructure can be exploited to obtain codes sent by text or voice². SIM swap is social engineering in which attackers convince a cellular carrier to transfer control of a phone number to a SIM card they control², after which every code sent by text arrives with them.

CISA ranks the options from strongest to weakest. Phishing-resistant methods, meaning FIDO and WebAuthn authentication and public key infrastructure based approaches, sit at the top and are described as "the gold standard"². App-based authenticators come next, covering one-time codes, token-based codes and push notifications with number matching. Text message and voice codes are the weakest tier listed.

The honest framing for a small business is not to dismiss the weaker options. A text-message code is enormously better than no second factor, and CISA has consistently urged organizations to implement MFA for all users and all services². Where phishing-resistant methods are not yet practical, CISA points to additional controls such as number matching². Start where you can, then improve the method.

• A second factor of any kind beats no second factor.
• Codes by text are the weakest tier CISA lists, for reasons it names.
• An authenticator app is a free upgrade over text messages.
• Passkeys and security keys are what CISA calls phishing-resistant.
• Turn it on for email first. Email is how every other account is reset.

The question nobody asks: who still has an account?

Credential strength is irrelevant if a developer from four years ago still holds an administrator login. The inventory is free, takes an afternoon, and is the part of this subject that never appears in security marketing because nothing needs to be purchased.

Everything above concerns the strength of a credential. This section concerns how many of them exist, which is usually the larger problem and always the cheaper one to fix. Open the users list on your website and read it properly. On most small business sites it contains people who left, contractors who finished, plugins that created accounts, and at least one login nobody present can identify.

This connects directly to the compromise route we covered in what Google does when a site is hacked, because an unused administrator account is a working door that nobody is watching. It also mirrors the ownership problem in who actually controls your domain name. In both cases the risk is not sophistication, it is that access outlived the relationship it was created for.

The remedy is a list and a habit. Write down every system that grants access to your business online: the website, the domain registrar, the hosting account, email, Google Business Profile, analytics, social accounts and any booking or invoicing tool. For each one, name who has access and why. Anyone you cannot justify gets removed, and anyone who leaves gets removed the week they leave rather than at some future tidy-up. The principle is in the guidance too: compromised authenticators are to be suspended, invalidated or destroyed promptly once compromise is detected¹.

And the boundary on what we will claim, which is the same one we set in the piece on patching. None of this makes an account impossible to compromise, and we are not going to tell you otherwise. What it does is remove the routes that require no skill at all: a shared password from 2021, a former contractor still holding administrator rights, and a login with no second factor on it. If you would like a look at how your setup currently stands, our free SEO audit is a reasonable starting point.

1. List every system that grants access. Website, registrar, hosting, email, Business Profile, analytics, booking, invoicing.
2. Read the users list on each one. Name every account and why it exists. Unidentifiable accounts are the finding.
3. Remove access the week somebody leaves. Not at the next review. Access that outlives a relationship is the common failure.
4. Turn on a second factor, starting with email. Email resets everything else, so it is the account that protects the others.
5. Replace text-message codes where you can. An authenticator app costs nothing and removes the SIM swap route.
6. Stop forcing password changes. Change on evidence of compromise, which is what the current guidance actually asks for.