Why one phone call beat Twitter’s login controls

The week

In July 2020, some of the most-followed accounts on Twitter began posting the same kind of message: send cryptocurrency, and you will get double back. It was a scam, and it ran on accounts that millions of people trusted. Three months later, the public got a clear explanation of how it happened.

The scam ran for a few hours on July 15. Twitter later said the attackers had targeted 130 accounts, posted from 45 of them, reached the direct messages of 36 and downloaded account data from 7. To stop the posts, the company temporarily blocked many verified accounts from tweeting that evening. Several cryptocurrency companies regulated in New York, including Coinbase, Gemini, Square and Bitstamp, blocked attempted transfers to the scammers’ bitcoin addresses. Even so, the department found that consumers sent more than $118,000 in bitcoin.

On October 14, 2020, the New York State Department of Financial Services published its report on the compromise. The department, which supervises banks, insurers and cryptocurrency businesses in New York, investigated because the scam touched cryptocurrency activity it oversees. Readers expecting a tale of elite hacking found something more ordinary, and more unsettling.

The department licenses virtual currency businesses, and several of the hijacked accounts belonged to companies it supervises. That gave it standing to examine a platform it did not otherwise regulate. The report’s full title also tied the incident to election security. It appeared less than three weeks before the November 2020 presidential election. At that moment a hijacked candidate or election-office account could have spread false information about voting to millions of people within minutes. The department had no direct authority over Twitter itself, which shaped what its report could recommend.

The attackers picked up the phone. They called Twitter employees while posing as the company’s own IT support staff. They steered those employees to a fake login page built to look like the company’s VPN portal. (A VPN, or virtual private network, is the secure tunnel staff use to reach company systems from home; its login page is the front door for remote workers.) As employees typed their usernames and passwords into the fake page, the attackers replayed them on the real site in real time.

That real login then triggered a multifactor prompt, the extra check that asks a person to confirm a sign-in on their phone. Some employees approved it. They believed they were the ones logging in, and in a sense they were, but the attackers were holding the other end of the session.

Once inside, the attackers reached Twitter’s internal account-management tools: the screens support staff use to help users who are locked out or need settings changed. Those tools were what turned a few stolen logins into control over famous accounts.

The department counted four employees who were tricked into giving up their credentials. Twitter, in its own account that summer, called the technique a phone spear-phishing attack: targeted calls rather than mass emails. The superintendent described the attack as unsophisticated, and the report’s emphasis on the ordinary nature of the method was deliberate. If it worked at a large technology company with a security team, it would work in many places with less.

The report also found that, at the time of the attack, Twitter lacked adequate access controls, identity management and security monitoring. Those three gaps line up with the three failures this article examines: who could reach the tools, how identity was confirmed, and whether anyone would notice misuse quickly.

The report added two details that matter for any leadership team. Twitter had been without a chief information security officer, the executive accountable for security, since December 2019. And the department recommended that the largest social media companies be designated systemically important, a label usually reserved for institutions whose failure could shake the wider system, and face dedicated oversight. Several young people had already been charged over the attack during the summer.

Three of them, the youngest 17 and the oldest 22, were charged at the end of July. Two faced federal charges in California, and the teenager, described by prosecutors as the leader, in state court in Florida. Twitter, for its part, had announced a new chief information security officer in September, weeks before the report appeared, ending a gap of about nine months in one of the company’s most important security roles.

The Twitter report is usually remembered as a story about a social network. Read from a bank, a health system or a government agency, it works better as a workforce design document. It describes no secret weapon and no flaw in Twitter’s code: only a friendly voice on the phone, a convincing web page and a handful of employees trying to do the right thing on an ordinary working day.

Once employees are dispersed, proving who someone is over the phone becomes a security boundary, as real as a firewall or a locked door. The report showed that boundary failing in three distinct places: the verification step itself, the internal tools that sat behind it, and the working pattern that made both fragile.

A phone call, a fake page and an approved prompt

