Motta Industries Blog

If your website lets customers create accounts, you are running a small identity system whether you meant to or not. Every login form makes choices about passwords, verification codes, recovery and lockouts. Many of those choices were set years ago, copied from another site or left at a plugin’s defaults, and some of them now work against both security and the customers trying to sign in.

In 2025 the National Institute of Standards and Technology finalized the fourth revision of its digital identity guidance for authentication. The guidelines are written for federal agencies and the services they run, so a small business is not bound by them. But they are among the most carefully reasoned public advice on login security available, and they are often used as a reference by auditors, insurers and software vendors. This article translates the parts that matter most for customer accounts into practical decisions.

What NIST published and why it matters

The final NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, is dated July 2025. It covers how people prove they are the rightful holder of an account, what kinds of authenticators can be used and how those authenticators should be managed over their life.

Its significance for businesses is less about any single rule than about direction. The guidance moves away from habits that frustrate users without stopping attackers, and toward methods that resist phishing. That direction lines up with what large platforms have been doing, which means your customers increasingly expect it too.

Password rules worth retiring

Many sites still enforce password rules that the guidance explicitly rejects. Under the final text, verifiers shall not impose composition rules such as requiring mixtures of different character types, and shall not require people to change passwords periodically. A change should be forced only when there is evidence that the password has been compromised.

The guidance also says verifiers shall not let people store a hint that an unauthenticated person can see, and shall not prompt people to use knowledge-based questions such as the name of a first pet when choosing passwords.

Length takes the place of complexity. When a password is the only factor, the guidelines require a minimum of 15 characters. When it is used as part of multi-factor authentication, it may be shorter but must be at least eight characters. They also say sites should permit a maximum length of at least 64 characters and should accept spaces and a wide range of characters, which makes long passphrases practical.

Rather than complexity rules, the guidance calls for checking new passwords against a blocklist of commonly used, expected or compromised values, and asking for a different one if there is a match.

For a customer account system, that means a few concrete changes. Remove the requirement for a symbol and a number. Stop expiring passwords every ninety days. Allow long passwords and paste, so password managers work. Check against a list of known weak and breached passwords instead.

Why phishing resistance is the real goal

The guidance is blunt about the limits of common methods. It states that passwords are not phishing-resistant, and that backup-code lists and out-of-band methods, which include many codes sent to a phone, are not phishing-resistant either. At its second assurance level, it says verifiers shall offer at least one phishing-resistant authentication option.

The Cybersecurity and Infrastructure Security Agency explained why in its October 2022 fact sheet Implementing Phishing-Resistant MFA. It described how attackers send a user to a fake login page that collects the username, password and six-digit code, how they bombard people with push notifications until someone taps accept, and how they exploit weaknesses in phone networks or persuade carriers to transfer a phone number.

The fact sheet called phishing-resistant MFA the gold standard and listed FIDO/WebAuthn authentication and public key infrastructure as the phishing-resistant forms. It also said that any form of MFA is better than no MFA, and that app-based or token-based one-time codes, or push notifications with number matching, are the best options for small and medium businesses that cannot immediately implement phishing-resistant MFA.

How passkey-style sign-in works

The phishing-resistant method most customers will meet is built on the W3C’s Web Authentication standard. The Level 2 Recommendation, published April 8, 2021, defines a way for web applications to create and use strong, public key-based credentials. Each credential is scoped to one specific site only, and credentials are created and used only subject to the user’s consent.

In everyday terms, the customer’s phone, computer or security key holds a private key that is not shared with the site, and the website holds only the matching public key. When the customer signs in, the device proves it holds the right key, usually after a fingerprint, face scan or device PIN. Because the credential is tied to the real site, a lookalike phishing page cannot use it.

NIST’s final guidance also addresses syncable authenticators, credentials that can be copied across a person’s devices through a provider’s sync service. Many consumers know these as passkeys. The guidance describes a common use of syncable authenticators in its second assurance level, noting that a properly configured one creates a key pair constrained to the domain where it was created, while it says syncable authenticators shall not be used at its highest level because the private key must be exportable. For most customer accounts on a business website, the second level is the relevant comparison.

