Robinhood’s phone-call breach argues for support access sized to one customer

The week

On the evening of November 3, 2021, someone picked up the phone and talked their way into a brokerage. No malware, no clever code-breaking. Just a conversation with a customer support employee who, like most support staff, had been hired and trained to help.

Five days later, on November 8, 2021, the retail brokerage Robinhood disclosed the data security incident. According to the company, an unauthorized party socially engineered a customer support employee by phone and obtained access to certain customer support systems.

Social engineering is the security world’s term for manipulating a person, rather than a computer, into opening the door. It is the con artist’s craft applied to organizations: sound confident, create urgency, borrow some authority, and ask for something that seems reasonable in the moment. When it happens over the phone it is sometimes called “vishing,” short for voice phishing. Phishing is the more familiar version, where a fake email tricks someone into clicking a link or handing over a password.

What the attacker reached shows why support systems matter. The attacker obtained email addresses for about five million people and full names for about two million others. According to the company, about 310 people had more personal details exposed, including name, date of birth and zip code, and about 10 of them had more extensive account details exposed.

The company also said what was not taken. No Social Security numbers, bank account numbers or debit card numbers were exposed, and it believed no customers suffered financial loss. It said the attacker demanded an extortion payment, a demand for money in exchange for not misusing or publishing the stolen data. It had notified law enforcement and engaged the security firm Mandiant.

The days that followed

The picture kept moving after the first notice. Press reports that week, citing screenshots the attacker had shared, described an internal support tool with account details and controls for customer security settings. Robinhood told reporters it did not appear that any customer accounts had been changed.

On November 16, the company updated its notice. It said several thousand entries in the stolen list contained phone numbers, and that other text entries were still being analyzed. Its view on Social Security, bank account and debit card numbers was unchanged. Reporting at the time also described the data being offered for sale on a criminal forum.

That sequence is typical of how incidents unfold in public. A first notice is issued within days, while investigators are still working out exactly what left the building. Updates follow as the stolen files are analyzed. Customers, journalists and regulators read each update for what changed, and every revision tests the credibility of the earlier statement. Firms that can query their own access logs quickly have a much easier time getting the first notice right.

The disclosure landed on a firm already under heavy scrutiny. Robinhood had listed its shares in July 2021, after a period in which millions of first-time investors opened accounts. Three weeks before that listing, on June 30, FINRA ordered it to pay about $70 million over customer harm tied to outages, misleading information and options approvals. FINRA, the Financial Industry Regulatory Authority, is the self-regulatory body that oversees broker-dealers, and the sanction was the largest it had ever ordered.

The same month, elsewhere

The week also showed how little a trusted sender address can prove. On November 12 and 13, a large volume of hoax emails went out from genuine FBI email infrastructure. The FBI attributed it to a software misconfiguration in its Law Enforcement Enterprise Portal, and said no data or classified systems were compromised. Recipients who checked the sender saw a real fbi.gov address.

Rule writers were busy with the same questions. On October 27, the Federal Trade Commission had finalized an updated Safeguards Rule for non-bank financial institutions under its jurisdiction, such as mortgage brokers and auto lenders. On November 18, the federal bank regulators finalized a rule requiring banks to notify their primary regulator within 36 hours of certain significant computer-security incidents. Neither rule covered Robinhood. Broker-dealers answer to the SEC’s Regulation S-P and to FINRA.

Read quickly, the Robinhood incident might sound modest: mostly names and email addresses, no money gone. Read more carefully, it is a sharper warning. A single support employee, persuaded by a single phone call, became the route to records about millions of people. Nothing about the firm’s core trading systems had to be broken. The weak point was the ordinary, well-meaning help desk that every bank, insurer, credit union and wealth manager also runs.

Some staff will always be fooled. The question the week raises is how much damage one fooled person should be able to do.

Customer support exists to remove friction. A customer who is locked out or worried should reach a helpful person quickly, and that person should have the tools to fix the problem. Those same qualities make support a target. Agents are trained to help, measured on speed, often early in their careers, and frequently equipped with search across the whole customer base.