Security people call this kind of attack social engineering: persuading a person to do something that helps the attacker, rather than breaking into a computer directly. The technique is old; only the setting changes.

Three pieces of technology sit at the center of the story, and each is simpler than it sounds.

The VPN. A virtual private network is a protected connection between an employee’s laptop and the company’s internal systems. To use it, an employee signs in on a login page. That page is therefore one of the most valuable screens in the company, and one of the easiest to imitate, because every employee sees it daily and stops looking at it closely.

Phishing. A phishing page is a fake copy of a real login screen. It looks right, but whatever is typed into it goes to the attacker. In this case the attackers did more than collect passwords to use later. They replayed them on the real VPN as they arrived, so the real system saw what looked like a normal employee login.

Multifactor authentication. Often shortened to MFA, this is the extra step after a password: a code sent to a phone, or a pop-up asking “Is this you?” It is meant to stop someone who has only stolen a password. Its weakness is that it asks a human to confirm a login, and the human cannot always tell whose login it is. An employee who had just typed a password into what looked like the VPN saw a prompt seconds later, which was exactly what should happen next. Some employees approved it, and the attackers were in.

Put together, the attack needed no software vulnerability at all. It needed an employee to believe that a caller from IT was genuine, and it relied on a help desk relationship that ran on things an outsider could learn or fake: names, titles, internal jargon and a plausible reason for urgency.

How a real-time relay defeats a code or a push

The relay is the technical heart of the attack, and it explains why common forms of multifactor authentication failed. The fake page is a front end. Behind it, the attacker, or a script, waits for the victim to type a username and password, then enters them on the real login page within seconds.

The real system responds by asking for the second factor. If that factor is a one-time code, the fake page asks the victim for it too, and the attacker types it into the real page before it expires. If the factor is a push notification, the real system sends it to the victim’s phone, and the victim, who has just tried to log in, approves it. Either way the real system issues a session to the attacker’s browser. From then on the attacker holds a valid, signed-in session, and the password and code are no longer needed.

Later refinements to push approval narrowed the gap without closing it. Number matching asks the user to type into the phone app a number shown on the login screen. It defeats careless approval of an unexpected prompt, and it helps against prompt bombing, the tactic of sending repeated prompts until a tired user accepts one. It does less against a relay, because the victim is looking at the attacker’s page, which can display the number the real system generated. Microsoft made number matching mandatory for push notifications in its Authenticator app in 2023.

Only an authenticator that checks the website’s identity itself breaks the relay. Security keys and passkeys built on the FIDO standards bind each credential to the genuine domain, so a fake page on a look-alike domain receives nothing it can replay. Smart cards used for certificate-based login, the model behind federal employees’ PIV cards, resist the same trick when properly configured.

Why the attackers wanted employees, not customers

Customers’ accounts were the prize, yet the attack went through staff. That choice reflects a simple economy. A customer’s login opens one account. An employee login with access to support tools opens thousands. Attackers who understand this will spend days researching a company’s internal structure for one well-placed login.

The same economy applies to banks, hospitals and agencies. A fraudster who phishes one online banking customer gets one balance. A fraudster who persuades one contact-center agent, or captures one agent’s login, can change the phone number on many accounts. Defenses aimed only at customers miss the higher-yield route.

The verification step: the help desk as a security control

Most regulated organizations had built strong controls at the front door: multifactor authentication, VPNs and conditional access, which means rules that check things like the device or location before letting someone in. Far fewer had treated the help desk script with the same rigor.

Two questions rarely had written, tested answers. How does an employee know a call from IT is real? How does IT know a caller is really an employee? In many places both still depended on goodwill and caller ID, and caller ID proves very little: the number shown on a phone can be set by the caller.

The report also showed the limits of push and code-based multifactor authentication. A second factor offered no protection once an employee entered credentials on a convincing fake page and then approved the prompt, because the attackers were relaying the login in real time. Authentication that can be phished is only as strong as an employee’s ability to recognize the page. On a home network, late in the day, with a corporate laptop and a helpful voice on the phone, that ability is weaker than security teams assume.

