For banks, the MGM and Caesars intrusions were about the few accounts that run the identity platform

The week

On September 11, 2023, MGM Resorts disclosed a cybersecurity issue that disrupted systems across its properties for days. Guests found reservations systems down, slot machines dark and digital room keys not working. For a company whose business runs on hospitality and gaming, it was a very public failure, played out in hotel lobbies and on social media.

MGM’s first statement came on social media that Monday. A press release followed on September 12, and the company furnished it to the Securities and Exchange Commission the next day. MGM later said it had shut down systems in response, which caused the disruption at some properties. Taking systems offline is a standard containment step. In a business that runs check-in, gaming floors and payments on shared infrastructure, though, containment and outage look the same to a guest.

Within the week, reporting attributed the intrusion to a group widely known as Scattered Spider, working with the ALPHV ransomware operation. Ransomware is malicious software that locks up an organization’s computer systems, and often steals data, so that criminals can demand payment to restore access or keep the data private. ALPHV ran that kind of operation.

The ransomware group did not stay silent. In a statement on its leak site, widely reported that week, ALPHV claimed it had held super administrator rights in MGM’s identity platform and administrative rights in its cloud environment. It also claimed it had encrypted servers after MGM began shutting systems down. These were a criminal group’s claims, made to pressure a victim, and MGM did not confirm them. They matched, however, the pattern the identity industry had just been warned about: the prize was the identity layer.

What caught attention was how the attackers reportedly got in. The reporting described initial access through a social engineering call to MGM’s IT help desk. Social engineering means manipulating people rather than breaking technology: in this case, a caller persuading a help desk agent to help them into an account. No clever code was needed for the first step, just a convincing voice.

MGM was not alone. On September 14, Caesars Entertainment disclosed in a filing with the Securities and Exchange Commission that attackers had taken data, including its loyalty program database. The intrusion followed a social engineering attack on an outsourced IT support vendor. The weak point was not even Caesars’ own staff but a company it had hired to answer IT support calls.

Caesars’ filing carried details a bank’s board would recognize. The company said it had determined on September 7 that the attackers had acquired a copy of its loyalty program database. That copy included driver’s license numbers or Social Security numbers for a significant number of members. Customer-facing operations, including its properties and online gaming apps, had not been disrupted. Caesars said it had taken steps to ensure the stolen data was deleted, while conceding that it could not guarantee it.

News reports at the time said Caesars had paid roughly half of a ransom demand put at about $30 million; the filing itself did not mention a payment. MGM, according to later reporting, did not pay and absorbed days of visible disruption instead. Neither path was free. Neither removed the underlying weakness, a recovery process that could be talked into helping the wrong person.

There had been a warning. Two weeks earlier, Okta had issued a warning. Okta is a major provider of identity software that many large organizations use to manage who can sign in to what. It had told customers that callers were persuading help desks to reset multi-factor authentication for highly privileged administrators. Multi-factor authentication is the second check beyond a password, such as a code from a phone app. Resetting it for an administrator can hand a stranger control over everyone else’s access.

Okta’s advisory, dated August 31, was specific. The callers targeted users with Super Administrator rights, and beforehand appeared to hold those users’ passwords or to be able to manipulate authentication delegated to Active Directory. After a reset, they signed in through anonymizing proxies and granted higher privileges to other accounts. They reset authenticators on other administrators and, in some cases, removed second-factor requirements from sign-in policies. Some configured a second identity provider they controlled, so they could sign in to applications as real users.

Okta listed defenses alongside the warning. They included phishing-resistant authenticators for administrators, re-authentication before sensitive administrative actions, and help desk roles that exclude privileged groups. Okta also recommended alerts on events such as a reset of all of a user’s factors or the creation of a new identity provider.

The warning also had a backdrop. In August 2023 the Department of Homeland Security’s Cyber Safety Review Board had published its review of attacks associated with the Lapsus$ group. That group had relied heavily on SIM swapping and on manipulating telecom and support staff. The board urged organizations to move away from text-message and voice-based authentication. The casino attacks put the same advice in front of a much larger audience a few weeks later.

The cost was concrete. In October, MGM estimated a negative effect of about $100 million on its third-quarter adjusted property EBITDAR, a measure of operating earnings. The story began with a phone call and ended in the earnings report. Banks watching from the sidelines had to assume their help desks could be fooled too, and ask what a fooled help desk could unlock.