The November 2021 incident showed how a single phone call could turn those features against a firm. Banks, credit unions, insurers and wealth managers run the same kind of operation, often partly outsourced, so the pattern travels. There are three places to intervene: the agent, the tools the agent holds, and the signals customers rely on afterward.

The analysis below starts with what lies behind a support screen and how a phone call turns into a logged-in session. It then takes the three intervention points in turn. A side-by-side scenario tests them against one call. The last sections cover what such a breach costs, how the better-run operations are organized, and the questions a leadership team can ask this quarter.

What sits behind the support screen

Behind every customer service conversation sits a set of software tools. When a customer calls, the agent typically works in a customer relationship management system, or CRM, which holds each customer’s profile, contact details, history of past calls and notes. Alongside it there may be a case or ticketing system that tracks open issues, and admin screens that let the agent reset a password, change an email address or unlock an account.

Each agent logs in with an account, and that account carries permissions: rules about what it can see and do. Permissions work like the keys on a building manager’s ring. A cleaner may have keys to the common areas; a facilities manager may have a master key. In many support operations, every agent has something close to a master key, because it is simpler to set up and faster on the phone.

Social engineering targets the person holding the keys. An attacker might call an agent pretending to be from the IT department and explain that there is an urgent problem with the agent’s tools. The aim is to talk them into installing a piece of software, sharing a login code or approving a remote connection. Once the attacker can act through the agent’s account, they inherit everything that account can reach.

How a phone call becomes a logged-in session

The mechanics are worth tracing, because each step is a place to break the chain. The attacker first collects enough internal detail to sound like an insider. Job postings, professional networking profiles and past breach data often reveal the names of support tools, team leads and IT vendors.

The call then aims at one of a few outcomes. The agent installs a remote-access tool and hands over the screen. The agent reads out a one-time login code, or approves a push prompt on a phone. Or the agent is persuaded to visit a look-alike login page that captures the password and code together.

Each route ends in the same place: a valid session in the attacker’s hands. Most firms now use single sign-on, where one login opens many applications. That is efficient for staff, and it means a single captured session can open the CRM, the ticketing system, the knowledge base and any admin console the agent is entitled to use.

Monitoring tools often see nothing wrong at this stage. The login came from a real account, passed multifactor checks and may even come from the agent’s own machine. Defenses that rely on spotting a stranger fail when the stranger is wearing an employee’s badge.

The features that turn one session into many records

Support platforms accumulate powerful features because they solve real problems. Common examples include free-text search across all customers, saved reports, bulk export to a spreadsheet, and the ability to reset a customer’s multifactor settings or trust a new device.

Some platforms also let an agent view the application exactly as the customer sees it, which helps with troubleshooting. Each of these features is reasonable for some role. Bundled into one front-line role, they turn a hijacked session into a data extraction tool and, at worst, an account takeover tool.

So “we trained our staff” is never the whole answer. Training reduces the odds that any one person is fooled. It does not change what happens when someone is.

Outsourced and offshore support

Outsourcing adds another layer. Many firms run part of their support through specialist vendors, sometimes in several countries. Those vendor agents log into the same CRM, often with the same broad permissions, but they are hired, trained, managed and monitored by a different company. The firm still owns the customer relationship and the data, yet it may have little day-to-day sight of who is using its tools and how. Every additional site and vendor is another set of people a caller can try to persuade.

Contracts can close much of that gap if they are specific. Vendor agents should sign in through the firm’s own identity system, so the firm can switch an account off in minutes. Leavers should lose access the same day. The firm should receive access logs directly, not a monthly summary written by the vendor.

Background checks, controlled workstations and a right to audit belong in the contract too. Many firms deliver the CRM to vendor sites through a virtual desktop, a remote session that keeps data off the vendor’s machines and blocks copying to local files. It costs more to run, and it narrows what a compromised vendor laptop can leak.

The design question is what the blast radius of a single compromised support account should be: one customer, a hundred, or everyone.

The agent

Support teams are large and often spread across sites and vendors. Their performance is measured on handle time (how long each call takes), first-contact resolution (whether the problem was solved on the first try) and satisfaction scores. Security training, where it exists, usually centers on email phishing.

