Checking at creation or reset prevents a bad password from ever being accepted, while checking only at login catches risk later and may leave the account exposed until the next sign-in. Login-time review can help when stored passwords cannot be revalidated easily, but it is a weaker control path. Strong programmes use prevention first, then login checks as a secondary safety net.
Password checks are stronger when they happen before the password is ever accepted
Checking at creation or reset is a preventive control. It stops a weak, reused, or known-compromised password from entering the account in the first place, which shrinks the window for exposure and reduces follow-on recovery work. Checking only at login is still useful, but it is reactive, because the account can remain unsafe until the next successful sign-in.
That difference matters operationally: creation and reset are the points where the organisation still has leverage over the credential choice, while login-time checking depends on the user returning and on the system being able to compare the stored password against a current risk source.
Why login-time checking is a weaker control path
Login-time review can catch a bad password only after it already exists in the account lifecycle. That makes it a secondary safety net, not the primary control. It is often used when stored passwords cannot be revalidated easily, when a legacy platform limits enforcement options, or when teams want to add a compensating check without changing the creation flow.
The drawback is simple: the account may be exposed for some period before the next sign-in, and dormant accounts may not be checked at all for long stretches. The control is therefore less effective at preventing initial acceptance of a risky password and less reliable as a universal enforcement point.
For a broader identity-security baseline, NHI programmes often emphasise prevention first because the blast radius of a bad secret or password grows over time; NHIMG’s Ultimate Guide to NHIs, the section on what non-human identities are is a useful reference for the lifecycle and governance perspective that underpins this control choice. In practice, the same principle applies to human passwords: the earlier you block acceptance, the less exposure you have to clean up later.
If you need a current compliance lens, PCI DSS v4.0’s account-control expectations reinforce the value of restricting access by need and managing system and application accounts carefully, which aligns with preventing risky credentials at the point of issuance rather than discovering them later at use.
What practitioners should do differently at creation, reset, and sign-in
Use creation or reset as the primary enforcement point for password strength, reuse, and compromise checks. Use login-time checks as a backstop for legacy systems, delayed remediation, or environments where you cannot immediately force every password through a reset path.
- What to verify: A password policy only helps if it is enforced where users can change the secret, not only when they authenticate.
- Decision rule: If the platform supports it, reject bad passwords at creation or reset first; if not, add login checks and plan to phase them out.
- What to measure: Track how many risky passwords are blocked before acceptance versus how many are detected later at login, because that shows whether the control is truly preventive.
NHIMG’s OneLogin API Key Vulnerability is a reminder that weak lifecycle controls around identity material can have real downstream impact when exposure is discovered late. A good password-control design tries to avoid that pattern by making bad credentials fail early, not merely detectable later.
Practitioner takeaway: Treat creation and reset as the main control point, and reserve login-time checking for compensating coverage where enforcement at issuance is not yet possible.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | 7 — Restrict Access by Business Need to Know | Password enforcement supports limiting access to only properly controlled accounts. |
| 8.6 — System and Application Accounts and Interactive Login | Directly addresses accounts whose authentication behavior must be controlled at issuance and use. | |
| Recommendation — Apply least-privilege account control to reduce exposure from risky or unnecessary credentials. Manage account passwords and interactive login paths so system accounts are not left with weak access. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The question concerns where authentication checks should occur in the identity lifecycle. |
| Recommendation — Place authentication enforcement at the earliest lifecycle point that the system can reliably control. | ||
| CIS Controls v8 | 6 — Access Control Management | Passwords are access-control material, and the key issue is when risky access is prevented. |
| Recommendation — Enforce credential checks before access is granted, then use login checks as a compensating control. | ||
Related resources from NHI Mgmt Group
- What is the difference between runtime protection and NHI lifecycle management?
- What is the difference between rotating a secret and revoking access?
- What is the difference between rotation and deprovisioning for NHIs?
- What is the difference between storing passwords and actually managing them securely?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