Help desk social engineering was not new in 2023; the 2020 Twitter intrusion and a 2021 brokerage breach had both turned on how agents verify callers. The casino attacks added something more specific for banks, broker-dealers and credit unions.

According to Okta’s warning and the reporting that followed, the goal of the calls was administrative control of the identity platform itself: the accounts that decide who can sign in to everything else. Most institutions have tens of thousands of user accounts and only a few dozen of these, and the imbalance works in the defender’s favour. Protecting tens of thousands of accounts perfectly is impossible; protecting a few dozen very well is a realistic goal.

The problem has three parts, which together describe how a control-plane takeover succeeds: the accounts that run the identity platform, the people permitted to recover them, and the events that would reveal a takeover in progress. Some background on identity platforms comes first.

One sign-in, trusted by everything

Twenty years ago, each system in a bank had its own user list and passwords. Today most institutions use a single identity provider, a central service that confirms who someone is and then vouches for them to every other system. When an employee signs in in the morning, the identity provider checks their password and second factor, and then lets them into email, internal applications and much else without asking again. This is called single sign-on, and it is both convenient and safer than dozens of separate passwords.

But it concentrates power. A bank’s identity provider is trusted by its email, core banking front ends, wire systems, cloud consoles and remote access gateway. The core banking system is the central ledger that holds customer accounts and balances; the front ends are the screens staff use to work with it. Wire systems move money between banks. Cloud consoles control the bank’s rented computing infrastructure. The remote access gateway lets staff connect from outside the office.

Security people call the identity platform part of the “control plane.” The term comes from networking: there are the systems that do the work, and there are the systems that control the systems that do the work. A control-plane account does not move money itself. It decides who can.

The arrangement resembles badge access in a large office building. Most employees have a badge that opens certain doors, while a few facilities staff can issue new badges, change which doors any badge opens and switch off the alarms. A criminal who talks the front desk into handing over a facilities badge no longer needs to worry about any other lock.

How trust passes from one system to the next

The mechanics explain why the attackers aimed where they did. When an employee opens an application, the application does not check the password itself. It sends the employee to the identity provider, which checks their credentials and returns a signed statement, called a token, saying who the employee is and which groups they belong to. The application accepts the token because it trusts the identity provider’s signing key. Standards such as SAML and OpenID Connect define this exchange, and almost every enterprise application supports one of them.

Three consequences follow. Whoever controls the identity provider’s configuration controls what those tokens say, and every downstream application will believe them. The identity provider can also be told to trust another identity provider, which is how subsidiaries, partners and acquired firms are normally connected. Okta described attackers abusing exactly that feature to sign in as real users. Finally, tokens outlive the moment of sign-in. Resetting a password does not end sessions already issued, so containment has to revoke them explicitly.

Many banks also run a hybrid arrangement. User accounts still originate in an on-premises Active Directory and synchronize to the cloud identity provider through agents on local servers. Okta’s advisory noted that some attackers appeared able to manipulate authentication delegated to Active Directory. The control plane therefore extends to the domain controllers, the synchronization servers and the accounts that administer them. A bank that hardens its cloud identity console but leaves domain administrators with standing rights has locked one door of a building that has two.

Fifty administrators, or ten

Whoever administers the identity provider can add a sign-in method to any account, trust a new external identity provider, or change the policy that requires multi-factor authentication. Okta described attackers using exactly these powers after a successful reset. Adding a sign-in method means the attacker can register their own phone or device to someone else’s account. Trusting a new external identity provider means the bank’s systems will start accepting sign-ins vouched for by a service the attacker controls. Relaxing the multi-factor policy means the second check simply stops being asked.

The first task is to list these accounts precisely. The list includes super administrators of the identity platform, global administrators of the cloud productivity tenant, administrators of the privileged access vault, owners of cloud subscriptions, and service accounts with directory write rights. The cloud productivity tenant is the bank’s instance of a cloud email and documents suite. A privileged access vault is a secured system that stores and hands out the most powerful passwords. Service accounts are accounts used by software rather than people, and “directory write rights” means they can change who exists and what they may do.

