Why Scattered Spider’s turn to insurers should have set a deadline for the rest of finance

The week

On June 16, 2025, Google’s threat intelligence group said publicly that it was tracking multiple intrusions at U.S. insurance companies with the hallmarks of Scattered Spider. The loosely organized criminal group had been linked that spring to attacks on British retailers including Marks & Spencer and the Co-op.

The warning came from John Hultquist, chief analyst at Google’s threat intelligence group, in comments to reporters. He said the insurance industry should be on high alert, especially for social engineering aimed at help desks and call centers. He noted the group’s history of focusing on one sector at a time, and that it had recently been targeting retailers in the UK and the United States.

Mandiant, Google’s incident response arm, pointed to recommended defenses in the same reporting. They included stronger authentication, strict identity controls, limits on access to stop intruders moving sideways and escalating privileges, and training help-desk staff to positively verify a caller’s identity before resetting an account.

The retail attacks gave the warning weight. Marks & Spencer had suspended online orders for weeks after an April cyberattack, and in May it estimated the hit to its operating profit for the year at about £300 million. Some researchers linked the retail intrusions to the DragonForce ransomware operation. Google told reporters it had seen no evidence that Scattered Spider worked with DragonForce.

The group was not new to U.S. firms. It was widely blamed for the 2023 intrusions at MGM Resorts and Caesars Entertainment. In November 2023, the FBI and CISA had published a joint advisory describing its help-desk impersonation, SIM swapping and push-fatigue techniques.

Its method is often simple. The IT help desk at a large insurance company takes a call on an ordinary Monday morning. The caller sounds stressed, gives a name that matches an employee in the directory, knows the employee ID and the manager’s name, and says they have a new phone and are locked out. Could the help desk please reset the password and register the new device? Helping people is the help desk’s job. Within minutes, a stranger has the keys.

Several insurers disclosed incidents around the same time. Erie Insurance’s parent company disclosed in a securities filing on June 11 that it had identified unusual network activity on June 7, the result of an information security event. On June 20, Aflac disclosed that it had identified unauthorized access to its network on June 12 and believed it had contained the intrusion within hours.

The filings themselves were sparse, as early filings usually are. Erie said it had activated its incident response protocols, notified law enforcement and engaged outside experts for a forensic analysis, and that the full scope was not yet known. It did not describe what data, if any, had been taken.

Aflac said its systems had not been affected by ransomware and that it could still underwrite policies, review claims and serve customers. It also said the files involved might contain claims information, health information, Social Security numbers and other personal information about customers, beneficiaries, employees and agents. It filed the report as a voluntary disclosure, under the “other events” item of Form 8-K, rather than the item reserved for material cybersecurity incidents. It said the full scope and impact were not yet known. Neither company’s filing named an attacker.

Researchers noted the group’s habit of concentrating on one sector at a time, often by talking IT help desks into resetting passwords and multifactor authentication. Multifactor authentication, or MFA, is the second check after a password, such as a code sent to a phone or a tap on an app. It is one of the best defenses against stolen passwords, but only if nobody can simply ask the help desk to move it to a new phone.

This kind of attack is called social engineering: manipulating people rather than breaking software. It needs no sophisticated code, just research, confidence and a plausible story. It works because organizations rightly want their help desks to be helpful.

For anyone in financial services, the pattern mattered more than any single break-in. A group that moves industry by industry had arrived at insurers. Banks, broker-dealers and wealth managers could reasonably wonder whether they were next, and how much time they had.

Most threat intelligence arrives as a stream of indicators and advisories that security teams triage alongside everything else. Threat intelligence is information about who is attacking whom and how, gathered by security firms, government agencies and industry groups. Most of it is technical and incremental: a new piece of malicious software here, a suspicious internet address there.

The June 2025 warnings were different in kind. They described a capable group working through one industry at a time, using techniques it had refined on the last one. For an insurer that had not yet been hit, the warning carried an implicit date. For banks, broker-dealers and wealth managers, it was a rehearsal: the next rotation could be theirs.

Turning that kind of warning into action needs three things agreed in advance. They are a trigger that declares a surge, a set of identity controls tightened for the surge window, and a containment plan built around the attack that still gets through. Identity, rather than software flaws, sits at the heart of all three.

