Password Updates on the Web: What Makes Changing a Password So Hard
Published June 19, 2026 · Reading time approx. 6 minutes
Your password turned up in a data breach. The advice is clear: change it, now. But anyone who tries first has to dig through account settings, click past shifting labels like "Security," "Account," or "Edit profile," and ends up unsure whether the change even worked. The study "An Analysis of the Security, Usability, and Automation Capabilities of Password Update Processes on Top-Ranked Websites" (Krause et al., SOUPS 2026) is the first to systematically examine how 111 top-ranked websites implement changing and resetting passwords, and it exposes a striking range of gaps.
There is a simple reason the effort is worth it: the password is not going away. Passkeys, biometrics, and hardware tokens have been billed as its successor for years, yet in everyday use the password remains by far the most common way to sign in on the web. And even where newer methods are in place, it steps in as the fallback the moment a phone goes missing or a token fails. For the foreseeable future nothing replaces the password, neither as the primary method nor as the second line of defense. That makes it all the more troubling that changing a password, of all things, so often goes wrong.
111 Processes, Two Paths
Password updates have two typical triggers. With a password change (PWC), the user still knows their current password and deliberately replaces it, for example after a breach or to end shared access. With a password reset (PWR), they have lost access and must confirm their identity another way, usually via an email link or an SMS code.
Two researchers created real accounts on top-ranked websites from the Tranco list between September 2024 and February 2025 and worked through each process using a protocol of 32 attributes. 96 of the sites offered a password change, 109 a reset. The headline result: no two sites were alike. Navigation paths, forms, and security measures differed on every single website.
Even Finding the Form Is a Hurdle
Before a new password can be set, you first have to find the right form. On average that took two to six clicks, with three being most common. It does not help that the feature is named differently on every site. Sometimes "Account Security," sometimes "Edit Profile," sometimes simply "Authentication." On three sites the entry point could only be found via a search engine.
Some forms lived on a dedicated page with a stable URL, others opened as a pop-up with no address of their own, and still others were buried deep in profile settings. This lack of consistency has a cost: experience from one website barely transfers to the next. Every password change becomes a small scavenger hunt.
Security: The Old Password Often Stays Valid
The most important finding concerns sessions. A new password protects little if old logins keep running, and that is the rule rather than the exception. Only 8 of 96 sites for a password change, and 7 of 109 for a reset, actually logged out all devices. An attacker with an existing session stays logged in even after the change. The study therefore argues that a password update should be treated as a revocation, not a mere replacement.
Notifications show the same gaps. 34 of 96 change processes and 45 of 109 reset processes did not notify the user about the change at all. If an account is quietly taken over and its password changed, the rightful owner never finds out. Checks against known breaches, comparing a newly chosen password against leaked lists, were almost entirely absent: just a single site implemented them effectively in each process.
Usability: Inconsistent, Confusing Forms
Many forms make things needlessly hard. 21 of the 96 change forms lacked a confirmation field for the new password, letting typos slip through and lock users out. A visibility toggle, which lets you check what you typed, was missing on 43 of the 96 forms.
On top of that come contradictory password policies. While most sites enforced a policy at all (67% for change, 74% for reset), the same website sometimes applied different rules to change and reset. A password with a hyphen was allowed in one process but not the other. Password strength meters appeared on only about a third of sites (31% for change, 25% for reset), and their ratings were inconsistent. Built-in password generators were the rare exception, present on just two sites.
The feedback after submitting is especially frustrating. Often no confirmation appeared at all, sometimes only a tiny message that vanished after a second or two, occasionally a redirect with no text whatsoever. The user is left guessing whether the new password is now in effect.
Automation: Password Managers Are Left Out
Password managers could simplify updates considerably, yet few sites support them cleanly. The HTML autocomplete attribute, which lets a manager reliably tell current and new password fields apart, was set correctly across all login and update forms on only 9 of 111 sites. Fields frequently carried misleading or dynamically changing names that defeat automatic mapping.
The standard proposed by the W3C, a well-known URL at /.well-known/change-password, would route tools straight to the change form. Only 6 of 111 sites had adopted it. Then there are the "gatekeepers" of automation: RBA (risk-based authentication), two-factor prompts, and CAPTCHAs. They hinder automated processing but also protect against attacks. The study stresses that automation-friendly design must not undermine these protections.
What the Authors Recommend
The recommendations are ordered by priority and each grounded in concrete measurements.
High priority (security-critical):
- Treat updates as revocation: On a password change, terminate all other sessions, tokens, and cookies, and offer the user the option to do so.
- Always notify out of band: Inform the user via a separate channel such as email, ideally with remediation guidance in case the change did not come from them.
- Provide guided account remediation: Walk the user through related steps such as active sessions, recovery, and two-factor authentication, rather than treating the password update as a finished action.
Medium priority (prevents errors):
- Make updates unambiguous: Offer a confirmation field and a visibility toggle, give visible feedback, and display the policy.
- Support and test password manager autofill: Check forms with common managers and set correct HTML attributes.
Lower priority (ecosystem):
- Implement the change-password URL: The W3C proposal spares users the navigation hurdle of two to six steps.
- Evolve standards toward a guarded API: Any future interface must preserve two-factor authentication, RBA, and anti-abuse controls.
Conclusion
So what makes changing a password hard? The analysis of 111 websites shows that the difficulty lies not in the password itself but in the fragmented processes around it. Precisely in security-critical moments, such as after a suspected compromise, users run into hidden entry points, inconsistent labels, unclear policies, and ambiguous outcomes. When in doubt, they skip the change altogether.
The password will remain the backbone of signing in on the web for years to come, as the primary method and as the fallback at once. That makes a reliable update process part of every account's baseline security, deserving the same standing as other security-critical workflows. Websites should provide direct paths to the form, communicate requirements before failure, confirm success clearly, notify out of band, and end old sessions. But it only becomes reliable and usable once developers, web frameworks, and standards bodies pull in the same direction.
This article is an AI-generated summary of the scientific publication "An Analysis of the Security, Usability, and Automation Capabilities of Password Update Processes on Top-Ranked Websites" (SOUPS, 2026). The content has been editorially reviewed.
Want to make your application's login and password processes both secure and usable? Contact me for consulting on authentication, account security, and password manager support.