Many institutions find the number is higher than expected, because vendors, consultants and former project teams were granted rights years earlier and never removed. Suppose a regional bank moved to a new identity platform four years ago. The implementation partner was given super administrator rights for the project. A consultant who helped with the cloud email migration kept global administrator rights, and two engineers who have since moved to other roles still hold access. None of them would misuse it, but each account is a target a caller could ask the help desk to reset.

Accounts that are easy to miss

Several other kinds of access carry the same power. Device management administrators can push software to every laptop and phone the bank manages, which makes them a distribution channel for anything an attacker wants installed. Administrators of the email security gateway can release quarantined messages and loosen filtering. Application registrations in the cloud tenant can hold directory-wide permissions granted years ago for an integration nobody now owns. Partners that manage a bank’s Microsoft environment may hold delegated administrative rights, and older, broad delegations were not always replaced when Microsoft introduced more granular ones.

The help desk’s own tooling belongs on the list too. The accounts that run the ticketing system, the password reset portal and the remote support software can all be turned against the bank. Okta’s advisory, and the CISA and FBI advisory on Scattered Spider that followed in November 2023, pointed at remote monitoring and management tools, the software help desks use to take control of a user’s screen. The joint advisory named several commercial products the group had abused and recommended allowing only approved tools and blocking the rest.

Once listed, these accounts can be treated differently from the rest. Each should be a separate account from the person’s daily identity, with no mailbox and no web browsing, because email and browsing are how most attacks arrive. Each should use phishing-resistant authenticators only, such as hardware security keys bound to that account, with a second registered key held in a safe. A hardware security key is a small physical device, often the size of a house key, that the user plugs in or taps; it cannot be talked out of its owner over the phone, and it will not respond to a fake website.

Standing access can be replaced with just-in-time elevation that expires within hours: instead of holding powerful rights permanently, an administrator requests them for a specific task and loses them automatically afterward. A bank that reduces this population from fifty to ten has cut the attacker’s target list by four-fifths without touching the help desk.

There is a cost. Administrators lose some convenience, and break-glass procedures must be tested so that the institution is not locked out of its own tenant during an outage. Break-glass refers to emergency credentials kept aside for when normal access fails, named after the fire alarm behind glass. Those procedures need a named custodian for the emergency credentials, a sealed record of each use, and a quarterly test. That is a modest price for removing most of the targets a caller would ask for.

The same list looks different at each kind of institution

At a large bank, the list is usually long but tended. There is a privileged access team, a vault and a regular certification cycle. The exposure comes from sprawl: many cloud tenants, subsidiaries and acquired platforms, each with administrators of its own.

At a community bank or credit union, the list is short but dominated by outsiders. A core processor runs the ledger, a managed service provider runs the network and the Microsoft tenant, and a managed security provider watches the logs. Several of these firms may hold global administrator rights, sometimes through shared or generic accounts. Cutting the list there means renegotiating vendor access rather than reassigning internal staff.

A broker-dealer adds another layer. Its order management and clearing connections depend on accounts at third parties. FINRA has reminded member firms that outsourcing an activity does not outsource the duty to supervise it. A wealth manager or fintech that runs entirely in the cloud may have no on-premises directory at all, which shortens the list. It often grants broad cloud console rights to a small engineering team for speed.

What an examiner or auditor would want to see

The inventory needs to exist as a record with an owner. Examiners and internal auditors tend to ask for the current list of privileged accounts, the date and outcome of the last access review, who signed it off, and how exceptions were handled. Useful measures include the total count and the share protected by phishing-resistant authenticators. Two more are the share holding standing rather than time-limited rights, and the number owned by vendors. A rising count should prompt a question from the risk committee.

The trade-offs are practical. Hardware keys must be bought, registered, replaced when lost and shipped to administrators in other countries. Dedicated administrative workstations add cost and friction. Just-in-time elevation needs an approver available at three in the morning during an incident, or it will slow the response it is meant to protect. These costs are real, but they fall on a few dozen people rather than on the whole workforce.

Taking the reset away from the help desk

Recovery is the weak point because it exists to bypass authentication. When someone loses their phone or forgets their password, the help desk’s job is to get them back in, which means, by design, letting someone in without the usual proof. Help desks are measured on speed and customer satisfaction, and a friendly, frustrated caller who seems to know the right names is hard to refuse.

Improving the help desk script is reasonable for ordinary staff. For control-plane accounts, the right number of help desk agents able to reset them is zero. Recovery should require two named people from the identity or security team. At least one should verify the requester in person, or on video against a photo already held by human resources, and the action should be logged and reported to the CISO the same day.

