Junify
Guides

What US incident records show about passwords and accounts that outlive the job

In nine of the ten US cases here, all from agency and court records, a person knew the password, or an account kept working after their job or contract ended.

Updated October 16, 2026

The US records linked here fall into four types. Former staff or former contractors get back in. A vendor’s staff misuse access or lose it to an attacker. Leaked or reused passwords open the way. And a brand’s social media account is taken over. The causes differ from case to case, but in nine of the ten cases linked below, one of two conditions held. A person knew the password, or an account kept working after the person’s job, or the vendor’s contract, had ended. The exception is the call-center case, where workers misused logins their own jobs gave them. Across the ten, the companies range from a small hospital and a monthly magazine to a national wireless carrier.

Three terms come up throughout. Under the federal Computer Fraud and Abuse Act, unauthorized access means entering a computer without permission or going past the access you were given (What is unauthorized access under the CFAA?). CISA defines an insider as anyone who “has or had” authorized access, so former staff count, and so do contractors and vendors (What is an insider threat?). A data breach has no single US definition. HIPAA, the FTC and each state define it for the data they cover (What is a data breach under US law?).

The four types in the records

Access by former staff and former contractors

In this type, someone whose job or contract has ended signs back in, with their own login or one they knew. An office manager who had access to coworkers’ logins resigned around January 2015. She kept signing in to her old company’s website until at least July 2016, at times with a coworker’s login. A school district IT worker downloaded over 300 district passwords before he was fired in April 2023. He used them against district systems from June 2023 into January 2025, and one series of attacks suspended classes for hours. Turning off his own login couldn’t stop a list like that, because a copied password works until someone changes it.

Accounts outside the main systems are easy to miss. A monthly business magazine cut off a departing editor’s access to the accounts it knew about, but missed the Google account behind its YouTube channel. The employee handling it didn’t know that account existed, and the channel was deleted a few weeks after the editor resigned. A small hospital never turned off a former employee’s login to its web-based scheduling calendar. The HHS Office for Civil Rights (OCR) said at least 557 patients’ information was disclosed.

Contractors’ logins outlive contracts the same way. According to an FTC complaint, an online education company let staff and contractors share one full-access cloud admin key. Around April 2018, a contractor whose work had ended used it to take data on about 40 million users. At a community health center, attackers reached the network in 2021 with the admin login of an IT vendor that had left in 2014. A state attorney general found the account had never been deleted or disabled, and its password hadn’t changed for at least 11 years.

For the steps, see the onboarding and offboarding checklist and taking back access when a vendor contract ends.

Leaks through contractors’ staff

Here a vendor’s staff work inside your systems. Either one of them misuses the access they were given, or an attacker takes that access on the vendor’s side.

At a national wireless carrier, three workers at a call-center vendor opened 68,701 customer accounts without authorization over 168 days. They used logins to the carrier’s own customer system, access their jobs gave them. The record shows the misuse in the volume: more than 11,000 customer accounts were opened each month from December 2013 until March 2014. The FCC said the carrier’s protections “failed to prevent or timely detect” the breach.

At a national retailer, a Senate committee staff report, citing outside reports, says attackers got in with a contractor’s login, stolen through malware-infected email, in 2013. The report says requiring two-factor authentication for vendors might have disrupted the attack at that step. Malware on the vendor’s computer could capture a password typed there.

What is vendor oversight? covers what US rules ask of the client.

Leaked and reused passwords

A password works for whoever has it. In 2024, attackers used stolen logins to sign in to the cloud data of at least 165 organizations, then downloaded terabytes of records and demanded ransoms. At least some of the logins belonged to real people.

Five FTC complaints filed from 2018 to 2024 keep naming the same login failures. They are one admin key shared by many people, reused or default passwords, no multi-factor authentication (a second check at sign-in), and access left on after the need ended.

Official social media account takeovers

According to a federal criminal complaint, attackers in 2013 phished the Twitter (now X) logins of two US media companies and posted from the accounts. The complaint describes the group’s method: an email that seemed to come from a trusted source, with a link to a fake sign-in page. In the attacks that worked, someone who knew a login typed it in there. These are charges, not findings of a court. Each person who knows a brand account’s password is one more person who can be phished for it.

What the national numbers show