A better kind of login exists, usually called phishing-resistant authentication. Hardware security keys and passkeys work this way. Instead of asking a person to judge whether a page is real, the device itself checks the web address and refuses to complete a login on an impostor site, like a house key that will not turn in the wrong lock however convincing the door looks. That shifts the burden from human judgment to the machine, which is where it belongs at the end of a long day.

Technology, though, only moves the problem. Every login system needs a way to recover when someone loses a phone, forgets a password or gets a new laptop. That recovery path usually runs through the help desk. If a caller can talk an agent into registering a new device, the strongest login in the world can be walked around.

Ways to verify a caller, and what each costs

Organizations have a handful of options for proving who is on the other end of a reset request. Each has a cost, and each fails in a known way.

• Knowledge questions. Employee number, manager’s name, date of birth or the last digits of a Social Security number. Cheap and fast, and weak, because much of this can be found online or is already circulating from old breaches.
• Call-back to a number on record. Strong against a caller using a spoofed or new number. Weaker if the attacker has already hijacked the employee’s phone number through a SIM swap or call forwarding, so it works best when the number on record has not changed recently.
• Manager or peer confirmation. A known colleague vouches for the request through a separate channel. Slower, and dependent on the confirmer being reachable, but hard to fake at scale.
• Video call with an identity document. Useful for remote staff. Increasingly exposed to synthetic video and cloned voices, so it should be paired with another signal rather than relied on alone.
• In-person verification. The strongest and the slowest. Practical for high-privilege accounts and for staff on a campus, much harder for a dispersed workforce.
• A pre-registered backup factor. A second security key or a set of recovery codes issued at enrollment lets an employee recover without the help desk at all. It moves the problem to keeping that backup safe.

The sensible design is tiered. Routine resets for low-risk accounts can use a self-service path backed by a registered factor. Resets that change the second factor, or that touch privileged, finance or executive accounts, need two independent signals. The tiers should be written into the help desk procedure, with the reasons, so an agent can point to the rule rather than argue with a caller.

How a reset really runs, step by step

The weak points become visible from inside an ordinary password or device reset. In most organizations the journey looks something like this.

1. An employee, or someone claiming to be one, contacts the service desk by phone, chat or email and says they are locked out or have a new phone.
2. The agent checks identity, often by asking for details such as an employee number, a manager’s name or a date of birth. Many of these facts can be found on professional networking sites, in old data breaches or simply by asking another employee.
3. The agent opens an administrative screen and resets the password, or removes the old second factor so a new device can be registered.
4. The caller sets up the new password or device and is back in, now with full access to whatever the real employee could reach.

Every step is designed for speed and kindness, which is what employees want when they are locked out. Very few steps are designed for doubt. The second step decides the outcome, and in many organizations it amounts to a short quiz an outsider can pass with an hour of research. Strengthening it need not make life miserable for staff. One independent check, such as a call-back or a manager’s confirmation, is enough for the small number of actions that hand over control of an account.

The Twitter attack ran the same logic in reverse: instead of the caller pretending to be an employee, the caller pretended to be the help desk. Both directions need an answer, and both answers should be written down rather than left to instinct.

How the verification problem differs by sector

The pattern is common to every sector, but the details and the rules differ.

Banks and credit unions face the problem twice: at the internal IT desk and at the customer contact center. The FFIEC’s 2021 guidance on authentication and access, which replaced its 2005 and 2011 guidance, addressed employees and third parties as well as customers, and discussed social engineering as a way around authentication controls. For a bank, a contact-center agent who changes a customer’s phone number or email address is performing an identity action as consequential as releasing a wire.

Health systems have a particular exposure. In April 2024 the HHS Health Sector Cybersecurity Coordination Center described callers who used local area codes and posed as staff in finance roles, such as revenue cycle. They supplied details such as the last four digits of a Social Security number and a corporate ID. They said their phones were broken, persuaded help desks to enroll new devices, and then redirected payments from insurers to accounts they controlled. Clinicians add a twist: they work under real time pressure, and a desk that slows a doctor at the start of a shift will hear about it.