Every verification method fails somewhere

Help desks verify callers in a handful of ways, and each has a known weakness. Knowledge questions such as date of birth, employee number or manager’s name can be answered from professional networking profiles, earlier data breaches or a little research. A callback to the number on file fails when the attacker has already moved that number to a SIM card they control, a technique the joint advisory described. Manager approval fails when the manager is messaged from an account that is already compromised. A code sent to a personal email address fails if that inbox has been taken over.

Stronger methods raise the attacker’s cost without removing the risk. A live video call compared against a photo on file is harder to fake than a voice, though synthetic video is improving. In-person verification at an office or branch is strong but slow, and impractical for a remote engineer. Document-and-selfie checks from identity verification providers add assurance, at a cost per check and with privacy obligations for the images collected. Okta’s guidance suggested starting any self-service recovery with the strongest authenticator the user already holds, and limiting recovery to trusted networks.

A recovery matrix, by tier

The workable answer is to assign recovery methods by tier, so that the strength of the check matches the power of the account. A simple version has three tiers.

• Tier 0, the control plane. No help desk recovery path exists. Recovery requires two named members of the identity or security team, in-person or video verification against a photo on file, and same-day notice to the CISO.
• Tier 1, sensitive business access. This covers staff with access to payment systems, bulk customer data or production infrastructure. Help desk recovery is allowed only after a callback through a verified channel and manager confirmation by a separate route. The result is a short-lived temporary credential that forces fresh enrollment.
• Tier 2, everyone else. Self-service recovery starts with an existing strong authenticator, with help desk fallback under the standard script.

Every reset at every tier should also send a notice to the account owner through a channel the caller does not control, such as the owner’s existing device. If the real employee did not ask for the reset, they will usually say so within minutes. Okta recommended turning on these new-device and suspicious-activity notifications for end users.

The temporary credential deserves its own controls. Microsoft’s cloud directory offers a time-limited temporary access pass for this purpose, and other platforms have equivalents. A short lifetime, single use and a narrow list of people allowed to issue such passes keep the recovery credential from becoming a second, weaker password.

Caesars showed why outsourcing needs separate attention. Many banks use a managed service provider for first-line IT support, sometimes offshore and sometimes shared with other clients. The contract usually sets response times and satisfaction targets. It rarely specifies which accounts the provider’s agents may never touch, what verification they must perform for the rest, how calls are recorded, and how quickly the bank is told of an unusual request.

Those terms belong in the statement of work, with technical enforcement behind them: the provider’s agents should lack the permission to reset privileged accounts, so that a convincing caller cannot succeed. A rule that agents should not reset administrator accounts depends on every agent remembering it under pressure; a system setting that makes it impossible does not. Bank examiners already expect third-party risk management to cover providers with access to critical systems, and an outsourced help desk is one of them.

What the rules ask, by type of institution

The regulatory hooks for an outsourced help desk differ by charter, and institutions should confirm with counsel which apply. Banks supervised by the Federal Reserve, the FDIC or the OCC fall under the agencies’ interagency guidance on third-party relationships, finalized in June 2023. It expects risk management proportionate to how critical the service is. The same agencies’ computer-security incident notification rule has been in force since 2022. It requires a bank service provider to notify its bank customers as soon as possible about incidents that disrupt covered services for four hours or more. A help desk contract can extend that duty to unusual requests about privileged accounts.

Credit unions are in a different position. The NCUA lacks authority to examine credit union vendors directly, so the contract is the main lever a credit union holds. The NCUA’s own rule requiring federally insured credit unions to report qualifying cyber incidents within 72 hours took effect on September 1, 2023, days before the casino attacks.

Broker-dealers answer to the SEC and FINRA. In 2024 the SEC amended Regulation S-P to require written oversight of service providers, including notice from a provider within 72 hours of a breach affecting customer information. Firms licensed by New York’s Department of Financial Services must also meet that regulator’s requirements on third-party service providers and privileged access.

One objection deserves an answer. A strict tier 0 process will occasionally strand a genuine administrator during an outage or at an awkward hour. The tested break-glass accounts exist for that case, and two members of the identity team should be reachable on call. A delay of a few hours for a legitimate engineer is a cost the bank can plan for. A stranger holding super administrator rights overnight is not.

