Two-factor authentication is not a checkbox for an auditor and not an extra button on a phone. It is the control that still works after the password has already reached an attacker. Passwords leak in bulk, sit in old databases, get reused at work and at home, and leave with a cookie file. As long as email, a VPN, a virtualization console, or an internal portal depends on a single secret string, that stolen string is a login.
Below is how a second factor actually works, what Google and Microsoft have measured about it, and how the absence or weak setup of this control showed up in incidents at large companies. The cases come from public sources: executive testimony, security-team blogs, and filings to regulators.
What breaks when there is only one factor
A password is a knowledge factor. A person remembers it. An attacker learns it. After that, both sides have the same knowledge.
The usual paths have been running as a business for years.
Dictionary guessing and password spraying. The attacker takes a short list of common passwords and tries them across thousands of accounts, one or two attempts each, so the lockout never fires. That is how Microsoft described the entry into its own test environment in January 2024.
Reuse. A person used one password for a forum, a shop, and work email. The shop was breached five years ago. The password still opens the corporate VPN.
Malware on a home computer. The browser stores passwords and syncs them to a personal account. That account is then bought or taken over outside the office network.
Phishing. An employee receives a page that looks like the corporate sign-in. They type the password themselves.
A shared password for remote access. The shift, the contractor, and whoever once set the system up all know it. Nobody changes it, because that would mean calling everyone.
In all of these, the attacker does not need malware inside the company. They need a working login. A second factor adds possession to knowledge: a phone with an authenticator app, a hardware key, a one-time code that lives for about thirty seconds and does not sit in the same database the password was stolen from.
What Google and Microsoft measured
In 2019, Google, with researchers from New York University and the University of California, San Diego, published results from real account-takeover attempts.
An SMS code stopped 100% of automated bot attacks, 96% of bulk phishing, and 76% of targeted attacks. An on-device prompt raised those shares to 100%, 99%, and 90%. A hardware key in that study stopped all three classes completely. A separate Google observation on corporate accounts: after employees moved to FIDO security keys, takeovers of those accounts were not observed.
The same year, Alex Weinert at Microsoft stated a practical conclusion from the company’s telemetry: an account with multifactor authentication is more than 99.9% less likely to be compromised. That figure is about mass password attacks, not a targeted operation against one specific person. For an ordinary company, mass attacks are the main flow: not “a hacker spends years studying your office,” but a script trying passwords from yesterday’s leak.
The numbers do not promise immunity. They show something narrower: between “the password is already stolen” and “the attacker is inside,” a second factor places a barrier that an automated attack almost never crosses.
Colonial Pipeline: a complex password with no second step
On 7 May 2021, the operator of the largest refined-products pipeline in the eastern United States stopped the flow. The DarkSide group encrypted its information systems. Fuel shortages appeared at stations along the East Coast. The company paid a ransom of about 4.4 million dollars in bitcoin. The FBI later seized part of the funds.
At a Senate hearing, Colonial Pipeline CEO Joseph Blount described the entry. It was an old VPN profile the company barely used anymore. The password was complex: Blount separately stressed that it was not a password like “Colonial123.” On normal remote access, the company used RSA tokens. This leftover profile had no second factor.
The incident-response firm Mandiant sharpened the picture in testimony to the House of Representatives. The earliest trace was 29 April 2021: a login to the VPN appliance with an employee’s username and password, and no one-time code. The profile was disabled after the incident.
The lesson is organizational. The second factor was turned on for “the main entrance” and left off on the leftover. For an attacker, the weakest path is the one that works, not the newest one. A decommissioned service, a test tenant, a contractor account, a forgotten Citrix portal: all of these are doors if the password is still accepted.
Change Healthcare: one portal without MFA, and medical payments stop
In February 2024, the AlphV group hit Change Healthcare, a payments operator inside UnitedHealth Group. A huge share of medical claims in the United States runs through the company. Pharmacies could not confirm insurance, clinics were not getting paid, and some organizations worked on paper for weeks.
On 30 April 2024, UnitedHealth Group CEO Andrew Witty set out the attack in prepared testimony to Congress. On 12 February, attackers who already held compromised credentials signed in to a Citrix portal used for remote desktop access. Multifactor authentication was not enabled on the portal. The group then moved inside the network and exfiltrated data. Ransomware was deployed nine days later.
The pattern matches Colonial. The consequences do not. A stolen password opened not “one program,” but a path that other hospitals and pharmacies depended on. A second factor on that portal would not have made the network invulnerable. It would have cut off the step which, in the company’s own account, is where the intrusion began.
Microsoft: a test account that started a state-linked attack
On 19–25 January 2024, Microsoft described an operation by the Midnight Blizzard group against its own corporate email. This was not a random ransomware crew. Microsoft links the group to the interests of a foreign state.
The beginning, in Microsoft’s description, looks ordinary. Password spraying against a limited number of accounts, few attempts on each, logins through a distributed residential proxy network, so that blocks based on geography and failure volume would not trigger. The entry that worked was an old test account in a non-production tenant. Multifactor authentication was not enabled on it.
The group then created OAuth applications, granted them rights, and reached mailboxes, including those of senior leadership. The share of affected mailboxes was small. The path matters: a state-linked operation started from a password on an account that was treated as unimportant.
A test bench, an integrator account, a mailbox “for checking SMTP” inherits rights more often than an administrator expects. If that account accepts a password with no second factor, it becomes a starting point, not a sandbox.
Uber: the second factor was there, and it was worn down
In September 2022, Uber confirmed an intrusion into internal systems through an external contractor’s account. According to the company’s security update, the contractor’s password had most likely been purchased after the contractor’s personal device was infected. The password alone did not grant entry: each attempt produced an approval request for the contractor. The requests kept coming. Eventually one of them was approved, and the attacker was inside.
From there the attacker reached internal tools and posted in corporate Slack. Production systems holding rider data and payment cards were, in Uber’s assessment, not affected. The company still took reputational and operational damage: the attacker moved through internal systems as a live account.
This is a different story. The second factor was in place, and at first it worked. It was bypassed by fatigue: a stream of “approve this sign-in” prompts until a person taps yes to make them stop. Sometimes a message arrives alongside them, pretending to be support: “this is a check, please approve.” The person is approving a nuisance, not an attack they recognize.
That leads to settings without which a push prompt is weaker than it looks. Cap the number of requests per minute. Show the place and the application in the prompt. Require the number on the screen to match, rather than a single tap. A suspicious series of prompts should lock the account and call an administrator. And employees need one rule: support never asks them to “just tap yes.”
Cisco and Cloudflare: one campaign, different second factors
In the summer of 2022, a similar scheme reached several technology companies at once. Cisco Talos published its own incident.
An employee’s corporate VPN password was sitting in his personal Google account: the browser had saved the credentials and synced them. The attacker took the personal account, read the password, and began a series of voice calls while posing as trusted organizations, pushing the employee to accept an MFA prompt. One prompt was accepted. The VPN opened. The attacker then registered new devices for the second factor and raised privileges. Cisco’s response team detected the attack and stopped it. The company said no customer action was required for Cisco products. For Cisco itself, this was still a full incident with a live attacker on the network.
In the same weeks, Cloudflare described a phishing campaign of the same class as the one that hit Twilio. More than a hundred SMS messages went to employees and their families. The links led to sites that looked like internal ones. Three employees entered their data. The attack stopped there: at Cloudflare the second factor was a FIDO hardware key. A phishing page can lure a password and even a one-time code. A key bound to the real site address cannot complete its cryptographic proof on a fake page. The sign-in did not happen.
Side-by-side cases are more useful than an abstract recommendation. The password was stolen in both. At Cisco, a push approval was talked out of a person. At Cloudflare, there was nothing to talk a key into doing.
Las Vegas casinos: the second factor was reset through support
In September 2023, MGM Resorts and Caesars Entertainment were hit almost at the same time. At MGM, electronic room keys, slot machines, and part of the internal systems were down for days. The company reported a social-engineering attack and said it did not pay a ransom. Caesars, in a filing to regulators, described a different ending of an attack of the same character: an attacker gained access through social engineering of an outsourced IT support vendor, after which the company paid about 15 million dollars.
Public analyses by Mandiant of the group UNC3944, also known as Scattered Spider, show a technique that makes even a carefully enabled MFA useless. A call to the help desk in an employee’s name. An employee number, a manager’s name, a piece of personal data. A request to reset the second factor or issue a temporary code. The operator wants to help, and the help takes five minutes. From then on, the attacker’s phone is “the” second factor.
The protection here is no longer the TOTP algorithm. It is the support procedure. Reset the second factor only through a second channel the attacker does not control. Refuse to change a factor on the strength of one phone call. Require a separate confirmation for privileged accounts. Keep a log of these resets that a person actually reviews. An outsourced support desk follows the same procedure as the in-house team: in the Caesars case, the weak link was the external operator.
Oldsmar: a shared account on a water-treatment plant
On 5 February 2021, an operator at the water-treatment plant in Oldsmar, Florida, watched the cursor on his screen move by itself. Someone had signed in through TeamViewer and raised the sodium hydroxide setpoint from 100 to 11,100 ppm. The operator restored the value within minutes. The county sheriff and the city reported it publicly. Plant operations later clarified that other process protections would also have fired, so poisoned water would not have reached the network unnoticed. That did not make the incident harmless: remote access to a process screen had been open to a stranger.
The entrance was a shared remote-administration account, reachable from the internet, with no separate second factor tied to a specific person. Setups like this live for years at small sites: “that’s how it was configured,” “the shift knows the password,” “otherwise we can’t get in at night.” For a plant, a boiler house, an electrical operation, or a dispatch room, that is a direct argument for named accounts and a second factor on remote access. A shared password cannot be revoked from one departing employee without taking access away from everyone.
When the second factor is stolen too
A second factor sharply cuts automated attacks. Targeted phishing can steal the factor as well, if the code is typed into someone else’s page.
On 15 July 2020, attackers reached an internal Twitter support tool and posted from dozens of well-known accounts, including those of Barack Obama, Joe Biden, Elon Musk, and Apple, asking people to send bitcoin. Twitter confirmed phone phishing of several employees who had access to those tools. The fraudsters collected a modest sum, on the order of one hundred thousand dollars. The damage was to trust in the platform: the message looked real because it came from the real account.
In February 2023, Reddit described a similar scheme aimed at the second factor itself. Employees were led to a page that copied the internal gateway. They entered both the password and the one-time code. The code was genuine at that moment, and the attacker used it immediately. In Reddit’s assessment, internal documents, fragments of source code, and contacts were affected, and user passwords of the platform were not.
That is an honest limit on expectations. An app code stops password leaks, reuse, and overnight guessing. A live phishing page that forwards the code to the real site at once can carry that code through. A hardware key bound to the site address breaks that forwarding. For leadership email, domain administrators, and remote access to critical systems, a key is justified. For everyone else, an app code already delivers the jump Google measured on mass attacks.
SMS is weaker than an app. The code arrives at a phone number, and a number can be reissued by the carrier on a forged authorization. In 2019, that is how the account of Twitter’s then CEO, Jack Dorsey, was briefly taken over: the attack was on control of the phone number, not on the Twitter password. SMS is better than nothing, and worse than a code generated by an app with no involvement from the carrier.
Which factor to deploy
The practical ladder looks like this.
SMS and voice calls. They stop bots and part of bulk phishing. They break when a number is reissued or intercepted at the carrier. For an administrator’s mailbox and a VPN, this is too little.
An app code, TOTP. The secret lives on the phone, and the code changes every thirty seconds. A stolen password database is useless without the phone. This is a working level for most employees and for systems that cannot do a second factor themselves.
A push approval. Convenient until there is no protection against fatigue. It needs a request limit, numbers on the screen, and a ban on “tap it to make it stop.”
A hardware key or a platform passkey, FIDO. The option most resistant to phishing. It belongs on administrators, finance, leadership, and the entrance to the environment from which everything else is reached.
A second factor on paper and a second factor in the configuration are different things. It has to be impossible to turn it off on a “temporary” portal. Support must not reset it because of a phone call. Old VPN profiles must be switched off, not forgotten. Failed attempts must end in a lockout, not in endless guessing.
When the application itself cannot do a second factor
Many systems in a company are closed to modification. A virtualization console, an old CRM, webmail, cameras, a contractor’s internal portal. Waiting for the vendor to add a one-time code can take years. For all of that time, publishing such a site on the network is equivalent to publishing its password.
The working approach is to put the check in front of the application. The employee opens the usual address, passes a one-time code at the gateway, and only then reaches the system. The application does not know about the second factor. The administrator sees who signed in, from which address, and can cut the session. Binding the session to the sign-in address keeps a stolen cookie from opening in another network. An address allow list further cuts sign-in from arbitrary points on the internet.
That is how MFA Proxy, which SoftTech places in front of web systems that are already running, is built: a separate verification layer, without rewriting the application. For domain administrators and leadership mail, the next step remains a hardware key. A gateway with an app code closes the layer where, today, there is most often nothing but a password.
The minimum worth starting from
The list is short, and each item maps directly onto the cases above.
- A second factor on all remote access: VPN, email, Citrix portals, and any sign-in from the internet. Turn old profiles off. Do not leave them “just in case.”
- Named accounts instead of shared passwords on TeamViewer, RDP, and equipment consoles.
- An authenticator app for employees. Leave SMS only where an app is not available yet, and remove it from administrators.
- A limit and a lockout after a series of failures. A push with no protection against repetition does not count as a sufficient control for privileged accounts.
- A support procedure: the second factor is not reset on the strength of one call. An outsourced support desk follows the same rule.
- FIDO keys for administrators and leadership.
- A sign-in journal that someone actually reads: an unfamiliar address, a session at night, a series of rejections.
The password stays. It stops being treated as a wall. The wall begins where a stolen password is not enough.