Why the attackers go after identity

In most large organizations, a single identity platform decides who you are and what you can open. When an employee logs in in the morning, that platform checks their password and second factor. It then hands them a kind of digital wristband that lets them into email, files, customer systems and dozens of other applications without logging in again. That convenience is called single sign-on.

It is a good design. Employees have one strong login instead of thirty weak ones, and security teams can switch off a departing employee’s access in one place. But it also means that whoever controls an employee’s identity controls everything that employee can reach. And whoever controls the identity platform itself controls everyone.

Attackers have adjusted accordingly. Rather than searching for a flaw in software, which takes skill and time, groups like Scattered Spider aim at the people and processes that manage identities. The help desk is the obvious target, because its job is to restore access to people who have lost it. A few weaker methods also help attackers:

• SIM swapping. Persuading a mobile phone company to move a victim’s phone number to a SIM card the attacker controls, so text-message codes go to the attacker.
• Push fatigue. Sending repeated “Is this you signing in?” prompts to a victim’s phone, often late at night, until they tap “approve” to make it stop.

Once inside, the most valuable targets are the identity platform and the virtualization consoles. Virtualization lets one physical server run many “virtual” computers, and the console that manages them, sometimes called the hypervisor console, can switch on, switch off or copy huge numbers of systems at once. An intruder with access to it can do enormous damage very quickly, including deploying ransomware, software that locks up systems until a ransom is paid.

How a help-desk takeover unfolds

Government advisories on the group describe a sequence that repeats with variations. Reading it as a sequence matters, because each step is a place to detect or stop the intrusion.

1. Research. The attacker builds a profile of a target employee from professional networking sites, past data leaks and the company’s own website. Accounts with broad access, such as IT administrators, are preferred.
2. The call. Posing as that employee, the attacker asks the help desk to reset a password and move multifactor authentication to a new device. The July 2025 update to the joint advisory described exactly this: pressuring help-desk staff to transfer MFA to a device the attacker controls.
3. The sign-in. With the new password and second factor, the attacker logs in through single sign-on and inherits every application the employee can reach.
4. Persistence. The advisories describe the group creating new identities, sometimes backed by fake social media profiles, and installing legitimate remote access tools so it can return even if the first account is reset.
5. Collection. The group looks for large data stores. The 2025 update described it searching for access to Snowflake, a cloud data platform, and running thousands of queries to pull data quickly, then moving it to cloud storage.
6. Extortion. In some cases it deploys ransomware, including against VMware ESXi servers, the hosts that run many virtual machines at once.

Two features of this sequence shape the defense. First, every early step uses legitimate access, so tools that look for malicious software see little. Second, the time from the call to the data store can be short. Detection has to focus on identity events: resets, device enrollments, new accounts, new remote access tools and unusual query volumes.

The original 2023 advisory added a detail that matters for containment. It said the actors had been known to monitor incident response discussions, including by joining remediation calls. A response team talking on corporate chat about an intruder with corporate credentials may be briefing the intruder.

So the fight is mostly about identity: who can reset it, how a reset is verified, and what happens if it is taken over anyway.

A trigger that declares a surge

The pattern was visible before June. Scattered Spider had disrupted UK retailers in April and May, and researchers had described its habit of staying in one sector for a period before moving on. Once Google’s warning was public and several insurers disclosed incidents within days of each other, any insurer not yet affected could infer it was in the same target pool.

Many security programs cannot act on that inference because it fits none of their processes. It is not a feed of malicious IP addresses (the numeric addresses of computers on the internet) or file hashes (digital fingerprints of known malicious files) that tooling can ingest automatically. It is a judgment about attacker intent.

Acting on it requires a named executive, usually the CISO, the chief information security officer, with authority to declare a surge period, and written criteria for doing so. Reasonable criteria include a credible public warning naming the institution’s sector, confirmed incidents at peers, or an alert through FS-ISAC, the financial sector’s information-sharing organization where member firms exchange warnings. The declaration should carry a start date, an end date and a list of pre-approved actions. Without those, the warning gets noted and filed, and the business pushes back on each control change one at a time.