Alarms on the identity platform itself

Some social engineering will still succeed, so the third part is detection. The events that matter are generated by the identity platform rather than by endpoints or the network. Endpoints are laptops, desktops and phones; most security monitoring grew up watching them and the network traffic between them.

The identity events worth watching include a new authenticator enrolled shortly after a reset, and a reset followed by a sign-in from an unfamiliar network. Others are a new external identity provider added to the tenant, an administrator role assigned outside a change window, or a relaxed authentication policy. A change window is the scheduled time when approved changes are made; an administrator role appearing at another time is unusual by definition.

From log event to alert

Identity platforms record these changes in audit logs, and the vendors document the event types. Okta’s advisory listed several worth monitoring, including a reset of all of a user’s factors, the creation or change of an identity provider, and sign-ins through a third-party identity provider. Microsoft’s cloud directory records comparable events for role assignments, authentication method changes and federation settings. The engineering task is to move those logs into the monitoring platform quickly, usually by polling the vendor’s interface, and to measure how many minutes that adds.

Single events produce noise in a large institution, where resets and role changes happen every day. Sequences tell more. A reset of all factors, followed within an hour by a sign-in from an anonymizing proxy and then a role change, is rarely innocent. Tying administrator role assignments to approved change tickets removes most legitimate noise, because an assignment with no ticket stands out at once. Each rule should be tested by performing the sequence in a test tenant and confirming that the alert fires.

Many security operations centers were built around endpoint and network alerts and ingested identity logs mainly for investigation after the fact. A security operations center is the team, in-house or outsourced, that watches for attacks around the clock. If identity events are only consulted after an incident, they explain what happened instead of stopping it.

Each of these events should raise a high-severity alert with a responder available at any hour. Response needs pre-approved authority to disable an administrator account, revoke all its sessions and roll back its configuration changes without waiting for a change advisory board, the committee that normally approves changes to production systems. A tabletop exercise built on the casino timeline, in which a privileged reset happens on a Sunday evening, will show quickly whether that authority exists. A tabletop exercise is a structured discussion in which leaders walk through a realistic scenario, step by step, to find gaps before a real incident does.

Containment, in the right order

Responders need a playbook written in advance, because the order of steps matters. Disabling the compromised account comes first. Revoking its active sessions and tokens comes next, since existing sessions can otherwise persist for a while. Then responders review every change the account made since the reset: new administrators, new authenticators on other accounts, new identity providers, relaxed policies and new application permissions. Each change is reversed, and any account the attacker touched is treated as compromised in turn. Only then is normal access restored for the genuine owner.

The joint advisory added a detail that changes how a response is run. It said the actors frequently joined incident remediation and response calls, likely to learn how defenders were hunting them. If the bank’s incident bridge, chat channel and email all depend on the identity platform under attack, the attacker may be listening. An out-of-band channel, set up in advance on separate accounts, lets responders coordinate without being overheard.

When monitoring is outsourced

Many community banks and credit unions buy monitoring from a managed security service provider. Those contracts usually list the log sources in scope and the alerts the provider will escalate. Identity platform logs may be missing, or ingested only for retention. The provider may also lack authority to disable an account, so an alert becomes a phone call to a bank employee who may not answer on a Sunday. The contract should name the identity events in scope, the escalation time, and the containment actions the provider may take without asking.

Two numbers belong in reports to the board risk committee: the count of control-plane accounts, and the measured time from a privileged reset to an analyst looking at it.

A Sunday evening call, played two ways

The three parts fit together best in a scenario. Take a regional bank facing the kind of call the casino attacks suggest.

At 6:40 on a Sunday evening, the bank’s outsourced help desk takes a call. The caller says he is one of the bank’s identity engineers, traveling, with a broken phone and an urgent change to make before Monday. He knows the engineer’s name, title and manager, all of which are on a professional networking site. He is polite, a little stressed, and persuasive.

In the weaker version of the bank, the help desk agent has permission to reset multi-factor authentication for any account, including administrators. The script asks for an employee number and date of birth, which the caller supplies. The agent resets the account. Within minutes, the caller enrolls his own device, signs in from an unfamiliar network, and assigns an administrator role to a second account he controls. The bank’s security operations center collects these identity logs but has no alert on them. Nobody looks until Monday morning, when staff begin reporting strange sign-in prompts. By then the attacker has had more than twelve hours with the master key.