Federal agencies have an advantage in the PIV card, the government-issued smart card used for employee login. Replacing a lost card generally involves in-person identity proofing, which builds a slow, strong recovery path into the system. State and local governments rarely have that infrastructure. A county may run its own desk with a handful of staff, or share one with other local bodies, and its verification may still rest on recognizing a voice.

Broker-dealers and wealth managers face the customer-side version most acutely. A brokerage or advisory account can be drained by a caller who persuades a representative to change contact details and then requests a transfer. Many firms already apply call-backs or waiting periods when a change of address is followed by a request for funds. The same discipline belongs on changes of phone number and email, which are now the more valuable targets.

The tools behind the call

The stolen credentials mattered because of what they reached. The attackers did not need senior engineers. They needed staff with access to internal tools that could change account settings at scale. Those tools existed for legitimate support work, and too many people could use them.

Every regulated organization has an equivalent:

• In a bank it is the console that resets online banking credentials or changes the phone number on an account.
• In a health system it is the identity tool that re-enrolls a clinician’s second factor, or the portal function that links a patient to a record.
• In an agency it is the caseworker screen that can redirect a benefit payment.

These applications have high impact and low visibility. They often sit outside privileged access management, the set of controls organizations use to watch and restrict their most powerful accounts, because they are not administrative in the infrastructure sense. Nobody thinks of a customer service screen as a master key. In practice, a screen that can change where a customer’s password reset is sent is exactly that.

Suppose a regional bank has 40 contact-center agents who can change a customer’s registered mobile number in one step, to help people who have lost a phone. Twelve of them work for an outsourcing firm. A criminal who persuades one agent, or who obtains one agent’s login through a fake page, can redirect the security codes for any customer and then empty accounts. The bank’s online banking login may be excellent; the weak point is the back office that services it.

A practical test takes a week. List the internal tools that can change who controls an account, or where money or data goes. For each, count how many people can complete an action without a second approver, and how many of those people work for contractors. The counts usually surprise the executives who see them.

Locking down the consoles

Once the list exists, a few controls go a long way. Access to an account-control function should be granted to named roles, reviewed on a schedule and removed promptly when people change jobs. For the riskiest actions, just-in-time access, where an agent requests elevated rights for a specific ticket and they expire afterward, cuts the standing exposure. A second approver for changes of phone number, email or payment destination stops a single persuaded or compromised agent from acting alone.

Monitoring matters because prevention will sometimes fail. Useful signals include one agent touching an unusual number of high-profile accounts, and actions outside a shift. Others are changes made from an unfamiliar device or location, and a change of contact details followed quickly by a password reset or a payment. Rate limits on bulk changes buy time for a human to notice. Session recording on the most powerful consoles gives investigators a record of what happened.

These controls have costs. Second approvals add minutes to real customer problems. Just-in-time access needs a workflow, and someone to approve requests out of hours. Monitoring produces alerts that someone must triage. The trade-off is easier to judge with the inventory in hand: a few dozen people holding a master key justify more friction than a few thousand with read-only screens.

The working pattern that changed in 2020

The third failure was specific to 2020. In an office, an odd request from IT could be checked by walking over to IT. Remote work removed that informal cross-check at the same moment it multiplied legitimate help desk calls about VPN problems, new devices and lockouts. Attackers could hide in the noise of real support traffic.

Incentives made it worse. Help desk staff were often contractors or junior employees measured on speed of resolution. Their scorecards rewarded resetting a credential quickly, and gave no credit for slowing down a frustrated caller who claimed to be a senior executive. Employees, for their part, had been told for months to expect unusual contact from IT as systems changed. Both sides of the call had been trained, in effect, to be helpful and quick.

Senior leaders most often miss this part. The failure lay in a system that rewarded the very behavior the attackers needed, more than in any one careless person. A help desk agent who hangs up on a caller claiming to be the CFO, and insists on calling back, is doing the job well. In many organizations that agent would be the one who gets a complaint.

