This password security checklist tests a firm’s own sign-in settings. It has 14 checks across passwords, multi-factor sign-in and passwordless sign-in. Each check has a task, evidence to keep, a yes or no pass test and a source. Marks run 2, 1 or 0 per check, with a maximum of 28 and no target total.
Last reviewed 2026-11-02 by Manish Sharma.
The reader is an IT manager or business owner at a firm of 250 to 2,000 people in India or the GCC. It suits anyone who runs, or answers for, sign-in settings. Ordinary staff accounts are in scope, but administrator, privileged and service accounts stay out. The guidance comes from NIST, the NCSC and CISA, which are US and UK sources. The list uses no statistics and names no product.
Password Security Checklist in Short: What It Tests and What It Skips
Sign-in settings sit in three places, and the 14 checks of this password security checklist follow the same grouping.
Two rules are missing from this list on purpose. Some password checklists tell firms to require a mix of upper case, lower case, numbers and symbols, and to change passwords on a timetable. One search engine’s AI answer, read in November 2026, also gave this advice and named every 90 to 120 days.
NIST SP 800-63B, the 2025 edition of US federal guidance, says providers shall not impose other composition rules. The NCSC’s Password policy: updating your approach (UK, reviewed 2018) advises against complexity requirements and against regular expiry. Its readers are security professionals and large organisations. No row of this list asks for either rule.
The account-ownership checklist covers how to write the password rule, as well as who owns each account. A separate article on why passwords fail gives the reasons behind both sources’ advice. Both sources are guidance, not regulation.
Marking Rules: Two Points, One Point or Zero
Each check on this password security checklist earns 2, 1 or 0. The marks, the sample and the pass tests are Signisys’ own method, built on the sources named in each row.
- 2: the test passes everywhere it applies, and the row’s evidence is on file with the day it was taken.
- 1: the test passes for part of the estate, such as one app or one department, or the setting is right but not shown.
- 0: the test fails, or nobody has looked.
A setting that is only described, with nothing to open, scores 1 at most.
Where a pass test says sample, take five accounts. Choose two long-standing accounts and two that joined in the last month. Add one from a part-time or contractor group, and write the five down.
If a check does not apply, mark it N/A and count the maximum without its 2 points. For example, a firm with no passwordless sign-in marks checks 12 to 14 N/A, so its maximum falls from 28 to 22. The maximum of 28 is arithmetic, not a standard, and there is no target.
Here is an illustration, not a client: the directory sets a minimum of 15 characters, but a mail app allows 10. The test does not hold everywhere, so check 1 scores 1.
Key Takeaway A setting that is right in the directory but wrong in one app earns 1, not 2.
Password Security Checklist, Group 1: Passwords
Checks 1 to 6 of this password security checklist test password settings in the directory and in every app that keeps its own passwords. NIST writes its figures for US federal systems, but a firm can set stricter ones.
Checks 1 and 2: Length and Screening
| Check and task | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| Check 1, Length: set the shortest password for each place one is typed, and allow a long passphrase. | A dated export of each length setting, including the directory and every app with its own passwords. | Yes if the minimum is at least 15 characters where a password is the only step, at least 8 where a second step is also required, and passphrases of 64 characters or more are accepted. A system that meets the minimums but caps below 64 scores 1. | NIST SP 800-63B sets 15 and 8 as minimums (shall) and recommends that a maximum of at least 64 characters be permitted (should), while the NCSC (2018) says to avoid a maximum that users could exceed; making 64 a pass condition is our test. |
| Check 2, Screening: turn on a blocklist check whenever a password is set or changed. | The setting screen, plus a test record, such as a common value and one containing the firm’s name tried on a test account, with the message shown. | Yes if both are refused, the whole password is compared rather than words inside it, and the person is told why. | NIST SP 800-63B covers comparison against commonly used, expected or compromised values, the entire password and a stated reason, and the NCSC also advises a deny list. |
Checks 3 and 4: Choosing a Password and Guessing Limits
Two more settings follow: what people may type, and the number of wrong tries a system allows.
| Check and task | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| Check 3, Choosing a password: drop forced mixes of character types, and allow paste and password managers when people sign in or change a password. | The policy export showing no character-type rule, and a test record for each sign-in page, including pasting and autofill. | Yes if no character-type rule remains and paste and autofill work on the sign-in and change screens. | NIST SP 800-63B says providers shall not impose other composition rules, shall allow password managers and autofill, and should permit paste, while the NCSC advises against complexity requirements. |
| Check 4, Guessing limits: slow or stop wrong passwords when they are tried again and again on any account. | The throttle or lockout setting, plus a test account given wrong passwords until the limit acts, for example a delay or a lock. | Yes if the system delays or blocks further tries after a set number of wrong attempts, that number is 100 or fewer, and any lockout acts at 5 to 10 attempts with a way back in. | NIST caps failed attempts at 100, an upper bound, while the NCSC prefers throttling and, if lockout is used, allows 5 to 10 attempts; the 5 to 10 test is our check. |
Checks 5 and 6: Storage and the Reset Path
Storage and reset sit behind the sign-in screen.
A hosted service’s statement is evidence the firm collects, but it is not a setting the firm sees.
| Check and task | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| Check 5, Storage: confirm that each system that keeps passwords stores them as salted hashes rather than readable text. | For a system the firm runs, a configuration note naming the hashing scheme, but for a hosted service, the supplier’s dated written statement. | Yes if every system that stores passwords has such a document. | NIST SP 800-63B says passwords shall be salted and hashed with a suitable scheme, and the NCSC says hashed using multiple iterations of the hash function, but asking the supplier for a statement is our check. |
| Check 6, Reset path: review how a forgotten password is reset, and who does it when the person calls the helpdesk. | The written reset steps, plus a test record of one reset, including the notice the person received. | Yes if no reset uses a security question or personal-fact prompt, the helpdesk checks the person’s identity before a reset, and the person gets a notice afterwards. | NIST SP 800-63B says providers shall not prompt people to use security questions when they choose a password, and that account recovery shall send the person a notice, but applying the security-question point to the reset path, and the helpdesk identity check, are our checks. |
Password Security Checklist, Group 2: Multi-Factor Sign-In
Group 2 of the password security checklist gives coverage, method and recovery each their own check, which keeps one tick from hiding a gap. For a plain definition of the second step, see what multi-factor authentication adds at sign-in.
Checks 7 and 8: Coverage and Method
The routes into company data come next, along with the second step each one asks for. CISA, the US Cybersecurity and Infrastructure Security Agency, wrote the Implementing Phishing-Resistant MFA fact sheet (October 2022) for IT leaders and defenders. It says not all forms of MFA are equally secure, and some are vulnerable to phishing.
| Check and task | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| Check 7, Coverage: list every way into company data, such as web apps, email, remote access and file sharing, and mark which enforce a second step. | A dated list built from the identity system’s policy, as well as each app’s own settings. | Yes if every route shows an enforced second step, or the route is listed as not covered, with the reason written. | Our check, while the NCSC (2018) says multi-factor sign-in should be the primary method for accounts reachable from outside, such as cloud services and remote access. |
| Check 8, Method: add to the list from check 7 the kind of second step each route uses, such as a code or a prompt. | The same list with a method column, such as text message or voice call, app code, approval prompt, hardware key or passkey. | Yes if every route has a method recorded, and any route that uses a text message or voice call has the reason written beside it. | CISA (October 2022) says text message or voice MFA should only be used as a last resort option, and that it can serve as a temporary solution while organisations move to a stronger method. This row ranks no method: it asks the firm to write each one down and give a reason for these two. That test is ours. |
Checks 9 and 10: Alternatives and Two Ways In
Checks 9 and 10 use the five-account sample from the marking rules.
| Check and task | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| Check 9, Alternatives: look for a weaker second step on offer when a person has a stronger one set up. | For each of the five sampled accounts, a screen record of the alternatives on offer at sign-in, as well as the allowed-methods setting. | Yes if every alternative offered appears on the method record from check 8. | Our check, although it builds on CISA’s point that not all forms of MFA are equally secure. |
| Check 10, Two ways in: have each person register two ways to pass the second step that do not rely on the same device, so that one lost device does not block sign-in. | A registration export showing methods per person, including the device each one relies on. | Yes if each of the five sampled accounts shows two methods on different devices, or one device plus recovery codes. | NIST SP 800-63B says providers should encourage at least two separate means of authentication, but the five-account sample is our check. |
Check 11: A Lost-Device Case That Works
Check 11 tests recovery by running it. If a firm has already rehearsed recovery as Step 4 of a passwordless rollout, that record can serve as the evidence.
| Check and task | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| Check 11, Lost device: run a lost-device case from the request until sign-in is restored. | The written path, including who verifies identity, who approves and how access is restored, plus the ticket from a rehearsal. | Yes if someone with no part in writing the path restored a test account, identity was checked by more than a call or an email request, and the person received a notice. | NIST SP 800-63B lists repeated identity checks, a prearranged recovery contact or recovery codes as recovery options, and says recovery events notify the person, but the rehearsal is our check. |
Password Security Checklist, Group 3: Passwordless Sign-In Where It Is Already On
Checks 12 to 14 of this password security checklist apply only when passwordless sign-in already runs. If it does not, mark all three N/A, read nothing into the gap, and use a maximum of 22. A separate step-by-step article covers moving to passwordless sign-in.
| Check and task | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| Check 12, Where it is on: list the accounts, groups and apps where passwordless sign-in has been switched on, and when. | A dated list with the sign-in method, including the date it was switched on. | Yes if the list matches the identity system’s sign-in policy, and no group is switched on that is missing from it. | Our check. |
| Check 13, The password’s state: write down whether a password is still accepted when a listed group signs in. | The sign-in policy setting, plus a test that tries a password for a listed account, including the result. | Yes if each group is marked “removed” or “still accepted”, and the test result matches. | Our check, but deciding to remove a password is outside this row. |
Check 14: Devices Recorded and Removed on Loss
Check 14 asks whether the firm knows which device holds each sign-in. It also asks whether the firm acts when one goes missing.
| Check and task | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| Check 14, Devices: keep a record of which device holds each person’s passwordless sign-in, and remove it when the device is lost or the person leaves. | An export of enrolled devices, plus two closed tickets, such as a lost device and a leaver, showing removal. | Yes if both tickets show the sign-in removed before the ticket closed. | Our check. |
Turning Your Password Security Checklist Result into a Fix Order
Run the password security checklist, then read the marks by group before reading the total. This order is ours, built on what each gap leaves open. No standard sets it.
Key Takeaway Treat a 0 as the job and a 1 as the follow-up.
Checks 7 and 11 lead in our view. Skip check 7, and a route may ask for no second step. Skip check 11, and a lost device may restore sign-in without an identity check.
Without checks 4 and 5, wrong passwords may be tried without a limit, and stored passwords may sit in readable form.
Without checks 1 to 3 and 6, a system may accept short or known-bad passwords, and a reset may rest on a guessable prompt.
A weaker second step may stay on offer without checks 8 to 10, and one lost phone may block a person.
With checks 12 to 14 skipped, the real sign-in state may differ from the record, and a lost device may keep working.
For a hosted service, ask the supplier for the written statement that checks 4 and 5 need. Give each Fail a row on a short fix list. Note who owns it, what changes and the day you will test it again. When the fixes are in, run all 14 checks again. Keep the new sheet in the evidence folder under its own date.
Where the Password Security Checklist Stops, and When to Call a Specialist
This list leaves out administrator, privileged and service accounts, customer sign-in, choosing a product and ranking sign-in methods. It draws on US and UK guidance only, so it does not cover India or GCC rules. It also gives no statistics. A full score certifies nothing and is not an audit. Separate articles cover why passwords fail, how to move off them and how passkeys compare with multi-factor sign-in.
Get help when a Fail on check 7 or 11 stays open despite the firm’s own changes. Also ask for help if a hosted service’s supplier will not give the storage statement. The same goes for a 1 on check 4 or 5 that repeats across several apps. Signisys offers identity and access management and cybersecurity services, and this is a Signisys offer, not neutral advice.
Signisys provides identity and access management, helping organisations control who can access what, with single sign-on, strong authentication, privileged access and automated provisioning. Signisys agrees the exact scope for each engagement. The use-case page also describes a free Sign-In Security Review. Our Solution: Identity and Access Management (IAM). Our Service: Cybersecurity Services.
Password Security Checklist FAQ
Should staff still change their passwords on a timetable?
What proof should sit beside each mark on this password security checklist?
Do the length figures apply to a firm that is not a US federal body?
How do we score a check that depends on a software supplier?
What if nobody uses passwordless sign-in yet?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.