Voice social engineering works differently. A caller who sounds like a colleague, an IT technician or a supervisor can create urgency and authority that a written message cannot, and the agent has seconds to decide. An email can be forwarded to the security team for a second opinion. A confident voice saying “I need this done before the system goes down in ten minutes” leaves little room for that.

Why phone pretexts beat email training

Email training teaches people to inspect artifacts: the sender, the link, the attachment. A phone call offers almost nothing to inspect. Caller ID can be spoofed cheaply, and a caller can display an internal extension or the name of a known vendor.

The caller also adapts in real time. If the agent hesitates, the caller escalates urgency, names a manager or offers to “stay on the line while you do it.” Written lures cannot respond to doubt. A live voice can, which is why the defense has to be a rule rather than a judgment call.

Firms can make this harder without making service worse. A short list of things agents will never do on an inbound call or chat gives them permission to refuse. It should include installing software, sharing credentials, approving remote access and resetting another employee’s login. When the rule is written down and backed by management, refusing becomes policy rather than rudeness.

A callback rule for any request that changes access, using a number from the directory rather than one the caller supplies, gives agents a safe default. If the “IT technician” is real, they will answer the callback. If not, the conversation simply ends. Training that uses recorded voice scenarios as well as email examples builds the reflex.

Removing the code that can be read aloud

The most effective control for the agent is to take away the thing the caller wants. Text-message codes, voice codes and simple push approvals can all be relayed or approved under pressure. Phishing-resistant authentication, such as hardware security keys or device-bound passkeys built on the FIDO2 standard, cannot be read out over the phone.

These methods also check the website’s real address, so a look-alike login page gets nothing usable. For a support workforce, that change removes whole categories of attack rather than lowering their odds.

The rollout has real costs. Keys must be issued, replaced and recovered when people leave. Shared workstations and hot-desking complicate device-bound credentials. Outsourced agents may need keys shipped to another country. Recovery is the weak point: if a lost key can be replaced by a phone call to the IT help desk, the attacker simply calls the IT help desk.

That second help desk deserves its own rules. Resetting an employee’s credentials should require a stronger check than a caller’s knowledge of their manager’s name. Options include a video call against the staff photo, approval from the person’s manager through a separate channel, or an in-person visit for privileged roles.

Scorecards and incentives

Scorecards matter too. If an agent who pauses a suspicious call loses points on handle time, the incentive points the wrong way. A “security stop” code that removes the call from timing metrics means refusal costs the agent nothing. Few changes available to an operations team are cheaper or more powerful: it aligns what the firm says about security with what it actually rewards.

Recognition helps as well. Agents who report a convincing pretext give the security team early warning that a script is in circulation. Publishing those reports internally, with the agent thanked by name, teaches the rest of the floor faster than any annual module.

How it differs by type of firm

The same principles land differently. A credit union with a small in-house call center has agents who know each other and the IT staff by voice, which helps. It also tends to have fewer specialized roles, so one agent may legitimately need broad access. Callback rules and phishing-resistant authentication matter more there than fine-grained role design.

A large broker-dealer or card issuer with several outsourced sites has the opposite profile. Agents rarely know the IT staff, turnover is higher, and scale makes broad access far more dangerous. Role design and monitoring carry more of the weight.

At a wealth manager, the “support agent” is often an advisor’s assistant with access to every client in the book. The pretext is more likely to target that assistant with a request that appears to come from a client or an advisor, such as an urgent wire. Verification rules for money movement matter as much as access design.

The tools the agent holds

In many firms, support tooling grew by accretion. Each new problem added a screen or a permission until one agent account could search a large share of the customer base, view full profiles and export lists. That is convenient for agents and exactly what an attacker wants. A compromised support session with broad search becomes a bulk extraction tool, and the breach is measured in millions of records rather than one.

The design principle is to size access to the customer in front of the agent. Security specialists call the broader idea least privilege: give each person only the access their current task requires. In a contact center, that translates into a handful of concrete rules.