In the stronger version, the same call goes differently at every step. The engineer’s administrator account is separate from his daily account and has no help desk recovery path at all, because the provider’s agents lack the technical permission. The agent can only log the request and tell the caller that recovery requires two members of the identity team and a video call. The request itself is flagged to the CISO the same day. Suppose the caller had somehow succeeded anyway. A new authenticator enrolled shortly after a reset, followed by a sign-in from an unfamiliar network, would have raised a high-severity alert. It would have gone to an on-call responder with authority to disable the account and revoke its sessions straight away.

The stronger version carries costs the weaker one avoids. The provider’s agents will now and then turn away a genuine engineer with a broken phone. The identity team carries an on-call burden. Detection rules will sometimes fire on legitimate weekend work. Each of these costs is visible and can be budgeted, unlike a night of undetected administrator access.

Nothing in the stronger version requires the help desk agent to be a better judge of character. It removes the agent’s ability to make the wrong decision about the accounts that matter most, and it makes sure that if something does go wrong, someone sees it in minutes instead of hours. The whole approach comes down to fewer targets, no easy recovery path for them, and fast detection on the identity platform.

What a bank stands to lose

The stakes for a bank go well beyond the IT department.

Customers and money. Control of the identity platform can open the door to wire systems and customer data. The casino attacks disrupted guests and exposed loyalty data; a bank’s equivalent would involve accounts and payments.

Earnings. MGM’s estimate of about $100 million in lost third-quarter operating earnings shows that an intrusion beginning with a phone call can reach the income statement.

Regulators. Examiners expect banks to manage the risk of the vendors they rely on. An outsourced help desk that can reset administrator accounts is an obvious question in an examination.

Reputation. Disruption that customers can see, like room keys that do not work or apps that do not load, is remembered long after systems are restored.

Disclosure clocks. A takeover of the identity platform can start several regulatory timers at once. Banks must notify their primary federal regulator within 36 hours of determining that a notification incident has occurred. From December 18, 2023, publicly traded holding companies became subject to the SEC rule requiring a Form 8-K within four business days of determining that a cybersecurity incident is material. MGM and Caesars filed under older, more general disclosure items, a few months before that requirement took effect. State breach notification laws apply where customer data is taken, and firms regulated by New York’s Department of Financial Services face a 72-hour notice requirement of their own.

Insurance. MGM said it expected its cyber insurance to cover the financial impact of the disruption and its one-time costs. Insurers commonly ask applicants about multi-factor authentication and privileged access controls. A gap between the answers on the application and the controls actually in place can complicate a claim.

Where defences usually fall short

A well-defended institution can say, in a single sentence, how many control-plane accounts it has and who holds them. Those accounts are separate from daily identities, use hardware keys, and hold power only when needed. No help desk agent, internal or outsourced, has the technical ability to reset them. Outsourcing contracts name the prohibited actions and the notification timelines. Identity platform changes trigger round-the-clock alerts, and responders have authority to act without waiting for a meeting.

The gaps tend to recur. Institutions count only people, when service accounts and vendor accounts often hold administrator rights and are rarely reviewed. They fix the script rather than the permission; better scripts help, but a determined caller tests them every day, and removing the ability is stronger. They overlook the outsourcer, whose contract measures speed and satisfaction, the very things a social engineer exploits. They watch laptops instead of the identity platform, although the most important signals in these attacks came from the identity system. And they lock down administrators without a tested break-glass path, which can turn an outage into a crisis.

Objections, and where they hold

The first objection is that banks are not casinos. Banks are examined on cybersecurity, many already issue hardware keys to administrators, and their help desks follow stricter scripts. Many large banks fit that description. Smaller institutions that rely on shared, outsourced help desks often do not, and the casino attacks were aimed at the outsourced and the overstretched.

A second objection is that phishing-resistant authentication settles the matter. It defeats stolen passwords and intercepted one-time codes. It does nothing against a recovery process that removes the hardware key and enrolls a new one on request, which is the step the callers asked for.

A third holds that the answer is a new product, such as an identity threat detection tool. Tools help, but detection without authority to act produces a report about an incident rather than a stop to it. The bank still needs the short account list, the closed recovery path and the on-call authority to disable accounts.