Lockouts and guessing attacks

Every login form needs a defense against automated guessing, but heavy-handed lockouts can punish real customers. The guidance takes a measured approach. Unless a specific authenticator says otherwise, it says verifiers shall limit consecutive failed attempts on a single account to no more than 100 by disabling that authenticator. It describes that figure as an upper bound, and notes that lower limits are allowed.

It also lists techniques that reduce the chance an attacker can lock a legitimate person out. These include requiring a bot-detection challenge before an attempt, making people wait after a failed attempt for a period that grows as failures accumulate, from perhaps 30 seconds up to an hour, and using risk-based signals such as IP address, location, timing patterns or browser details to spot unusual behavior.

For a business site, the practical takeaway is to avoid the pattern of locking an account permanently after three wrong guesses. That design sends frustrated customers to support, gives attackers an easy way to block someone and rarely stops a determined bot. A gradual delay, combined with monitoring for unusual login activity across many accounts, usually serves both customers and security better.

Watch for credential stuffing too, where attackers try usernames and passwords leaked from other sites. Spikes in failed logins from many addresses, or many accounts failing at once, are signs to investigate with your host or developer.

Recovery is where account security often fails

A strong sign-in method does not help if account recovery is weak. Attackers often skip the front door and go straight to the forgotten-password link.

Review your recovery flow with the same care as the login itself. Where do reset links go, and how long do they stay valid? Can someone change the account’s email address and phone number in one step without confirming through the old ones? Do support staff reset accounts based on details anyone could find online?

Offer customers more than one way back in, such as a second registered device or saved recovery codes, and tell them clearly when recovery details change. A short notification saying “your email address was just updated” lets a real customer react quickly if it was not them.

Deciding what level of protection each account needs

Not every account carries the same risk. A newsletter preference center, a loyalty account with stored rewards and a portal holding invoices, medical forms or saved payment details are very different targets.

Start by listing what a customer account on your site can actually do or see. Can someone change a shipping address, view past orders, download documents, spend stored credit or message staff? The more an account can do, the stronger the sign-in and recovery should be.

For low-risk accounts, sensible password rules and good rate limiting may be enough. For accounts that hold personal documents or allow purchases, offering a second factor and passkey-style sign-in becomes much more important. For staff and administrator access, phishing-resistant methods should be the expectation rather than an option.

Write these decisions down. When a vendor proposes a new plugin or an insurer asks about your controls, you will have a clear answer about why each type of account is protected the way it is.

Practical steps for customer accounts

You do not have to implement everything at once. A sensible order looks like this.

First, fix the password rules. Remove composition requirements and forced expiry, allow long passwords and paste, and add a blocklist check. These changes are usually configuration rather than new development, and customers notice the relief.

Second, add a second factor for customers who want it, and make it straightforward to enroll. An authenticator app is a reasonable baseline for most stores and portals.

Third, offer passkey-style sign-in where your platform supports it. Present it as the easier option, not the scary security option, and keep a fallback for customers who are not ready.

Fourth, tighten recovery. Require confirmation before changes to email or phone, send alerts when recovery details change and train staff not to bypass checks under pressure.

Fifth, protect the accounts behind the accounts. Administrator and staff logins to the site, hosting and email deserve phishing-resistant methods first, because a compromised admin account exposes every customer at once.

Explaining changes to customers

Security changes can feel like friction if they arrive without explanation. When you retire password expiry or add passkeys, say so in plain language. A short message on the login page or in an email can explain that longer passwords are now allowed, that regular forced changes are gone and that customers can sign in with their device if they prefer.

Avoid alarming language. The goal is to make signing in both safer and easier, and the guidance supports that combination. Update help pages and support scripts at the same time, so staff can answer questions about new sign-in options consistently and customers hear the same explanation everywhere they ask.

Where to get help

Login security sits where design, development and hosting meet. Some changes are settings in your platform; others require code changes or a new authentication provider. If you would like an outside review, Motta’s trust and security team can assess your customer account flows against current guidance. Our website maintenance plans keep authentication plugins and libraries current, and our web hosting environment supports modern sign-in methods for both customers and staff.