Coastal towns treat hurricane warnings this way. They do not debate, storm by storm, whether to board up windows; they have pre-agreed thresholds, someone with authority to declare an emergency, and a checklist that follows. The declaration is what turns a forecast into action.

The trigger should also define the peer set. A regional bank may decide that a warning about insurers does not trip its surge, while a warning about credit unions or card issuers does. A wealth manager with a large call center may treat any finance-sector warning about help-desk fraud as relevant. Writing this down removes the debate from the moment of pressure. It also makes the decision auditable afterward: the board and examiners can see what criteria existed, whether they were met and what the institution did next.

Where the signal comes from

Public warnings are only one source. A firm’s own systems often see the early signs first, and the trigger criteria can include them:

• Help-desk patterns. A rise in calls asking for MFA resets or new device enrollment, especially for privileged accounts or outside normal hours.
• Lookalike domains. New registrations that imitate the firm’s name with words such as “helpdesk” or “SSO”. The joint advisory listed domain patterns of this kind, and domain monitoring services can flag them.
• Failed push approvals. Clusters of denied or ignored MFA prompts for the same user, which can signal a push-fatigue attempt.
• Peer reports. Direct contact from a peer firm’s security team, often through an information-sharing group, before anything is public.

Internal signals have one advantage over public ones: they are specific to the firm. A spike in reset requests for administrators is a reason to surge even if no public warning names the sector.

How the trigger differs by firm

The design depends on who runs the help desk. A large bank or insurer usually runs its own, and the CISO can change its procedures with the head of IT operations. Many credit unions, community banks, independent broker-dealers and wealth managers outsource IT support to a managed service provider.

For those firms, the surge has to bind the provider. The contract or a standing work order should say what changes when the client declares a surge, how fast the provider must apply it, and how the provider will verify callers. A surge declared by the client and unknown to the outsourced help desk protects nothing. Researchers had also reported that groups in this community were targeting managed service providers and IT contractors, where one compromise can reach many clients.

The peer set differs too. An insurer’s natural peers are other carriers. A bank holding company with an insurance agency subsidiary has two peer sets. A broker-dealer’s peer set may include the custodians and clearing firms its systems connect to, because an intrusion there could reach it.

Identity controls tightened for the surge window

The group’s methods were well documented by mid-2025. Callers posed as employees, using personal details found online, and persuaded help-desk staff to reset passwords or enroll new authentication devices. SIM swapping and repeated push prompts defeated weaker multifactor methods. Once inside, intruders moved quickly to identity platforms and virtualization consoles, and in some cases deployed ransomware.

That makes the surge list short and concrete.

• Stop trusting researchable facts. Help desks should stop resetting credentials on the strength of facts an attacker can research, such as an employee ID or a manager’s name. Those details are often on professional networking sites or in old data leaks.
• Verify through a separate channel. During the surge, resets can require a callback to the number already on file, a video check against a government ID, or manager approval for privileged accounts (accounts with administrator powers).
• Suspend self-service for administrators. Self-service password and device enrollment for administrators can be suspended for the surge window.
• Use phishing-resistant authentication. Phishing-resistant authentication, such as FIDO2 security keys or device-bound passkeys, should cover administrators and help-desk staff first. These methods tie the login to a physical device and to the real website, so they cannot be talked out of someone or captured by a fake login page.
• Watch for the telltale signs. Detection rules should alert on new device enrollment for privileged accounts, on password resets followed within minutes by sign-ins from new locations, and on unusual activity in identity and hypervisor consoles.

Verification methods compared

Each way of verifying a caller has a weakness, so the choice is about which weakness the firm can live with for a few weeks.

• Callback to the number on file. Simple and cheap. It fails if the attacker has already changed the number in the HR system or taken over the employee’s phone number through a SIM swap. The number must come from a record with its own change controls.
• Manager approval. Strong for privileged accounts, provided the help desk reaches the manager through a verified channel. A manager “confirming” over a chat message from a compromised account adds nothing.
• Video check against government ID. Raises the attacker’s effort considerably. Synthetic video is improving, so this works best combined with something the attacker cannot research, such as a callback.
• In-person verification. The strongest for administrators who work near an office. It is slow, and impractical for remote staff.
• Pre-registered recovery. A second security key or recovery code issued at enrollment lets employees recover without the help desk at all. This removes the attack surface rather than guarding it.