• Open a record only from an active call, chat or case, so search requires a reason that the system logs.
• Mask sensitive fields by default, showing only part of a date of birth or address, and reveal them only for a specific task, with the reveal recorded.
• Remove bulk search and export from front-line roles entirely and place them with a small, separately authenticated team.
• Fire alerts when an account looks up far more customers than its peers in an hour.
• Put administrative functions, such as changing an agent’s own permissions, in a different system with different credentials.

How case-bound access works

The building blocks already exist in most contact center stacks. When a customer calls, the telephony platform identifies the caller and runs the firm’s verification steps. Computer telephony integration then opens that customer’s record on the agent’s screen, a feature often called a screen pop. Access can be tied to that event.

The CRM grants the agent a short-lived right to that one record, linked to the call or case number. When the call ends or the case closes, the right expires. Chat and email work the same way through the case number.

Follow-up work needs a path too. An agent returning a customer’s call tomorrow reopens the record through the existing case, not a fresh search. Rare tasks that need wider access go through a request that names the reason and expires after a set period. Security teams call this just-in-time access.

For emergencies, a “break-glass” role can open any record. It should alert a supervisor every time it is used and be reviewed afterward.

Admin functions with account takeover potential need extra care. Resetting a customer’s multifactor settings, trusting a new device or changing the contact email are exactly what an attacker wants. These actions can require a second agent’s approval, or a confirmation sent to the customer’s existing, verified channel before the change takes effect.

These controls carry costs. Agents handling complex cases, such as estate transfers or account consolidations, need to see linked accounts. Masked fields can slow verification. The answer is to build exceptions for named workflows rather than leaving broad access in place for everyone.

What to measure, and what an examiner would ask to see

The same controls also produce useful operating data. Lookup logs show what agents actually need, which is usually far less than what they hold, and they make it easier to set access for outsourced teams on evidence rather than habit.

A short set of metrics tells leaders whether the design is holding:

• Records opened per agent per hour, compared with that agent’s peers.
• The share of record views with no linked call, chat or case.
• Every unmasking event and every export, with the user and reason.
• Use of break-glass access and the outcome of each review.
• Time from a vendor agent’s departure to the removal of their access.

An examiner or auditor will usually ask for the evidence behind those numbers. That means current role definitions, periodic access reviews signed by a business owner, log retention, alert handling records and vendor oversight files. A firm that can produce them quickly is in a far stronger position after an incident than one reconstructing them under pressure.

The case against tight access, and why it still holds

The strongest objection comes from service leaders. Case-bound access lengthens some calls, frustrates experienced agents and adds engineering work to systems that already struggle. Households with several linked accounts, business clients with many authorized users and customers who call about someone else’s account all strain a one-record model.

Those objections are fair, and they argue for careful design rather than broad access. Most support interactions involve one customer. The complex minority can be served through named workflows with their own, wider rules. The added seconds on some calls buy a large reduction in what a single compromised account can reach.

Suppose a regional insurer has a contact center of a few hundred agents, a third of them at an outsourced partner. Under its old setup, any agent could search the full policyholder base by name. After redesign, an agent sees a customer’s record only once that customer’s call is connected, and the record closes when the call does. If an agent’s account is hijacked, the attacker sees one customer at a time, slowly, while an alert flags the unusual pattern. The same social engineering call now yields a fraction of the data.

The signals customers rely on

Exposed email addresses and names are less sensitive than account numbers, but they are fuel for follow-on phishing. A brokerage customer who receives a convincing message about “your account after the recent incident” is at real risk, and the firm’s own breach notice can become the template for the scam. Communication after an incident is part of the defense.

How a list of emails becomes fraud

A list of email addresses known to belong to customers of one brokerage is valuable to criminals. It tells them who holds investment accounts, and at which firm. A phishing message that names the right firm and refers to a real, publicly reported incident is far more convincing than a generic lure.

Phone numbers raise the stakes again. They allow text-message phishing and calls that impersonate the firm’s own fraud team. The caller who claims to be “calling about the breach” is a natural next step for the same criminals.

