Setting Password Policy for Two Hundred Staff, and the Questions Your Provider Should Answer Cleanly

If you are renewing an identity contract this quarter, the policy you are about to inherit was probably designed around 2015, when the accepted answer to account security was to make every user do more work more often. Eight characters minimum, one uppercase, one digit, one symbol, a forced change every ninety days, a security question about your first pet, and a text message with a six-digit code if the account mattered. Almost every element of that stack has since been revised or replaced, and the revision came from the same institutions that wrote the original rules. What follows is the comparison, and the questions that get an honest answer out of a vendor.

What the old stack was actually solving

The composition rules were not arbitrary. They were built for a world where the realistic attack was offline cracking of a stolen hash file, and where a dictionary attack against short lowercase words succeeded quickly, so adding character classes genuinely raised the cost. Rotation was built for a world with no reliable way to detect that a credential had leaked, so the assumption was that every password was quietly compromised and the fix was to expire it on a clock. Both measures were rational responses to real gaps in monitoring. What broke them was not new cryptography but observed human behavior at scale.

Once organizations began measuring what employees actually did under those rules, the pattern was consistent: predictable substitutions, incremented digits at the end, and the same base word carried across the corporate account and the personal one. The National Institute of Standards and Technology, which is responsible for the federal digital identity guidelines that most private-sector policies quietly copy, revised its guidance to reflect that. The short version of the change is that length was promoted, mandatory complexity and scheduled rotation were demoted, and the burden moved from the user to the system.

What replaced each piece, item by item

Length replaced complexity. A long passphrase that a person can actually recall outperforms a short string with a symbol jammed into it, and modern guidance supports substantially higher maximums, permitted spaces, and the full character set rather than a list of forbidden punctuation. Screening replaced scheduled expiry. Instead of expiring everyone's credential every ninety days, the system checks each new password against a list of known-breached and commonly used strings at the moment it is set, and forces a change only when there is evidence of compromise. That single substitution removes the most disliked rule in the building while tightening the actual control.

On the second factor, the ten-year gap is wider still. In 2015 a text message code was a meaningful upgrade over nothing. Now SIM swapping and real-time phishing proxies have made SMS the weakest of the available options, and the direction of travel is toward phishing-resistant factors: hardware security keys, platform authenticators, and passkeys bound to the origin so that a convincing look-alike domain cannot harvest anything reusable. Knowledge-based questions have largely been retired outright, because the answers are either public record or sitting in a breach corpus somewhere.

The questions to put across the table

Ask the provider how new passwords are screened, and listen for whether the check happens at the moment of setting or on some later batch job. A good answer names the source of the breach corpus, says how often it is refreshed, and explains what the user sees when a password is rejected. A poor answer is that the product enforces complexity requirements, which is a description of 2015. Ask whether rotation can be switched off per policy group, and whether your auditors have accepted that before. Ask what the fallback is when a hardware key is lost on a Tuesday morning.

That last one matters more than the marketing does. Recovery is where credential systems fail in practice, because a help desk that will reset a factor after hearing an employee's date of birth has reintroduced the weakest link at the exact point you spent money to remove it. Ask who is authorized to approve a reset, what evidence they require, whether the process is logged in a way you can pull six months later, and how long a temporary credential stays valid. Vague answers about a support portal are not answers. A provider that has thought about this will describe the manager-attested or in-person verification path without being prompted.

Where the cost actually sits in a migration

The license line is rarely the expensive part. The cost sits in the applications that will not federate: the old payroll module, the industry-specific scheduling tool, the vendor portal your accounts payable clerk logs into weekly, each of which keeps its own password table and its own rules. Inventory those before you sign, because the number of them determines whether you are buying single sign-on or buying a second password manager with extra steps. Ask the provider to price the connectors, name which of your systems they have integrated before, and put a date on anything described as being on the roadmap.

Then ask about the sequence. A sensible rollout raises length limits and turns on breach screening first, because those are invisible to most staff and reduce risk immediately; moves administrators and finance to phishing-resistant factors next, since those accounts carry the loss; and stops forced rotation only once monitoring is genuinely in place. Doing it in that order means each stage stands on its own if the next one slips, and it gives you something concrete to show an auditor or an insurance carrier asking about multifactor coverage on privileged accounts.

The useful test of any provider in this market is whether they can explain what changed since 2015 and why, in plain language, without being led. The ones who can will also tell you which parts of your current policy to keep, and that is usually the answer worth paying for.