A related weakness is the HR record itself. If an attacker can change an employee’s phone number or email through a self-service HR portal, every later callback goes to the attacker. Surge rules should cover changes to contact details as well as password resets.

Ideally the phishing-resistant authentication is already in place before any surge, so the surge only tightens process rather than starting a technology project under pressure.

Each of these adds friction. Locked-out employees wait longer, and the help desk handles angrier calls. That friction is the reason to agree the list in advance and limit it in time. A surge measured in weeks is something business leaders will accept. An open-ended tightening invites exceptions, and one exception granted to a convincing caller on a busy morning undoes the rest.

Help-desk metrics also need adjusting for the period, so that staff are not judged on call-handling speed while being asked to slow down. If a help-desk agent is measured on how quickly calls are closed, the incentive works against every control on this list.

The case against a surge model

A fair objection is that controls worth applying during a surge are worth applying all the time. If callback-only resets stop attackers, allowing anything weaker on an ordinary Monday looks hard to defend. A surge model can look like an admission that the baseline is too weak.

Part of the objection is right. Phishing-resistant authentication for administrators, alerts on privileged device enrollment and strict verification for administrator resets belong in the permanent baseline. The surge should not be an excuse to defer them.

The remainder of the objection underestimates friction. Video verification or manager approval for every employee’s reset, applied indefinitely, generates exceptions, workarounds and pressure from the business. Controls that are unsustainable for everyone all year can be sustained for a defined period against a defined threat. The surge model is a way to spend tolerance for friction when it buys the most.

A second objection is that attackers could wait out a surge. That risk is real but limited. The firm need not announce its end date outside, detection rules can stay on after the surge, and the post-surge review can make the most effective controls permanent.

Help-desk measures for the surge window

The metrics that govern the help desk should change with the rules. Average handling time and first-call resolution can be suspended for privileged resets during the surge. In their place, managers can track the share of resets completed through the approved verification path, the number of requests refused or escalated, and the time taken to complete callbacks.

Refusals deserve recognition rather than suspicion. An agent who declines a convincing caller and is later proved right has done the job the surge exists for. Saying so publicly inside the team reinforces the rule more effectively than any training module.

A four-week surge at a wealth manager

Suppose a mid-sized wealth manager’s written criteria say a surge is declared when a credible public warning names financial services firms and describes help-desk impersonation. On the day such a warning appears, the CISO declares a four-week surge by email to the executive committee, attaching the pre-approved list. The help desk switches to callback-only resets for all staff and manager approval for administrators. Self-service device enrollment for administrators is paused. The security team switches on extra alerts. The head of operations tells help-desk staff that call times will be longer for a month and that their targets have been adjusted. Two weeks in, a caller claiming to be a senior portfolio manager demands an urgent reset. The agent politely says the firm will call back on the number on file. The caller hangs up. Nobody needed to make a judgment call under pressure, because the decision had already been made.

Containment built around the attack that gets through

Determined social engineering sometimes succeeds against good defenses. Aflac said it stopped its intrusion within hours, yet it still faced a review of what data had been taken. Speed of detection limits damage. It does not remove the need to plan for theft.

Containment plans should assume the identity platform itself is under attacker control. That changes a lot. If the attacker controls the system that decides who can log in, the response team cannot rely on that system for its own access or communication. Practically, it means:

• Break-glass administrator accounts held outside the main directory. “Break glass” refers to emergency accounts kept separate and used only when normal access is compromised.
• An out-of-band channel for the response team, meaning a way to communicate that does not run through corporate systems, in case corporate email and chat may be watched by the intruder.
• Isolated, tested backups of identity and virtualization infrastructure, stored where an intruder with administrator access cannot reach or delete them.

It also means deciding in advance who can authorize disabling single sign-on or cutting network connections, because those decisions stop business activity. Switching off single sign-on may lock every employee out of every system. That is sometimes the right call, but it is a business decision as much as a technical one, and nobody wants to be working out who has authority while an intruder is active.