The last objection carries more weight. Concentrating so much trust in one identity platform is a risk in itself, and some practitioners argue for separating administration into a dedicated tenant or directory. That isolation works well at large institutions with mature teams. At a smaller bank, the added complexity can open new gaps, and a well-defended single platform with few administrators is often the better trade.

Who can reset a control-plane account, and who would notice

1. How many accounts can administer our identity platform, cloud productivity tenant, privileged access vault or cloud subscriptions, and when was that list last cleaned?
2. Could any help desk agent, ours or a provider’s, reset one of those accounts today, and is that prevented by policy or by system settings?
3. What does our outsourced help desk contract say about prohibited actions, caller verification, call recording and notifying us of unusual requests?
4. If someone added a new sign-in method or a new trusted identity provider at 9 p.m. on a Sunday, who would be alerted, and could they disable the account without waiting for a change board?
5. When did we last test our break-glass procedure, and did it work?

With hindsight

The same approach kept working. Groups associated with Scattered Spider used help desk social engineering against major retailers in the United Kingdom in spring 2025 and against U.S. insurers and airlines that summer, prompting renewed warnings from the FBI and CISA. Nearly two years after the casino attacks, the opening move was still a phone call to someone whose job is to help.

The British cases showed the cost. Marks & Spencer suspended online orders for weeks after an April 2025 attack and told investors it expected a hit of about £300 million to operating profit. The National Crime Agency arrested four people in July 2025 over the attacks on M&S, Co-op and Harrods. In July 2025, CISA, the FBI and partner agencies in four other countries also updated their 2023 advisory on the group. The update said the actors were posing as employees to persuade IT staff to reset passwords and move multi-factor authentication to devices the actors controlled. That was the casino technique, described almost word for word.

That persistence matters more than any single incident. A technique that works does not go out of fashion because it has been publicized. It moves from sector to sector, looking for the organizations that have not yet closed the gap. Retail, insurance and aviation are different industries with different systems, but their help desks share the same basic purpose, and therefore the same basic weakness.

Law enforcement responded. U.S. prosecutors charged several alleged members in late 2024, and British and U.S. authorities made further arrests and filed charges in 2025, without ending the activity. The arrests did not remove the threat, and defenders could not count on the courts to solve the problem for them.

The identity layer’s own suppliers proved to be targets as well. In October 2023, a month after the casino attacks, Okta disclosed that an attacker had used stolen credentials to reach its customer support case management system. The attacker viewed files some customers had uploaded, and Okta later said the attacker had also downloaded the names and email addresses of all its support system users. The support channel of an identity vendor turned out to be part of its customers’ control plane.

Forgotten accounts mattered too. In January 2024, Microsoft disclosed that the Russian state-sponsored group it calls Midnight Blizzard had password-sprayed a legacy, non-production test tenant account that lacked multi-factor authentication. The group then used a legacy test application with elevated access to reach corporate email. A neglected test account and an over-privileged application are exactly the leftovers the 2023 inventory work was meant to find.

Regulation moved in the same direction. New York’s Department of Financial Services finalized amendments to its cybersecurity regulation on November 1, 2023. They tightened privileged access requirements and phased in multi-factor authentication for all users by November 2025. Institutions outside its jurisdiction were not bound, but the amendments gave them a ready benchmark.

One assumption aged less well: that a video call settles who is calling. Synthetic voice and video improved quickly after 2023. In November 2024 FinCEN issued an alert to financial institutions about fraud schemes using deepfake media. Video checks still raise the attacker’s cost, but they work best against a photo already on file and alongside a second, independent approver.

Defenses did improve. Phishing-resistant authentication and just-in-time administration spread through larger institutions, and identity threat detection became a recognized product category. That last development is telling: watching the identity platform itself for signs of takeover, once a niche concern, became something vendors built and sold as a standard capability.

Adoption among smaller banks and credit unions, though, was uneven. Where an institution relies on outsourced IT support and has few security staff to watch alerts at any hour, this technique has the most room to work. Boards of community banks and credit unions have good reason to put these questions directly to their providers.

The 2023 pattern held: intrusions tended to succeed where an institution had strong authentication and a recovery process that a capable caller or an outsourced agent could still trigger. The work that matters most is narrow and concrete: few control-plane accounts, no help desk path to reset them, and fast eyes on identity changes.