Password Policy

password policies let your organization control how strong local (platform) passwords must be, how often they expire, and whether old passwords may be reused policies are scoped (for example by user type and hierarchy context such as contact center) and can be turned on or off per scope several policy layers can apply together composition (simple and complex rules), lifecycle and reuse ( enforce ), and extra string or identity checks ( regex policy block—despite the name, it is driven by substring settings rather than a free form regular expression field) users who sign in only through saml or google sso still benefit from centralized idp rules; this page covers platform stored passwords used with normal login and password change flows how it works an administrator (or deployment process) defines one or more policy rows for the right context and user type (for example agent vs administrator), and sets enable so the rules apply when a user sets or changes a password (including forced change after reset), the platform evaluates each enabled policy type that is registered for that user and aggregates any violations into a single error for the user new users may be created in a “new” state on the next login the platform can require a password change before normal access, in addition to any expiry rules password history rows (salted hashes) are written when passwords change; reuse prevention compares the candidate password against those stored values how policies combine policy kind (configuration name) purpose simple ( simpleconfigurationpolicy ) yes/no composition required upper, lower, digit, special; optional allow list of special characters; optional ban on adjacent repeated characters complex ( complexconfigurationpolicy ) numeric minimums for length, uppercase, lowercase, digits, and special characters, plus maximum length enforce ( enforceconfigurationpolicy ) maximum age (mandatory change), minimum age (early warning before expiry), and reuse prevention against password history regex ( regexconfigurationpolicy ) substring rules forbid user id or display name inside the password (case insensitive), forbid listed strings, or require one configured substring all four can be enabled independently for the same user type where your deployment supports it composition checks ( simple and complex ) typically run together when both are enabled simple password policy stored in the simple password policy data (linked from password policy detail ) field / parameter meaning behaviour when enforcing allowed special character allow list text if non empty , every non alphanumeric character in the password must appear in this list if empty , no allow list restriction is applied by this rule required uppercase letter boolean at least one latin uppercase letter ( a – z ) required lowercase letter boolean at least one latin lowercase letter ( a – z ) required number boolean at least one digit ( 0 – 9 ) required special character boolean at least one character that is not a digit or latin letter (any other symbol qualifies as “special” here) allow repeated character boolean if false , the password must not contain the same character twice in a row (no aa , 11 , @@ , etc ) allow anagram boolean stored with the policy record for compatibility it is not evaluated during standard password validation in current product logic—do not rely on it to block anagrams of old passwords unless your release notes state otherwise typical validation messages users may see include reminders to use allowed specials, at least one small letter, one capital letter, one numeric value, one special character, or that the password contains repeated characters complex password policy stored in complex password policy field / parameter meaning how it is checked min pwd length minimum length password length must be ≥ this value max pwd length maximum length password length must be ≤ this value min number allow minimum digits count of 0 – 9 in the password min special character allow minimum “special” count of characters not matching \[0 9a za z] min lowercase character allow minimum lowercase count of a – z after non letters are stripped from consideration (same family of rules as simple policy) min uppercase character allow minimum uppercase count of a – z in the same sense if any bound fails, the user receives guidance that length or character counts are below the configured minimums (wording may vary slightly by deployment) enforce password policy stored in enforce password policy works together with user password history (prior salted hashes per user) field / parameter meaning behaviour max pwd age days uses the most recent password change timestamp from history if the password is older than this many whole day buckets (see rounding below), login / expiry handling treats it as expired and the user must change password min pwd age days after the password is older than this threshold (and still within max pwd age ), the user may receive a warning that the password will expire in a shown number of days (derived from max pwd age and age) disallow previous password integer when non zero , reuse prevention is on the new password is hashed and compared to each password history entry the platform still holds for that user in its active configuration cache; a match rejects the change values greater than 20 are stored capped at 20 in one code path, but the comparison itself does not stop after n rows—it evaluates all cached history rows for that user plan retention and audits accordingly setting the field to 0 disables this reuse check (other rules may still apply) pwd grace value integer present in the schema for compatibility; not used by password logic—leave unset or ignore reuse and max pwd age when reuse prevention is on and max pwd age is set, the platform also rejects a password whose hash matches a password that was set within the last max pwd age days (in addition to the general history scan) user state “new” if the account is still in a new user state, the expiry path can respond with a force change password outcome so the first platform password meets policy rounding age in days is derived from calendar time difference; partial days are rounded up when deciding whole day age for expiry, so behaviour matches “full days since last change ” regex password policy (substring and identity rules) stored in regex password policy the name reflects legacy wording; operators configure plain substrings , not a regular expression editor field / parameter meaning behaviour disallow user id boolean if true, the password must not contain the user’s login id as a substring ( case insensitive ) disallow user name boolean if true, the password must not contain the user’s display name as a substring ( case insensitive ) exclude strings text comma separated list of forbidden fragments if the password contains any listed fragment ( case sensitive match), it is rejected example password,123456,welcome forbids those exact substrings contain substring text if non empty, the password must include this exact substring ( case sensitive ) only one required phrase is supported in this field (not a list) master policy row password policy detail links everything to user type , context , context id , a name , and enable each enabled row can have child rows in the simple, complex, enforce, and regex tables as your deployment defines configuration parameters use these policy type identifiers when integrating with configuration apis or exports that list password policy blocks exact ui navigation depends on your edition (on prem administrator vs cloud configuration portal); map these keys in your user / security / password settings area for the right hierarchy and user type key / parameter description how to configure constraints / allowed values sample simpleconfigurationpolicy simple composition toggles and optional special character allow list enable per user type + context ; edit simple password policy fields (or equivalent ui) booleans true / false ; allow list is a string of permitted special characters; empty allow list disables allow list filtering required number=true , allowed special character=@#$% complexconfigurationpolicy minimum counts and password length bounds same scope as simple; edit complex password policy non negative integers; min pwd length ≤ max pwd length min pwd length=12 , min number allow=2 enforceconfigurationpolicy age, warning, reuse same scope; edit enforce password policy and ensure history retention matches compliance goals ages in days ; disallow previous password 0 = off, non zero = on (stored value may cap at 20 , but checks use all retained history rows); pwd grace value unused max pwd age=90 , min pwd age=80 , disallow previous password=5 regexconfigurationpolicy substring / identity rules same scope; edit regex password policy comma separated exclude strings ; single contain substring ; booleans for id/name checks exclude strings=companyname,welcome configuration steps (administrator checklist) decide which user types (for example agents, supervisors, administrators) need stricter rules identify the correct hierarchy context (for example contact center or tenant) where policy is defined for your product edition create or update password policy detail with enable = true for that combination fill simple and/or complex rows if you need composition rules fill enforce if passwords must expire or cannot repeat ; confirm password history is populated on change fill regex row if you must block company names , default passwords , or forbid user id / name fragments test with a non production user set passwords that should pass and fail each rule and confirm messages are acceptable for your agents show / hide password (eye icon) starting from version 4 13 3, a show/hide toggle (eye icon) is available on the /app and toolbar login screens, allowing users to reveal or hide their password while typing in version 4 13 4, this was extended to all password fields throughout the ui user id and username character restrictions starting from version 4 13 48, administrators can enforce character restrictions on user ids and usernames via two configurable regex flags in the server preference store at the contact center level allowed userid regex — restricts which characters are accepted when creating or updating a user id allowed username regex — restricts which characters are accepted for usernames these constraints apply to both individual user creation/update in the ui and bulk user uploads limitations and notes allow anagram is not enforced by the standard validator despite appearing in the schema pwd grace value is unused disallow previous password effective ceiling 20 ; behaviour depends on how many history rows exist for the user sso users may rarely set a local password; strongest guarantees come from the idp for saml/google mfa release notes reference password policy alignment with mfa—keep mfa and local policy coordinated cloud vs on prem behaviour and ui entry points should be confirmed for your specific release; configuration keys above align with shared service naming related topics user login & single sign on (sso) — normal login (platform user id and password), saml , and google sso; password policies apply to local passwords and complement idp rules for sso users administrator login / supervisor login — where login options appear for each persona login – logout (reporting) — audit of sign in and sign out events version history version enhancement release notes 4 13 3 show/hide password eye icon on /app and toolbar login screens 4 13 3 release notes docid\ aaq9hd2jykmjbsrfyaane 4 13 4 eye icon extended to all password fields in the ui 4 13 4 release notes docid\ jomnaxu6jtlbecpeceyxc 4 13 48 configurable allowed userid regex and allowed username regex at contact center level contact center patch release notes version 4 13 48 docid\ ohmti dqxjpuejrdrcdz0