How failed logins become a data security problem

In healthcare, users aren’t always required to log in, which is one of the first visible signs that identity controls are strained by either human friction or active abuse. An NCBI Bookshelf chapter Patient Confidentiality warns that “passwords alone are inadequate for security measures and offer a very weak protection method,” while the study How secure is your information system? describes passwords as the “first line of defense” and found that the vast majority of real healthcare-worker passwords it examined had serious security problems.

Once a login finally succeeds, the blast radius is rarely limited to one screen. A single identity can lead to email, EHR-connected workflows, billing platforms, cloud storage, and patient communications. A national study of U.S. healthcare breaches found 1,512 breaches from 2013 to 2017 affecting 154,415,257 patient records, although hacking incidents accounted for fewer than 25% of the breaches, they were responsible for nearly 85% of all affected records.

Where failed login risk appears first

Failed-login risk usually shows up first at the edges of the identity system: dormant accounts, shared credentials, temporary worker access, vendor accounts, legacy protocols, and staff workflows that are too rushed or awkward to follow cleanly. The Bookshelf volume Technical Approaches to Protecting Electronic Health Information says login credentials must stay tightly linked to employment status and notes that leaving former or no-longer-authorized accounts active is a “major source of security vulnerability.”

Another early risk zone is credential sharing. In the study Prevalence of Sharing Access Credentials in Electronic Medical Records, 220 of 299 participants, or 73.6%, said they had obtained another staff member’s password, and 57.2% were willing to estimate how often it had happened, with an average of 4.75 episodes. Failed logins can be symptoms of a system where people are already bypassing formal access rules to keep work moving.

Why logging alone is not enough

Logging itself is not a defense as a log file that goes unreviewed is simply an unused tool. The OWASP Authentication Cheat Sheet says organizations should enable logging and monitoring of authentication functions on a real-time basis and ensure that all failures, password failures, and account lockouts are logged and reviewed. The OWASP Logging Cheat Sheet goes a step further, stating that all successes and failures of authentication should be logged as multiple failures could indicate account take over attempts before they succeed.

The problem is that while many organizations are still collecting logs, they are not giving them enough context or operational follow-through. The NIST audit-trail guidance says an audit trail should identify successful and unsuccessful log-on attempts and, at minimum, record the log-on ID, date and time, log-off time, devices used, and functions attempted after logon. Patient Confidentiality states that in the HITECH-era tracking should show who signed on, when, what data they accessed, whether they downloaded anything, and risk analysis should be an ongoing exercise rather than a one-off project.

The attack path from failed login to data exposure

The journey from failed login to data exposure usually begins with low-cost, low-risk probing. Attackers could use credential stuffing, which OWASP defines as the automated use of stolen username-password pairs on login forms, or password spraying, where the same common password is tried across many accounts to circumvent lockouts. Both techniques start by generating failed logins, which makes those failures so valuable as early-warning signals. As such, the NIST Digital Identity Guidelines require verifiers to implement rate limiting for failed authentication attempts. The HHS HC3 paper Multi-Factor Authentication & Smishing explains that attackers also use MFA fatigue by bombarding users with prompts until one is approved.

Once the attacker achieves a valid foothold, the narrative shifts from “failed login” to “trusted session.” The result can be mailbox access, internal phishing, password reset abuse, forwarding rule creation, or movement to connected systems.” Microsoft’s guidance on token protection in Entra notes that organizations need to look out for successful or attempted token theft, as attackers are increasingly targeting valid credentials or session artifacts, not noisy malware.

In the news: EvilTokens shows how login abuse can bypass normal defenses

April 6, 2026, Microsoft Security observed a widespread device-code phishing campaign that was compromising organizational accounts at scale, with automation and dynamic code generation leading to a much higher rate of success than older, narrower campaigns. Separately, Barracuda said it detected more than 7 million device-code phishing attacks in a four-week period.

The exposure is targeted for health care. Paubox reports that around 79% of healthcare organizations use Microsoft 365 and in 2025, it was the software used by 53% of breached organizations. 31% of breached Microsoft 365 environments are considered high risk. Microsoft’s own Conditional Access guidance now labels the device code flow as a high-risk authentication method and advises blocking it wherever possible.

See also: EvilTokens phishing kit fuels spike in Microsoft 365 device code attacks

How to reduce failed-login risk without slowing care

The best controls are the ones that reduce both risk and friction. If security slows the provision of care too much, people invent workarounds. The case report Implementation of a Single Sign-on System Between Practice, Research and Learning Systems on implementing single sign-on in healthcare describes how multiple systems and passwords disrupt clinical workflow and reports that enterprise SSO reduced complexity like “password hell,” with users reporting ease of use and streamlined workflows.

At the same time, another study, Tensions of network security and collaborative work practice, on SSO in hospitals found that authentication technology can misfit collaborative clinical areas if it is imposed without understanding real work patterns. So the goal is not more friction; it is better-designed friction. Paubox applies the same idea to HIPAA compliant email by reducing the extra steps that often push staff and recipients toward less secure workarounds. The design starts with strong identity basics like unique accounts, fast deprovisioning when roles change, rate limiting, and meaningful review of failed and successful logins together.

FAQs

Are failed logins themselves a data breach?

Not by themselves. A failed login is evidence of an unsuccessful access attempt, not proof that PHI was disclosed.

Is account lockout enough?

No. An account lockout helps, but by itself it does not stop low and slow password spraying, and in clinical settings an aggressive lockout policy can disrupt legitimate care.

What is better-designed friction?

Better-designed friction protects data without making routine tasks harder than necessary. Examples include single sign-on, role-based access, automatic encryption, clear alerts, and fast authentication methods.