Two federal sources count reports nationally, and neither sorts them into these four types.

The FBI’s Internet Crime Complaint Center (IC3) received 24,768 complaints of business email compromise in 2025, with $3,046,598,558 in reported losses. IC3 defines business email compromise as scams that compromise email accounts and other ways of communicating, through social engineering or computer intrusion, to make unauthorized transfers of funds. These are the complaints and losses people reported to IC3, not every loss in the US. Each complaint carries one crime type, and IC3 notes that its figures can change as analysis goes on. The crime-type tables don’t show how each email account was compromised.

Organizations covered by HIPAA report breaches to OCR, and breaches affecting 500 or more people are listed publicly on OCR’s website. In its report to Congress for calendar year 2024, OCR counted 663 breaches of that size. The reporting organization picks only one type per breach, using the definitions on the reporting form. Of the 663, 534 (81%) were hacking or IT incidents and 108 (16%) were unauthorized access or disclosure. OCR’s examples of hacking include ransomware, malware and phishing. Its examples of unauthorized access include employees opening records outside the scope of their jobs. A former employee signing in with a password that still works could fit either category, so these counts can’t tell you how many breaches were misuse of a login.

OCR’s own investigations point at logins anyway. The 2024 report says compromised credentials, meaning “a password or other login credentials known to an attacker,” remain one of the main ways attackers get in. The weak practices OCR found include weak passwords, even on admin accounts, default passwords on system accounts, and remote access protected by a password alone. It also found admin rights given to generic shared accounts that an attacker, once inside them, could use to get around access controls.

How to read a public record

The cases here come from agency and court records, not from the companies’ own notices. Each kind of record states something different. A complaint or an indictment states what the government alleges. A settlement, such as an HHS resolution agreement or a state attorney general’s agreement, may say it isn’t an admission. A plea agreement records what the defendant admitted. A congressional staff report may mark points as reported or unconfirmed.

Read for what the record states, and keep it apart from what you would be guessing. The school district releases don’t say how the passwords were downloaded, or whether any were changed after the firing. The cloud data case doesn’t say where the stolen passwords came from. If you fill those gaps yourself, you end up checking your company against an incident that didn’t happen. The case pages linked here report each incident only as far as its record states.

Four questions to check at your own company

  1. Can you list every login that someone who left last month, or a vendor whose contract just ended, could use? Is each one turned off or changed?
  2. Who knows the password to each shared account and each brand social media account today? Is anyone on that list gone, or moved off that work? Is any of those passwords used elsewhere, or enough on its own to sign in?
  3. If someone used a shared account yesterday, could you name the person by the end of today?
  4. Do you have a list of which vendor staff use which of your logins, and could you see how many records each one opened?

Articles in this guide

Frequently asked questions

Where can I read what caused a US incident?

In US agency and court records: FTC complaints, HHS resolution agreements, state attorney general settlements, FCC consent decrees, and federal charges and plea agreements. A complaint alleges, while a plea agreement records an admission.

Is a former employee who signs in with an old password an insider?

Yes, under CISA's definition. CISA defines an insider as anyone who "has or had" authorized access to an organization's resources, so leaving doesn't take a person out of it. Its examples include contractors and vendors.

Does the HHS breach portal show how many breaches came from stolen passwords?

No. Each breach is filed under one type, and one that began with a stolen or misused password could be filed as hacking or unauthorized access. OCR's 2024 report does say compromised credentials remain one of the main ways attackers get in.

Where should we start checking our own accounts?

List every login that someone who left last month, or a vendor whose contract ended, could use, and confirm each one is off or changed. A login you can't put on that list is the first one to look into.

How Junify handles this

Doing this by hand
To avoid the same kind of incident, you stop every login a person could use each time they leave or a contract ends. You change the shared passwords they knew and send the new ones to everyone who stays. And someone has to check the sign-in records on a regular schedule.
With Junify
Nine of the ten cases ran through a login that a person knew, typed or could still use. For web logins you add to Junify, your admin changes the password at setup so only Junify holds it. People verify on their own phone and Junify fills it in, so nobody has a password to enter on a fake page, reuse, keep or have captured as they type. Removing someone stops their next sign-in through Junify. Each use is recorded by person, vendor staff included.

Sources