These preparations need testing. Run a short exercise in which the response team pretends the identity platform has been taken over. The team tries to reach each other, log in to the break-glass accounts and restore a test system from the isolated backup. It will reveal problems that a document review never would. Passwords for emergency accounts turn out to be stored in the system that is supposedly unavailable. The out-of-band channel has not been set up on half the team’s phones. The backup restores, but takes three times longer than anyone assumed. Each of those discoveries is cheap in a rehearsal and expensive in a real incident.

The first hours

When a help-desk takeover is confirmed, the order of actions matters. A password reset alone may not evict the attacker. Existing sessions and tokens issued by the identity platform can stay valid until they are revoked, so revoking sessions for affected accounts is one of the first steps.

The team then needs to find everything the attacker created. That means reviewing recent MFA device enrollments, new user accounts and newly granted administrator rights across the identity platform. It means looking for remote access tools installed in the period, and for changes to how the identity platform trusts other systems. Credentials for service accounts and data platforms that the compromised account could reach should be rotated.

During an active incident, the help desk should pause resets for privileged accounts entirely and route any such request to the incident team. An attacker who loses access often tries to regain it the same way, and a second call is a chance to catch them. The agents who take those calls should know an incident is under way and whom to alert.

Each step can disrupt the business. Revoking sessions broadly logs out many people at once. Rotating the credentials of a data platform can break reports and integrations. The pre-agreed authority list should cover these decisions, as it covers disabling single sign-on.

Planning for theft as well as encryption

Many response plans were written around ransomware that locks systems. Their center of gravity is restoration: clean backups, rebuild order and recovery time. A help-desk intrusion that ends in data theft needs a different plan, because the systems may never stop working at all.

Theft brings its own workstreams. Legal counsel and forensic firms have to be engaged under the right terms. A notification vendor, a call center for worried customers and an identity protection offer may all be needed, and are faster to arrange if contracted in advance. An extortion demand may follow, and any decision about paying it raises sanctions questions. The Treasury Department’s Office of Foreign Assets Control has warned that facilitating ransom payments to sanctioned parties can violate U.S. sanctions.

The plan should therefore name an owner for each workstream and a budget authority who can approve spending in the first days. Insurance carriers that sell cyber coverage often require policyholders to use approved vendors, so a firm with a cyber policy should know which vendors its own policy allows before it needs them.

Logs decide how many people are notified

The most expensive part of a data-theft incident is often working out whose data was taken. That question is answered from logs: which files were opened, which queries were run, how much data left and where it went.

If those logs exist and were retained, the firm can scope the theft to the records actually touched. If they do not, it may have to assume that everything the attacker could reach was taken, and notify accordingly. The difference can be large. Retention for identity, file-access and data-platform query logs is therefore a containment decision made long before any incident.

Data platforms often keep query history for a limited period by default, and software-as-a-service applications vary in what they log at each license tier. Security teams should check, for each system holding customer data, what is logged, for how long and whether those logs leave the system to a place the attacker cannot alter.

Notification: the clocks that start running

Notification planning belongs in the same exercise, because the clocks differ by regulator. Financial firms often answer to several authorities at once, each with its own deadline and definition of what must be reported.

• Insurers and banks licensed in New York must notify the Department of Financial Services (NYDFS) within 72 hours of determining certain cybersecurity events under its Part 500 regulation.
• Many states have adopted insurance data security laws based on the NAIC model. The NAIC, the National Association of Insurance Commissioners, writes model laws that individual states can adopt.
• Public companies must assess materiality for Form 8-K disclosure, the filing companies use to tell investors about significant events. “Material” broadly means information a reasonable investor would consider important.
• Insurers that hold health information may also have HIPAA breach obligations under federal health privacy law.

More clocks by type of firm

Other financial firms face different clocks:

• Banks. Under the federal computer-security incident notification rule, a bank must notify its primary federal regulator within 36 hours of determining that a qualifying incident has occurred.
• Federally insured credit unions. NCUA’s rule, in force since September 2023, requires notice to NCUA within 72 hours of forming a reasonable belief that a reportable cyber incident has occurred.
• Broker-dealers and investment advisers. The SEC’s 2024 amendments to Regulation S-P require notice to affected individuals within 30 days when sensitive customer information was, or is reasonably likely to have been, accessed or used without authorization. Larger firms had to comply from December 2025 and smaller ones from June 2026.
• Nonbank financial institutions under the FTC’s Safeguards Rule. Since May 2024, these firms must notify the FTC within 30 days of discovering an incident involving the unencrypted information of at least 500 consumers.