Outsourced desks and the contract behind them

Many organizations run some or all of their service desk through an outsourcing provider. The provider’s agents follow the provider’s scripts, take the provider’s training and are measured against the service levels in the contract. Those service levels are usually about speed: average time to answer, share of tickets resolved on first contact, time to resolve. Few contracts measure correct refusals.

The contract is therefore part of the control. It can require the client’s verification procedure, rather than the provider’s default, for identity actions. It can give the client the right to run test calls and see the results. It can require notice of agent turnover, and background checks for agents with access to account-control tools. And it can add a security measure to the service levels, so the provider is not penalized when an agent slows a suspicious call down.

Supervisors expect this. Banking regulators hold a bank responsible for functions it outsources, and the interagency third-party risk guidance of 2023 says so in general terms. In health care, a business associate agreement covers privacy and security obligations, but it rarely specifies how a contractor’s agent should verify a caller. That detail has to be written into the operating procedures and the statement of work.

Money, regulators and reputation

For a business or agency, the costs of a help desk compromise arrive in several currencies at once.

Money. When attackers control an account, they can redirect payments, approve transfers or change bank details for suppliers and staff. Recovering stolen funds is slow and often incomplete.

Payment diversion is the usual route from a compromised identity to lost money. An attacker inside an employee’s mailbox or a finance system changes a supplier’s bank details, or an employee’s direct deposit account, and the next scheduled payment goes to the attacker. The FBI’s annual internet crime reports have for years ranked business email compromise, the family of frauds this belongs to, among the costliest categories reported to it. By the time the victim notices and asks the receiving bank to recall the funds, much of the money has often moved on. A help desk reset is frequently the first step in that chain, which is why the finance team has a direct interest in how the desk verifies callers.

Customers and citizens. At Twitter, the harm landed on the public who trusted famous accounts. At a bank, a hospital or a benefits agency, it lands on people who may lose savings, have medical records exposed or miss a payment they depend on.

Regulators. The Twitter report came from a financial regulator, and it ended by recommending new oversight. A security failure often becomes a governance conversation. For regulated firms there is a direct supervisory angle too: examiners and auditors increasingly ask how factors are enrolled, reset and recovered, as well as whether multifactor authentication is deployed. Organizations should check with their regulators and counsel on how those expectations apply to them.

Leadership. The report noted that Twitter had been without a chief information security officer since December 2019. A board does not need to know how a VPN works to ask who owns security, whether the seat is filled, and who covers it when it is not.

Which rules reach the help desk

Few rules name the help desk, but several reach it through authentication requirements.

• New York financial firms. The Department of Financial Services’ cybersecurity regulation, 23 NYCRR Part 500, covers banks, insurers and other firms licensed by the department. Amendments adopted in November 2023 extended multifactor authentication to any individual accessing a covered firm’s information systems, phased in by November 2025.
• Nonbank financial firms. The FTC amended its Safeguards Rule under the Gramm-Leach-Bliley Act, with most changes effective in June 2023. It requires multifactor authentication for anyone accessing customer information systems at the nonbank financial institutions it covers, such as mortgage brokers and many lenders.
• Federal agencies. OMB’s January 2022 zero trust memorandum required phishing-resistant authentication for agency staff, contractors and partners.
• Health care. The HIPAA Security Rule requires covered entities and business associates to verify that a person seeking access to electronic protected health information is who they claim to be. In January 2025 HHS proposed updates that would make multifactor authentication an explicit requirement, with limited exceptions.
• Criminal justice information. The FBI’s CJIS Security Policy sets authentication requirements for anyone accessing criminal justice information, including police and court staff at state and local agencies, and recent versions tightened its multifactor requirements.

A strong login rule says little about recovery, and the gaps between the two are where attackers go. Organizations should ask counsel and their examiners how these requirements apply to their own recovery procedures.

Call-backs, second approvals and mystery shoppers

The fixes that worked were operational and cheap:

