Password Policies
Password Policies is the Salesforce Setup page where an administrator defines the password rules that apply to user accounts in the org.
Definition
Password Policies is the Salesforce Setup page where an administrator defines the password rules that apply to user accounts in the org. The settings cover minimum length, complexity, expiration interval, password history, the security question used for resets, and how many failed logins trigger a lockout.
These rules form the baseline for every account that signs in with a Salesforce password rather than single sign-on. You set them once at the org level, and you can also override them per profile so different groups of users get stricter or looser requirements.
How password rules are configured and enforced
Where the page lives and what it covers
You reach the org-wide page from Setup by typing Password Policies into Quick Find and selecting Password Policies. The page is one form with a handful of fields, and each field maps to a specific rule that the login service checks every time a user signs in or changes a password. The grouping is loose but practical. The top fields handle expiration and history, the middle fields handle length and complexity, and the lower fields handle lockout behavior and the forgotten-password flow. By default a Salesforce password must contain at least eight characters, including one letter and one number. It cannot contain the user's username, and it cannot match the user's first or last name. Those constraints exist before you touch anything. The page lets you raise the bar from there. Salesforce also caps password length at 16,000 bytes, so you do not need to worry about users pasting unusually long passphrases. Editing the page requires the Manage Password Policies permission, which is why this work usually sits with a security admin rather than a general user admin.
Length, complexity, and history
Minimum password length defaults to eight and can be raised. Password complexity requirement is a dropdown with several choices, from no restriction up to requiring three of four character classes (numbers, uppercase, lowercase, special characters). The strongest preset asks for all four classes plus a special character. Pick the option that matches your standard, then communicate it, because users notice the day the rule changes. Enforce password history controls how many previous passwords the system remembers so a user cannot reuse them. The default remembers three, and you can set up to 24. You cannot set this to zero unless expiration is turned off. Require a minimum 1 day password lifetime is a related toggle. It stops a user from cycling through several password changes in one sitting just to land back on an old favourite. These three settings work together, so treat them as a set when you write your standard down.
Expiration and the reset experience
User passwords expire in sets the rotation interval, with a default of 90 days and a Never expires option at the bottom of the list. Choosing Never expires loosens the policy and disables history enforcement, so it is a deliberate decision rather than a convenience. Modern guidance from NIST actually favours longer or no forced rotation paired with strong length and breach screening, so do not assume a short interval is automatically more secure. Match the interval to the framework you answer to. Two settings shape the reset flow itself. Password question requirement decides whether the security answer can contain the password text, and Obscure secret answer for password resets hides the answer as the user types it instead of showing it in plain text. There is also a control that keeps the link in a forgotten-password email valid for a 24 hour window rather than expiring it the moment a newer request arrives. Each of these is small on its own, but together they decide how forgiving or strict the account-recovery path feels.
Lockout behavior and brute-force defense
Maximum invalid login attempts sets how many wrong passwords a user can enter before the account locks. Lockout effective period sets how long the lock lasts before it clears on its own, with a default of 15 minutes. You can also set the lock to stay until an administrator releases it. Together these two fields are your main defence against password guessing and credential-stuffing attempts. There is a trade-off to think through. A very low attempt threshold combined with a permanent lock will stop attackers, but it also generates help-desk tickets every time a real user fat-fingers a password a few times. A common middle ground is a threshold around ten attempts with a timed lock of 15 to 30 minutes, which frustrates automated attacks without burying your support queue. Watch the Login History page after you change these values. It shows you locked-out events and failed attempts so you can confirm the policy behaves the way you intended.
Org-wide settings versus profile overrides
Everything on the Password Policies page sets the default for the whole org. You can then override those defaults on individual profiles. Open a profile, select Password Policies, and edit the same fields there. Profile password policies take precedence over the org-wide settings for users assigned to that profile. If you leave a profile's policies unset, the org-wide values apply to those users instead. This split exists because not every account needs the same treatment. You might run a strict profile for administrators and integration accounts and a lighter profile for read-only users. One important timing detail catches people out. New profile password policies take effect for existing users on that profile only when they next reset their password, not the instant you save. So a tightened rule rolls in gradually rather than all at once. Plan communication around that delay, and consider forcing a reset if you need the new rule to apply immediately.
Where this fits in your wider security posture
Password Policies is the floor, not the ceiling, of account security. For most workforce users the better answer is single sign-on, which moves authentication to your identity provider and makes these Salesforce-side rules largely irrelevant for those accounts. Multi-factor authentication is required for direct Salesforce logins and adds a second factor on top of whatever password rule you set. None of that removes the page, because integration users, API-only accounts, and any user who still signs in with a Salesforce password all fall under these settings. Compliance frameworks are the usual reason orgs tighten the defaults. PCI DSS, SOC 2, and NIST controls all reference password parameters explicitly, so set the fields to your tightest applicable standard and record the alignment. Review the page during every audit cycle, and pair it with Login Access Policies, Session Settings, and Health Check for the full picture. Health Check in particular scores your password settings against a Salesforce baseline and flags gaps.
How to set password policies in Salesforce
Set the org-wide password rules from Setup, then override them on specific profiles if certain user groups need stricter or looser requirements. You need the Manage Password Policies permission.
- Open the Password Policies page
From Setup, type Password Policies into the Quick Find box and select Password Policies. This is the organization-wide page that sets the default rule for every user who is not covered by a profile override.
- Set length, complexity, and history
Choose a Minimum password length, pick a Password complexity requirement from the dropdown, and set Enforce password history. Turn on Require a minimum 1 day password lifetime if you want to stop rapid reuse cycles.
- Set expiration and lockout
Pick an interval under User passwords expire in (or Never expires), then set Maximum invalid login attempts and Lockout effective period to control brute-force defence. Adjust the reset-flow options for the security question if needed.
- Save, then override per profile if needed
Click Save. To make a group stricter, open that profile, select Password Policies, edit the same fields, and save. Profile settings override the org-wide values for those users.
Smallest allowed password size; defaults to 8 characters and can be raised to meet a tighter standard.
Dropdown of character-class rules, from no restriction up to requiring three or four of numbers, uppercase, lowercase, and special characters.
Rotation interval before a forced password change; defaults to 90 days, with a Never expires option that also disables history.
Number of previous passwords the system blocks from reuse; defaults to 3 and supports up to 24.
Failed sign-ins allowed before the account locks; pairs with Lockout effective period (default 15 minutes) to slow brute-force attacks.
- Profile password policies override the org-wide page, so check both places when a user's rule does not look right.
- A tightened policy applies to existing profile users only when they next reset their password, not the moment you save.
- Choosing Never expires disables password history enforcement, so you lose reuse protection along with rotation.
- Single sign-on users authenticate through your identity provider, so most of these rules do not apply to them; integration and API-only accounts still do.
Prefer this walkthrough as its own page? How to Password Policies in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Set Password PoliciesSalesforce
- Password Policy Fields in ProfilesSalesforce
Straight from the source - Salesforce's reference material on Password Policies.
Hands-on resources to go deeper on Password Policies.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Which setting belongs on the Password Policies page rather than elsewhere in Setup?
Q2. Why do most orgs tighten the default Password Policies values after a security audit?
Q3. Whose logins are still governed by Password Policies after an org adopts workforce SSO?
Discussion
Loading discussion…