Modern password policy, as defined by NIST SP 800-63B and reflected in PCI DSS 4.0, favors long passphrases, no forced periodic rotation, screening against known breached passwords and multi-factor authentication. For PSPs, PayFacs and ISVs, these rules apply to every user of their merchant console and back office, under their own brand.
Complexity rules and 90-day rotations survived for decades even though they made passwords weaker. This article, first written by Damien Fleuriot and updated in October 2026, explains why classic rules failed, what NIST now recommends, what PCI DSS 4.0 requires, how to screen passwords against breaches, whether passwordless logins are safe for a merchant console, and how operators enforce these rules for their merchants' users.
Why did classic password complexity rules fail?
Because they optimized for the wrong attacker. In 1979, Robert Morris and Ken Thompson's paper "Password security: a case history" proposed some of the first strength rules, with short minimum lengths and mixed character types, to resist guessing.
Decades of symbols, digits and forced expiry produced predictable patterns, passwords written on sticky notes and endless resets, while attackers moved on to breached password lists and phishing, which complexity does not stop.
What does NIST SP 800-63B recommend instead?
The US National Institute of Standards and Technology reversed course in 2017 and went further in Revision 4 of SP 800-63B, published in August 2025:
- Length over complexity: at least 15 characters when a password is the only authenticator, with support for at least 64 characters, spaces and Unicode.
- No composition rules: systems shall not require specific character types.
- No periodic rotation: change passwords only when there is evidence of compromise.
- Blocklist screening: check every new or changed password against breached, common and context-specific passwords.
What does PCI DSS 4.0 require for passwords and MFA?
PCI DSS v4.0.1, applicable in full since March 31, 2025, sets a minimum of 12 characters for passwords used to access system components (requirement 8.3.6), requires multi-factor authentication for all access into the cardholder data environment (requirement 8.4.2), and only requires 90-day rotation when a password is the single authentication factor (requirement 8.3.9).
In practice, a payment platform that enforces MFA and long passphrases satisfies both PCI DSS and NIST without forced rotation. The PCI DSS v4.0 guide for PayFacs lists the other requirements that became mandatory in 2025.
How should a payment platform screen passwords against known breaches?
By checking each new password against large breach corpora without sending the password itself. Services such as Have I Been Pwned's Pwned Passwords use k-anonymity: the platform sends only the first characters of a hash and compares the results locally.
Screening should run at sign-up and at every password change, and accounts whose credentials appear in a new breach should be prompted to change them, which is exactly the compromise-driven reset NIST recommends.
Are passwordless logins and magic links safe for a merchant console?
It depends on the method. Email magic links move the risk to the mailbox and can be intercepted or forwarded, as security researchers have pointed out, so they are a weak choice for a console that controls payouts and refunds.
Phishing-resistant methods, such as passkeys and hardware security keys based on FIDO2 and WebAuthn, are the strongest option for console access, alone or alongside a password. They also satisfy the multi-factor requirement when used with device unlock.
How do PSPs and PayFacs enforce these rules for their merchants' users?
At platform level, so every merchant user follows the same policy without each merchant configuring it. That means length-based passwords with breach screening, mandatory MFA for all users with access to payment data, role-based permissions, session limits and logs of every sensitive action.
On NORBr, these controls are part of platform operations and security, applied to every console under the operator's brand, while platform supervision tracks unusual access. The TLS configuration checklist covers the transport side.
_%2520a%2520game%2520changer%2520for%2520digital%2520transactions_-Cover.webp){kind=spacer}