• Call back on record. Return calls go to a number in the directory or HR system, never the number that called in.
• Second confirmation for factor resets. A manager or peer confirms before a second factor is re-enrolled, especially for privileged or finance staff.
• A never-on-one-call list. A short set of actions that cannot be completed on a single inbound call, published so staff can cite it to an impatient caller.
• A clear statement to employees. IT will never ask for a code or a password, and staff should hang up and call back if it does.

The fixes require no new products. They require someone to own the help desk as a control and to measure it on correct refusals as well as tickets closed. Mystery-shopper calls, where a tester tries to talk an agent into a reset, give a direct measure, and running them quarterly costs little.

A first ninety days

Most organizations can make the main changes within a quarter, in a deliberate order. The first month goes to discovery. Security and service desk managers write down how identity actions are handled today, listen to a sample of recorded calls if recording exists, and list the consoles that can change who controls an account. They run a handful of test calls to set a baseline.

The second month goes to the rules. The never-on-one-call list is agreed with the business, with tiers for privileged, finance and executive accounts. The call-back procedure is written, and the directory or HR system is confirmed as the source of numbers on record. Employees receive a short, plain message about what IT will and will not ask for. Outsourcing contracts are reviewed for the clauses that would need to change.

The third month goes to measurement. Test calls resume against the new procedure, the help desk dashboard gains its security measures, and the results go to the risk committee for the first time. Phishing-resistant authentication for administrators and finance staff can start in parallel, since those are the accounts attackers prefer, and broader rollout can follow on its own timetable.

The plan costs mostly staff time. Its main risk is complaint fatigue in the first weeks, as executives and clinicians meet a desk that now says no. A visible statement of support from the chief executive or the hospital’s chief medical officer tends to settle that faster than any policy memo.

Take a county IT service desk after it adopts these rules. A caller says he is the county treasurer, locked out before a budget meeting, and needs his authenticator moved to a new phone right now. The agent replies that new-device enrollment is on the never-on-one-call list, ends the call politely, rings the treasurer’s number from the HR directory and asks his deputy to confirm. The real treasurer is at his desk and has no idea what she is talking about. Total cost: four minutes and one mildly awkward conversation.

The failures are just as recognizable. Many organizations turn on a second factor and assume the job is done, leaving the recovery process untouched. Some let executives skip verification because slowing them down is uncomfortable, though senior names are the ones attackers impersonate most. Outsourced service desks often run on their own scripts and scorecards, set by a contract nobody in security has read. And if the only number on the dashboard is time to resolve, staff will optimize for it, and attackers will exploit it.

Banks learned long ago to require call-backs and dual approval for wire transfers, because a convincing voice is no proof. The Twitter report showed that in many organizations the identity equivalent of a wire transfer could be approved on one phone call, by staff who had never been told it mattered as much.

The case for less friction

A serious argument runs the other way. Every added step at the help desk costs employees time. Lockouts often happen at the worst moment: a clinician starting a shift, a trader before the open, a caseworker in front of a resident. Strict verification can push people toward workarounds, such as shared accounts or passwords on paper. It can also fall hardest on staff with disabilities, those working unusual hours and those without a manager on call.

That argument is right about blanket friction and wrong about targeted friction. Most help desk calls do not hand over control of an account. A password reset through a self-service portal backed by a registered device need not involve a person at all. The friction belongs on the small set of actions that move a second factor, change contact details or grant privileged access. Moving routine requests to well-designed self-service frees agent time for the calls that deserve care.

A second objection holds that phishing-resistant authentication makes help desk rules less important. The opposite tends to be true. As logins get harder to phish, recovery becomes the easiest route around them, and attackers shift their effort there.

Measuring the desk

What gets measured is what changes. A help desk dashboard that includes security can track the share of identity actions that followed the full procedure and the results of test calls. It can also track the number of resets on privileged accounts and how each was verified, and the time from a reported suspicious call to an alert reaching security. These measures belong alongside the speed measures, not in place of them.