The NYDFS regulation has more than one clock. Its 2023 amendments added a 24-hour notice requirement for extortion payments, followed by a written explanation within 30 days. State breach laws for notifying individuals add their own timelines and content rules, which vary by state.

For public companies, the SEC’s rule requires a Form 8-K under Item 1.05 within four business days of determining that a cybersecurity incident is material. In 2024, SEC staff said companies could disclose incidents not yet judged material under a different item. Aflac’s June filing took that route.

Counsel should confirm which apply. Drafting the decision tree before a surge saves hours when the clocks start. A decision tree here is simply a one-page chart: if this kind of data or system is involved, these regulators must hear within these deadlines, and this person decides.

The tree should also name who drafts the first notice to each regulator, who approves it and where the templates are kept. First notices are usually short and incomplete by design, because the clocks run before the facts are known. A firm that has agreed in advance what a first notice may say, and what it should not speculate about, files faster and corrects itself less often.

Where the cost of an intrusion lands

The cost is mostly downstream. Even a short intrusion can lead to a long, expensive review of what was taken, followed by notifications, regulatory inquiries and customer concern. The technical fix may be fast; the business consequences are not.

Customers judge the response. Clients of insurers, banks and wealth managers expect their personal and financial information to be protected. How quickly and clearly a firm acts shapes whether they stay.

Regulators and boards look for preparation. A written trigger, a pre-approved surge list and a notification decision tree are evidence that management anticipated the risk. Improvising under pressure is much harder to defend.

The threat is shared across the sector. Because groups like this move from one industry to the next, a firm’s peers are an early-warning system. Taking part in information sharing, and acting on what peers report, turns other firms’ bad weeks into useful preparation time.

Insurers know the bill from both sides. Many carriers underwrite cyber insurance and have for years asked policyholders about multifactor authentication and help-desk procedures. An insurer whose own help desk was talked into a reset faces awkward questions from its own underwriters, regulators and clients. The same holds for banks that advise business customers on fraud controls.

Customer service desks face the same playbook. Google’s warning named call centers as well as IT help desks. A bank or insurer’s customer service team resets online account access for customers every day. An attacker posing as a customer, armed with leaked personal details, uses the same script against that desk. Controls such as callbacks to numbers on file and holds on contact-detail changes apply there too, with the added complication that customers expect a fast answer.

Smaller firms carry proportionally more. A large carrier can absorb a forensic investigation, a notification program and a year of legal work. A small wealth manager or credit union may find the same exercise costs a meaningful share of its annual technology budget. Prevention measures that look expensive in isolation compare well against that.

Staff are the front line. Help-desk agents are not security experts, and they are trained to be helpful. Giving them clear rules, and backing them when they enforce those rules, protects both them and the firm.

A surge that starts in an hour and ends on a date

The aim is a firm that can declare a surge within an hour of a sector warning appearing. It switches on a known list of controls the same day and tells staff what is changing and why. It ends the surge on a set date with a short review of what happened.

Ending the surge well

The close of a surge is where much of its value is captured. A short review, held within a week of the end date, should record four things in writing:

• What triggered the surge, and whether the trigger was right.
• Which calls or events the tightened controls stopped or slowed.
• Which controls caused the most friction, and whether that friction was worth it.
• Which controls should become permanent.

The last answer is the ratchet. Each surge should leave the baseline a little stronger. A firm that runs two or three surges and makes one control permanent each time will, within a couple of years, have the help-desk posture it could not have imposed in one step.

The review also produces evidence. Examiners and auditors asking how the firm responds to sector threats can be shown a trigger, a declaration, a control list, metrics and a review, all dated. That record is far more persuasive than a policy that says the firm monitors threat intelligence.

The usual failures:

• No owner. Nobody has clear authority to act on a sector warning, so it is noted and filed.
• Negotiating each control separately. Without a pre-approved list, every change becomes its own debate with the business.
• Open-ended tightening. Controls with no end date breed exceptions, and exceptions are what attackers exploit.
• Conflicting incentives. Measuring help-desk staff on speed while asking them to slow down.
• Containment that assumes identity is safe. Response plans that rely on the very systems the attacker may control.
• Planning only for encryption. Preparing to restore locked systems but not to handle data theft and the notifications that follow.

Where a firm’s surge plan stands

• Who has authority to declare a security surge, what written criteria would trigger it, and which sectors count as our peer set?
• What exactly changes at the help desk during a surge, has the business pre-approved it, and could a caller today reset a password using only an employee ID and a manager’s name?
• Are our administrators and help-desk staff already on phishing-resistant authentication, and would we be alerted if a privileged account enrolled a new device or signed in from a new location minutes after a reset?
• If our identity platform were taken over, how would the response team log in and talk to each other, and who could authorize switching off single sign-on?
• Do we have a one-page notification decision tree covering NYDFS, state insurance laws, the SEC and HIPAA, reviewed with counsel?

With hindsight

Attention soon moved again, much as the sector-by-sector pattern suggested it would. In late June 2025, airlines began disclosing incidents, among them Hawaiian Airlines, whose parent reported a cybersecurity incident detected on June 23, though its filing named no attacker.

Law enforcement and government agencies responded too. On July 10, the UK’s National Crime Agency arrested four people, aged between 17 and 20, in connection with the April attacks on Marks & Spencer, the Co-op and Harrods. The suspected offenses included computer misuse, blackmail and money laundering.

On July 29, CISA, the federal Cybersecurity and Infrastructure Security Agency, updated its joint advisory on Scattered Spider with the FBI and agencies from Canada, Australia and the UK. The update described attackers posing as employees to get help desks to move MFA to attacker devices. It also covered bulk data theft from Snowflake, DragonForce ransomware and attacks on VMware ESXi servers.

Through 2025, Google also tracked voice-phishing crews from the same broad criminal community stealing data from cloud customer relationship platforms, the online systems companies use to manage customer contacts and sales.

The insurance intrusions proved costly even where they were contained quickly. In December 2025, Aflac completed its review, found that personal information of about 22.65 million individuals was involved and began notifying them, according to its 2025 annual report. Its securities filings did not name the attacker.

Pressure on the wider community continued into the autumn. In September 2025, a cyberattack halted production at Jaguar Land Rover for weeks, and the UK government backed a loan guarantee of £1.5 billion for the company. A group calling itself Scattered Lapsus$ Hunters claimed responsibility. The same month, the National Crime Agency charged two young men over a 2024 cyberattack on Transport for London, and U.S. prosecutors unsealed charges against one of them.

Regulation moved in the direction the surge model assumes. On November 1, 2025, the last phase of New York’s amended Part 500 took effect, requiring multifactor authentication for any individual accessing a covered entity’s information systems. For DFS-regulated insurers and banks, strong authentication stopped being a surge measure and became the baseline.

The timeline matters as much as the number. Aflac’s first disclosure came on June 20, and its review of the files was completed in December, roughly six months later. For half a year, the company could not say how many people were affected. That figure is the most instructive fact in the whole episode. Aflac said it detected and contained the intrusion within hours, which by most standards is a fast response. Yet detection within hours did not prevent a very large notification exercise. That supports planning containment and notification around theft as well as encryption. An attacker who gets in through the help desk may not need long to copy a great deal of data.

Not every part of the June argument can be checked. Firms rarely publish how they responded to a sector warning, so there is little public evidence on whether surge declarations worked better than ordinary vigilance. The insurers’ own filings did not attribute their incidents to any named group, so any link between a particular incident and Scattered Spider rests on outside reporting rather than on the companies’ own statements. What is visible is the attackers’ pattern, which continued to favor people and processes over software flaws, and the scale of the losses when they succeeded.

Two conclusions follow. First, sector warnings about groups that move industry by industry deserve a planned response with an owner and an end date, rather than a note in a security briefing. Second, the help desk is a frontline security function. Giving it clear rules, the right tools and incentives that reward care over speed is one of the most practical investments a financial institution can make.