The goal of that follow-on fraud is usually account takeover. Once inside, a criminal may change the linked bank account, withdraw funds or move assets to another firm. Those are the moments where friction belongs.

Teaching customers what genuine contact looks like

That has consequences for experience design. Customers need a reliable way to tell genuine contact from fake. That means a small set of sender addresses and a stated rule that the firm will never ask for passwords or one-time codes by email, text or phone. (A one-time code is the short number texted or generated by an app when you log in, a second check on top of a password.) It also means an in-app message center, reached only after login, where every important notice also appears.

The FBI episode the same week showed why the sender address cannot carry the whole load. Hoax messages arrived from a real government address. Customers should be taught to check important messages in the app or on the website they already know, not to judge an email by its sender alone.

Firms that taught customers these patterns before an incident could point back to them afterward. Firms that communicated through a mix of channels, vendors and styles had little to point to. If a customer has received genuine messages from a dozen different addresses over the years, a thirteenth fake one does not look out of place.

Marketing and operations teams often own those channels separately, which is how the dozen addresses accumulate. A single register of approved sending domains, numbers and short codes, owned by one person, keeps the promise to customers true.

Verification on inbound calls

Verification on inbound calls needs similar care. Every step added to stop impersonation adds friction for genuine customers, many of whom call because something has already gone wrong. Stronger checks belong where the stakes are high: changes to email or phone number, password resets, new linked bank accounts and large withdrawals. Low-risk questions can stay fast.

Knowledge-based questions are weak after a breach, because the answers may be among the stolen data. Better options include a prompt sent to the customer’s app, which the caller must approve, or a one-time code sent to a channel already on file. Those codes should be read to the firm, never requested by it on an outbound call.

A short hold on high-risk changes, explained as protection, is widely accepted, and it gives the security team a window to catch account takeovers that start in the contact center. An account takeover is exactly what it sounds like: a criminal gains control of a real customer’s account and locks the real owner out. A common route is persuading support to change the email or phone number on file.

US rules already push in this direction. Identity theft “red flags” rules require many financial firms to run programs that detect warning signs such as a contact change followed quickly by a request to move money. The SEC’s Regulation S-ID covers broker-dealers and investment advisers. Banking regulators and the FTC have parallel rules for the firms they oversee. A contact center’s high-risk change process is often where those programs succeed or fail.

One call, two contact centers

Run the same attack against two hypothetical firms, each with a busy contact center and well-meaning staff.

At the first firm, call it Firm A, an agent near the end of a long shift takes a call from someone who says he is from the internal IT team. He is friendly, uses the right jargon, and says the agent’s screen-sharing tool needs an urgent fix before a system change at the top of the hour. He asks the agent to read out a code that has just appeared on her phone. She hesitates, glances at her handle-time counter, and reads it out. Within minutes the caller is logged in as her. Her account can search every customer by name and export results to a spreadsheet. By the time anyone notices, a large share of the customer list has left the building.

At the second firm, Firm B, the same call reaches a similar agent. This time a laminated card on her desk lists five things she never does on an inbound call, and reading out a login code is one of them. She presses the security stop code, which pauses her call timer, and tells the caller she will call back through the IT directory. The caller hangs up. She reports it, and the security team warns other agents that the same script is circulating.

Now suppose Firm B’s agent had been fooled anyway, as people sometimes are. The attacker, logged in as her, finds that the system will only open a customer record linked to a live call or case. Search across the customer base is not available to her role. Exports are not available at all. When the attacker tries to open record after record, an alert fires because no agent normally does that. The breach, if it happens at all, is measured in a handful of records, not millions.

Run it once more, with Firm B using security keys for its agents. The caller asks for a code, and there is no code to give. The attacker’s best remaining option is the IT help desk, where a recovery request now triggers a video check and a message to the agent’s manager. Each layer the attacker has to pass raises the cost and the chance of being noticed.

Both firms employed people who could be fooled. Only one had designed its systems on the assumption that someday, someone would be.

What a help desk breach costs the firm