Test calls work best when they vary. A tester posing as an executive, a new hire, a contractor and a frustrated clinician will find different weaknesses. Results should go to the desk’s managers as coaching material, and to the risk committee as a trend. Agents who refuse correctly should hear about it, because the instinct to help is strong and needs reinforcement in the other direction.

A help desk audit any leader can run

A leader does not need technical depth to test this area. Each of these questions should have a short, specific answer.

• If someone calls our help desk claiming to be me, what exactly happens next, and when did we last test it?
• Which actions can never be completed on a single inbound call, and is that list written down where staff can see it?
• Which internal tools can change who controls an account, a phone number on file or where a payment goes, and how many people, including contractors, can use them without a second approver?
• Can our current login methods be phished, and what is our timeline for phishing-resistant options for the staff who matter most?
• How is the help desk measured: do we reward a correct refusal, or only a fast resolution?

If any answer starts with “it depends who picks up,” that is the finding. The most important security decisions are sometimes made by the most junior people in the organization, on the phone, under time pressure, and designing for that moment is a leadership job.

With hindsight

The pattern proved durable. In 2023 intrusions at large casino operators were widely reported to have begun with calls to IT help desks. In November 2023 CISA and the FBI described the group behind such attacks, which they call Scattered Spider, posing as IT staff and persuading help desks to reset passwords and transfer multifactor tokens. In April 2024 HHS’s health sector cybersecurity coordination center warned hospitals that callers posing as employees were persuading help desks to enroll new authentication devices, then diverting payments.

The individual cases ran their course. The Florida teenager at the center of the Twitter attack pleaded guilty in 2021 and received a three-year sentence. A British man involved in it was arrested in Spain in 2021, extradited to the United States and sentenced in 2023 to five years in prison.

Twitter’s own security record stayed in the news. In May 2022 the company agreed to pay $150 million to settle FTC and Justice Department charges. They alleged it had used phone numbers and email addresses, collected for account security such as two-factor authentication, to target advertising. The order required it to offer multifactor options that do not depend on a phone number. In August 2022 its former head of security filed a whistleblower complaint alleging serious security failings, which the company disputed. No federal regime designating social media companies as systemically important followed the department’s recommendation.

The techniques spread well beyond social media. In 2022 the group known as Lapsus$ combined SIM swaps, help desk manipulation and repeated push prompts against large technology firms. The federal Cyber Safety Review Board published a review of those attacks in August 2023. CISA updated its Scattered Spider advisory in July 2025 to add the tactic of posing as employees to persuade help desks to reset passwords and move multifactor enrollment to an attacker’s device. In 2025, attacks on British retailers that were widely attributed to the same loose community again began with impersonation; Marks & Spencer estimated the hit to its operating profit at about £300 million.

Basic controls still lagged in places. UnitedHealth’s chief executive told Congress in 2024 that the attack on its Change Healthcare unit began with stolen credentials used on a remote access portal that lacked multifactor authentication.

Those later warnings echo October 2020 closely. Different targets, different years, the same move: a confident caller, a helpful agent, a reset that should have required more than one conversation. The sectors changed from social media to entertainment to health care; the human mechanics did not.

Federal policy moved toward phishing-resistant authentication. OMB’s 2022 zero trust strategy required it for agency staff, and passkeys and hardware security keys became mainstream options. That was real progress. A login that refuses to work on a fake page removes the exact trick that worked at Twitter. New York’s amended cybersecurity regulation, for its part, brought multifactor authentication to every user of covered firms’ systems by November 2025.

The help desk process changed more slowly than the login technology. Strong authentication raised the value of the recovery path, because recovery became the easiest way around the login. With the front door well locked, attackers go to whoever can issue a new key, and in most organizations that is the help desk.

The practical lesson concerns where to look more than any one tool. Ask about recovery as often as you ask about login. Treat the people who verify callers as part of the security team, with the training, authority and scorecards to match. And make sure someone senior owns the question.

By 2026 the principle from October 2020 is widely accepted, if unevenly applied: the strongest login is only as strong as the weakest way to recover it.