For a board or executive team, the support channel is easy to think of as a cost center to be made efficient. The incident is a reminder that it is also a privileged path into customer data, and should be governed like one.

• Customers and reputation. Customers rarely distinguish between a breach through a trading platform and one through a help desk. Either way, their details were exposed by the firm they trusted.
• Regulators and disclosure. Financial firms hold customer data under privacy and security obligations. An incident that touches millions of records brings notification work, scrutiny and questions about controls that were in place beforehand.
• Extortion. As in this case, attackers who obtain data may demand payment. Having less data reachable from any single account reduces both the harm and the pressure an attacker can apply.
• Outsourcing. Many firms run support partly through vendors. The firm remains accountable for customer data even when the agent works for someone else.
• Staff. Front-line agents should not carry the whole burden of security. Clear rules, safe defaults and fair metrics protect them as well as customers.

Which rules apply to whom

The regulatory consequences depend on the type of firm, and leaders should confirm the details with counsel. Broker-dealers and registered investment advisers fall under the SEC’s Regulation S-P, which requires written policies to safeguard customer records, and under Regulation S-ID. Broker-dealers are also examined by FINRA.

Banks follow the interagency information security guidelines under the Gramm-Leach-Bliley Act. From 2022 they also had to tell their primary federal regulator within 36 hours about incidents that materially disrupt operations. A theft of contact data may or may not meet that threshold, which is a judgment to make with counsel in advance.

Federally insured credit unions answer to the NCUA, which adopted its own 72-hour cyber incident notification rule in 2023. Insurers answer to state regulators, many of which have adopted versions of the NAIC’s insurance data security model law. Firms licensed by New York’s Department of Financial Services must also meet its cybersecurity regulation, Part 500. Every state has a breach notification law that applies when residents’ personal information is exposed, with differing definitions and deadlines.

The less visible costs

Beyond fines and notices, there is the operating cost of a response. Forensic investigators, outside counsel, notification mailings, call center surge staffing and identity protection offers all add up. Each one scales with the number of people affected.

There is also a strategic cost. After a help desk breach, the obvious response is to slow down every call. Firms that respond that way shift the cost onto honest customers for months. Firms that had already designed access around the case can make targeted changes instead.

How the better-run operations are set up

A well-run support operation, viewed through this lens, has a few recognizable features. Access follows the customer in front of the agent. Bulk capabilities are held by a small, separately controlled team. Agents have a written list of things they never do and a callback rule they can fall back on. Metrics include a way to stop the clock for security. Customers know one simple rule about how the firm will and will not contact them. And outsourced teams operate under the same access and monitoring rules as employees, verified through their logs rather than taken on trust.

Who owns it

Ownership is often the missing piece. The head of customer service owns the agents and the metrics. The CISO owns authentication and monitoring. Procurement owns the vendor contracts. Product teams own the admin features. Each can reasonably assume another has the support channel covered.

Firms that handle this well name one accountable executive for support-channel access. That person approves role definitions, signs off on access reviews and owns the metrics above. The CISO advises and monitors, and service leadership is measured on security outcomes as well as speed.

Testing it

Controls on a phone channel should be tested on the phone. Some firms commission authorized voice social engineering tests against their own agents and IT help desk, with the scope agreed in advance with service leaders and, where relevant, vendors. The goal is to find weak processes, not to catch out individuals, and results should feed into rules and tooling rather than discipline.

Tabletop exercises help too. A two-hour walk-through of “a support account has been hijacked and the attacker is demanding payment” exposes gaps in log access, vendor contacts, customer communication and the decision on extortion. It is far better to find those gaps in a conference room.

The failures tend to come from defaults:

• Treating training as the control. Training matters, but a design that assumes no one will ever be fooled is a design that fails at scale.
• Giving everyone the master key because tailoring access seemed slow or complicated.
• Rewarding speed above all, so that pausing a suspicious call looks like poor performance.
• Exempting vendors from the access reviews applied to internal staff.
• Communicating inconsistently, so customers cannot tell a real message from a fake one.
• Adding friction everywhere instead of concentrating it on the handful of high-risk changes.
• Leaving recovery weak, so strong authentication can be undone by a phone call to the IT help desk.

How far one hijacked agent account could reach

• If one support agent’s account were taken over tonight, how many customer records could the attacker see by morning?
• Can our agents search the whole customer base, or only open the record of the customer they are helping?
• Would we notice if an agent account looked up hundreds of customers in an hour?
• Does an agent who stops a suspicious call lose points on their scorecard?
• Do our outsourced support partners operate under the same access and monitoring rules, and how do we check?

Answering those questions honestly usually takes a few days of work with logs and role tables, not a new platform. The answers tell a leadership team where its exposure is concentrated and which fixes buy the most protection first.

The help desk will always be staffed by people trying to help, and some callers will always be lying. The goal is to make sure that when one of them is fooled, the damage stops at one customer, without making agents suspicious of everyone.

With hindsight

Social engineering of help desks and support staff became one of the defining attack patterns of the following years. What looked in 2021 like a single brokerage’s bad evening turned out to be an early example of a method that would be used against much larger organizations.

The pattern spread

In 2022, the group known as Lapsus$ breached a series of large technology companies using unsophisticated methods: buying or phishing employee credentials, swapping SIM cards, and calling help desks. The federal Cyber Safety Review Board examined those attacks in a report published in August 2023. It found a collective failure to account for the risk of text-message and voice codes, and recommended a move to phishing-resistant authentication. It also urged the FCC and FTC to act on SIM swapping.

The FCC did so in November 2023, adopting rules that require wireless carriers to use secure methods to authenticate customers before a SIM change or number transfer. The phone company’s own support desk, a telecom version of the same weak point, became a regulated control.

In September 2023, Caesars Entertainment disclosed an intrusion that began with a social engineering attack on an outsourced IT support vendor. MGM Resorts reported disruption at some of its properties from a cyberattack the same month. That November, CISA and the FBI described Scattered Spider as a group that targets companies and their contracted IT help desks. In May 2025, Coinbase disclosed that a threat actor had paid contractors or employees in support roles outside the United States to collect customer data, then demanded money. That last case added a twist: the insider did not need to be tricked at all, only paid.

The Coinbase filing also put a price on the pattern. The company preliminarily estimated remediation and voluntary customer reimbursement costs at $180 million to $400 million. It said it had not paid the demand and would open a new support hub in the United States.

The rules caught up

Regulators moved too, along the lines that the 2021 incident had exposed. In May 2024, the SEC amended Regulation S-P. Broker-dealers, investment advisers and other covered firms must now run an incident response program and notify affected customers within 30 days of learning of unauthorized access to sensitive customer information. They must also oversee service providers, who must report breaches to the firm within 72 hours. Larger firms had to comply by December 3, 2025, and smaller firms by June 3, 2026.

Robinhood itself faced later enforcement. In August 2022, New York’s Department of Financial Services fined its crypto unit $30 million over anti-money laundering and cybersecurity regulation failures. In January 2025, two Robinhood broker-dealers agreed to pay $45 million in combined SEC penalties. The findings included failing to maintain adequate identity theft policies under Regulation S-ID between 2019 and 2022.

What held up

The common thread was visible in 2021: support functions combine broad access, pressure to help and exposure to outsiders. Whether the person on the inside is fooled, pressured or bribed, the damage depends on what their account can reach.

The defenses that worked were also available then: narrower agent access, callback verification, phishing-resistant authentication for staff, monitoring of bulk lookups and consistent customer communication rules. Phishing-resistant authentication means login methods, such as physical security keys, that cannot simply be read out over the phone or typed into a fake website.

Less durable was the hope that stronger authentication alone would end the problem. Attackers shifted to account recovery, to outsourced help desks and, as the Coinbase case showed, to paying insiders. Each shift pointed back to the same control: limiting what any one support account can see.

By this point in 2026, contact centers and outsourced service channels belong in the same access reviews as any other privileged path into customer data. The practical shift is one of category. The help desk is a service cost, but it is also one of the most powerful sets of keys the organization hands out. It deserves the same scrutiny as the keys to the vault.