A support engineer two contracts away: Okta, Lapsus$ and the hospital front door

The week

On March 22, 2022, an extortion group calling itself Lapsus$ posted screenshots on the internet. The images appeared to show someone inside the internal systems of Okta, one of the best-known providers of identity and single sign-on services.

An identity provider is the company that checks who you are when you log in at work. Single sign-on is the convenience it sells: you prove your identity once, with a password and usually a second step such as a code on your phone, and then every connected application lets you in without asking again. It works like the badge office for a large building: get past it, and most doors open.

Okta responded within hours that the images were connected to an incident in January, two months earlier. An attacker had gained remote access, for a period, to the computer of a customer support engineer. That engineer did not work for Okta directly. The engineer worked for Sitel, a third-party firm that supplied contract staff to Okta’s customer support organization.

Okta’s published timeline filled in the gap. On January 20, its security team received an alert that a new factor had been added to a Sitel support engineer’s Okta account from a new location. The attempt failed, the account was suspended within hours, and Okta shared indicators with Sitel the next day. Sitel hired a forensic firm, whose investigation ran to the end of February. That firm’s report to Sitel was dated March 10, and Okta said it received a summary on March 17. The full report reached Okta on March 22, hours after the screenshots appeared.

The attacker, the forensic firm found, had access to Sitel’s environment over five days, from January 16 to January 21. The intruder had not taken over an Okta account. It had remotely controlled a Sitel-owned, Sitel-managed laptop that was logged into Okta’s support tools, and had taken the screenshots from it.

Over the following days, Okta published several updates, each adding detail, and its senior executives addressed customers publicly. The screenshots themselves appeared to show Okta’s internal support tool and other internal applications, which is why many customers first assumed the worst. Okta’s position, maintained throughout, was that its service had not been breached and that customers did not need to take corrective action, although it expected some would want to do their own analysis.

Okta explained what such support engineers could and could not do. Most of their work ran through an internal tool for basic tenant management. They could help reset users’ passwords and multifactor factors, the second step of the login, such as a phone app or a text code. They could not obtain anyone’s password, create or delete users, or download customer databases.

Okta said that at most 366 customers, about 2.5 percent of its customer base, might have been affected, because their tenants had been accessed by Sitel staff during the window. It reached that figure by reviewing more than 125,000 log entries. It said customers of its HIPAA and FedRAMP offerings, the versions built to meet US health privacy rules and federal government security standards, were not affected. Each potentially affected customer would receive a report of the actions Sitel had performed on its tenant.

The reaction was sharp, partly because of the timing. Customers were learning in late March about something that had begun in January, and they were learning it because the attackers had published screenshots, not because their supplier had told them. Okta’s leadership wrote that it was greatly disappointed by how long it took to receive the full report from its subprocessor, the industry term for a subcontractor that handles a supplier’s work. It added that it should have moved faster once the summary arrived.

Lapsus$ was not a one-target group. Earlier that winter it had claimed attacks on Nvidia and Samsung. On the same day as the Okta screenshots, Microsoft confirmed that the group had compromised a single employee account, gaining limited access to source code. It published an analysis of the group’s methods under the name DEV-0537. On March 24, police in the City of London announced the arrest of seven people aged 16 to 21 in an investigation into a hacking group. All were released while the inquiry continued.

Security teams at Okta customers spent much of that week in their own logs, searching the January window for activity by Okta support and resetting credentials for their most powerful administrators as a precaution. Many also asked Okta directly whether their tenant was among those affected, and how soon they would receive the promised report of support activity. For any organization whose staff signed in through Okta, including many health systems, the question that week was simple and uncomfortable: were we one of the 366, and how would we even know?

A night nurse at a large hospital walks up to a shared workstation, taps her badge or types a password, approves a prompt on her phone, and in a few seconds she is inside the electronic health record, the medication system, the imaging viewer and her email. She does not think about how that works. She should not have to.

Behind that moment is the identity provider. For many health systems, it is the front door. Clinicians sign in once and reach the electronic health record, imaging, email, the scheduling system and dozens of other applications. Administrators manage access through the same service, and remote staff and vendors come in through it too. That makes the identity provider one of a health system’s most important suppliers, even though most board members could not name it.

The Okta episode showed that the supplier’s own support arrangements, two contracts away from the hospital, fall inside the hospital’s trust boundary, the line around everyone and everything the hospital is relying on to behave. It also showed how long a customer might wait to learn about a problem there. Three parts of the episode matter: the tier where the compromise happened, the time it took to reach customers, and what a customer could check without waiting. The sections that follow set the scene, take those three parts in order, and then turn to what a distrusted identity provider costs and how to manage the supplier accordingly.

One front door for every system

Every application a hospital uses needs to know who is asking to come in. Twenty years ago, each application kept its own list of users and passwords. Staff juggled dozens of logins, wrote them on sticky notes, and when someone left the organization, IT had to remember to remove them from every system separately. Often it did not.

An identity provider centralizes that job. It holds one directory of people, checks their credentials, and then vouches for them to every connected application. When the nurse signs in, the identity provider confirms her identity and hands each application a kind of signed note that says, in effect, “this is the night nurse on Ward 4, and she has proved it.” The applications trust the note because they trust the provider.

The vocabulary a board member needs

• Single sign-on is the experience of logging in once and reaching many systems. It saves clinicians time and reduces password fatigue, which is a real safety and morale issue on a busy ward.
• Multifactor authentication means proving your identity with more than one thing: something you know, such as a password, plus something you have, such as a phone or a hardware key. Each of those second things is called a “factor.” It is the main reason a stolen password alone is no longer enough to break in.
• A tenant is one customer’s private section of a shared cloud service. Okta runs one large platform, and each hospital has its own walled-off tenant inside it, with its own users, rules and settings.
• Administrative roles are the levels of power inside a tenant. A help desk role may reset an ordinary user’s factors. A super administrator can change anything, including who else is an administrator.

How the signed note travels

The signed note travels using open standards, most often SAML or OpenID Connect. The application checks the note’s signature against the provider’s published key and then creates its own session for the user. That session may last for a shift or longer. Two consequences follow. Revoking access at the identity provider does not always end sessions already granted downstream. And anyone who can make the provider vouch for the wrong person gets every connected application at once.

Behind the scenes, most hospitals connect the cloud identity provider to an on-premises directory, usually Microsoft Active Directory, through software agents. New hires, transfers and departures flow from the human resources system to the directory and on to applications, often through an automated provisioning standard called SCIM. That plumbing is what makes one switch-off close every door. It also means the identity provider’s administrative console can reach far beyond the cloud service itself.

What it does in a hospital day

The identity provider does not guard each application, but whoever controls it controls who gets in. That is why the people who can operate it, including the supplier’s support staff, matter so much.

Inside a hospital, the identity provider touches almost every working day. When a new resident starts in July, her account is created in the directory and she is placed in groups that decide which systems she can open. When a contractor’s engagement ends, switching off one identity account closes every door at once, which is one of the strongest security arguments for the whole model. When a physician is locked out at 3 a.m., the hospital’s own help desk usually resets her login. When the hospital’s administrators themselves get stuck, or something in the tenant breaks, they call the identity provider’s support line.

That last step is the one this story turns on. The help desk inside the hospital is visible, staffed by known employees and governed by the hospital’s policies. The support line at the supplier is a black box. It may be staffed by the supplier’s employees, by an outsourcing firm, or by both, working from offices the hospital has never seen. Concentrating identity in one place makes a hospital both safer and more dependent.

Why identity moved up the attacker’s list

By early 2022, attackers had learned that breaking software is harder than borrowing someone’s identity. Phishing pages that capture passwords and one-time codes in real time were widely available. Some groups flooded users with login prompts until one was approved by mistake. Others called help desks and asked for a reset. Every one of those techniques targets the processes that issue and restore credentials, not the cryptography that checks them. An identity provider’s support function is one of those processes, run at very large scale on behalf of thousands of customers.

Differences across health care organizations

The dependence looks different by type of organization. A large health system may run a dedicated identity team, a badge-based tap-and-go product on shared clinical workstations, and hundreds of integrated applications. An ambulatory network or physician group may rely on the identity service bundled with its productivity suite, with a small IT staff and a managed service provider. A life sciences company may route laboratory and manufacturing systems through the same front door, where access records also matter for regulated quality systems. Each faces the same supplier question, with very different capacity to answer it.

Two contracts away

The attacker did not breach Okta’s core platform. The compromise was of a support engineer’s computer at a subprocessor that handled customer support for Okta. That distinction matters, and it cuts both ways.

Why support staff hold real power

Support staff at an identity provider need some power over customer tenants, because helping customers often means resetting credentials or authentication factors. When a doctor loses her phone and cannot log in, someone has to reset her second factor. Those powers were bounded by design: support engineers could help reset passwords and factors but could not obtain passwords. Even bounded power over identity is sensitive, since a reset of the right account can open everything behind it. Reset the password and the second factor of a senior system administrator, and you no longer need to steal anything. You simply become that person.

The forensic findings showed a second point. The engineer’s laptop belonged to Sitel and was managed by Sitel. Okta’s own security controls ended at the login to its support tools. Whatever happened on the device itself, including who else was controlling it, was governed by another company’s security program. Okta later committed to manage directly every third-party device that accesses its customer support tools.

Why vendors outsource support

Outsourcing support is common across the software industry, and for sound reasons. Business process outsourcing firms offer round-the-clock coverage across time zones, trained staff at scale and lower cost. A software company growing quickly can add support capacity in weeks rather than months. Nothing about that is improper. It does mean that the people with hands on a customer’s tenant may answer to a different employer. Their security team and device policy may differ from those of the vendor whose name is on the contract.

What the usual assurance misses

Most third-party risk programs, the processes organizations use to vet their suppliers, assess the vendor. They review its architecture, certifications and incident history, and ask a general question about subcontractors. They rarely ask who, at the vendor or its subcontractors, can act inside the customer’s own environment, from what devices, under what monitoring, and with what approval. For the handful of suppliers whose compromise would expose everything, those are the questions that matter.

The standard assurance report has a specific blind spot. A SOC 2 report, the audit report most software vendors provide, may describe a subcontractor’s work using what auditors call the carve-out method. Under that method, the subcontractor’s controls are excluded from the audit, and the report lists controls the vendor expects the subcontractor to have. A hospital reading the report needs to find that section and see which subcontractors it covers. A clean opinion on the vendor says little about a carved-out support firm.

HIPAA’s contract chain has a similar gap. A business associate must flow its obligations down to subcontractors that create, receive, maintain or transmit protected health information. A support engineer resetting factors may never touch patient data, so the chain of business associate agreements may never reach that engineer at all. The hospital’s privacy contracts can be complete and still say nothing about the people who hold its keys.

Questions to put to the identity provider

A health system can reasonably ask its identity provider for:

• the list of roles with access to the hospital’s tenant;
• the locations and employers of the people in those roles, including subcontractors;
• the device controls applied to them, such as whether their laptops are managed and monitored, and by whom;
• whether support actions in the tenant appear in the hospital’s own logs, and how they are labeled;
• whether the customer can require its own approval before support acts in its tenant.

Suppose a regional health system reviews its identity provider every year using a standard questionnaire. The vendor holds strong certifications and answers every question well. Nowhere does the questionnaire ask how many people outside the vendor’s own staff can reset one of the hospital’s administrator logins. The honest answer might be “many support staff, some of them employed by outsourcing firms abroad.” That answer would not necessarily be alarming. It would, however, change how the health system monitors its tenant and what it negotiates.

What a deeper review takes

The deeper review is not a large project. For most health systems, only a handful of suppliers hold administrative power over everything. Typically they are the identity provider, the electronic health record vendor, the email and productivity platform, and perhaps a remote access or endpoint management service. A focused review of those few, built around the questions above, can be done in a few working sessions with each vendor. The output is a one-page record per supplier: who can act in the tenant, from where, under whose device controls, with what visibility to the hospital. That record is far more useful in an incident than a long questionnaire filed away.

Where this argument is weakest

The strongest objection is that the subcontractor tier was not the decisive weakness. In-house staff can be compromised too, and a later Okta incident, discussed below, began with an Okta employee’s credential. Pressing every critical vendor for a map of its support staff also takes time that third-party risk teams do not have. Both points are fair. The response is to apply the deeper questions only to the few suppliers that hold administrative power over everything. The rest of the effort belongs on controls the hospital owns: visibility of support actions, approval where offered, and alerts. Those work regardless of who employs the person on the other end.

Two months of silence

The intrusion happened in January. Customers learned of it in March, after the attackers posted screenshots. Okta acknowledged it should have acted faster once its subprocessor reported the event. For two months, customers could not assess their own exposure, rotate credentials or review logs with the incident in mind.

How the delay built up

The timeline shows how such delays happen without anyone deciding to hide anything. Okta detected suspicious activity on one account and contained it within hours. It then treated the matter as an incident at its subprocessor, to be investigated by the subprocessor’s forensic firm. That firm took weeks. Its findings passed from the firm to Sitel and only then, in summary, to Okta. At each handoff, the question of whether customers should be told was implicitly deferred to the next party.

A customer contract that required notice on a clock would have forced that question earlier. So would an internal rule at the vendor that any confirmed compromise of a device with access to customer tenants triggers a customer notice assessment, whoever owns the device.

What customers could do in the meantime

Once the screenshots appeared, prepared customers moved quickly. They searched their own copies of the identity logs for any action attributed to the provider’s support staff between January 16 and January 21. They listed every password and factor reset on administrative accounts in that window and confirmed each with the person concerned. They rotated credentials for super administrators and for the service accounts that connect the identity provider to the on-premises directory. Customers without their own logs could do almost none of this. They waited for Okta’s customer reports, which is to say they waited on the same supplier whose delay had caused the problem.

Why privacy clauses stayed silent

For health systems, that is partly a contract problem. Vendor contracts usually include breach notification clauses tied to personal data, often written to meet the requirements HIPAA sets for business associates, the outside firms that handle patient information on a provider’s behalf. Those clauses turn on protected health information. An identity provider incident may involve no patient data at all and still be more dangerous than a data breach, because it touches the control plane for every system. The control plane is the machinery that decides who can do what; compromise it, and the data is only a step away.

The HIPAA Security Rule does require business associates to report security incidents they become aware of, and that definition is broad. Its reach here was limited. Okta said its HIPAA offering was unaffected, and a hospital that bought the standard service without a business associate agreement had no such clause to invoke. Many business associate agreements also narrow the duty in practice, excluding routine unsuccessful attempts and saying little about timing.

Few contracts required notice of security incidents affecting the vendor’s ability to protect the customer’s environment, on a defined clock, regardless of whether data was taken. That gap is easy to miss because most contracts were drafted by privacy lawyers thinking about records, not by security teams thinking about keys.

What other sectors had already written down

Banking regulators had addressed the same gap a few months earlier. The federal banking agencies finalized a computer-security incident notification rule in November 2021. It required bank service providers to notify their bank customers as soon as possible when an incident disrupted covered services for four hours or more. Compliance began on May 1, 2022. Health care had no equivalent rule. Hospitals had to write the duty into contracts themselves.

Winning the clause, or recording the refusal

Adding that clause is straightforward to draft and harder to win. Large providers resist bespoke terms. Health systems negotiating together, through purchasing groups or sector bodies, carry more weight than one hospital alone. Even where the clause cannot be won, asking for it records the expectation, and the vendor’s answer is useful risk information. A vendor that refuses any defined notice window is telling you something.

A workable clause has four parts. It defines the trigger as any security incident affecting the vendor’s systems, personnel or subcontractors that could affect the confidentiality, integrity or availability of the customer’s tenant. It sets a clock, measured in hours or days rather than the 60 days familiar from HIPAA. It requires updates as facts develop. And it obliges the vendor to provide the customer with the relevant logs and findings for its tenant.

A playbook for the notice

Notice is only useful if the customer can act on it. A short playbook for a critical-vendor security notice should name:

• who receives the notice, around the clock;
• who decides whether to rotate administrator credentials and reset factors for privileged users;
• which logs are pulled first;
• a deadline for asking the vendor the standard questions: dates, scope, affected tenants and actions taken.

Rehearsing that playbook once a year with the identity team costs an afternoon. It turns a frightening headline into a checklist.

The logs a hospital keeps for itself

Identity providers log administrative actions, including password and factor resets, session activity and configuration changes. A log is simply a running diary that a system keeps of what happened, when and at whose request. A customer that exported those logs to its own security monitoring, and kept them, could search the January window for resets or sessions initiated by provider support. A customer relying only on the provider’s console, with its retention limits, might find the history incomplete or gone.

This is the part of the story most within a leader’s control. Many cloud services keep only a limited window of history in their own consoles, often measured in weeks or a few months. If a supplier tells you in March about something that happened in January, and you have not been copying the diary into your own files, you may be unable to answer the board’s first question: did anything happen to us?

Three standing controls

1. Keep your own copy. Logs should flow into the health system’s own monitoring and be kept long enough to investigate events disclosed months later.
2. Watch for outside hands. Alerts should fire on administrative actions that do not originate from the health system’s own administrators, including support-initiated resets.
3. Know and limit support’s reach. The health system should know, and where possible restrict, how provider support can act in its tenant, such as requiring customer approval or limiting support to read-only access.

How long to keep the diary

HIPAA’s audit controls standard requires mechanisms that record and examine activity in systems containing electronic protected health information, but it leaves retention periods to each organization. Federal agencies had been given a benchmark in August 2021, when the Office of Management and Budget’s memorandum M-21-31 set logging maturity requirements. It called for twelve months of logs in active storage and a further eighteen months in cold storage. Hospitals are not bound by that memorandum. It is a defensible reference point when a board asks how long is long enough.

Retention costs money. Security monitoring platforms often charge by the volume of data ingested, and identity logs are voluminous. A common compromise keeps administrative and authentication events in fast, searchable storage for a year and archives the rest more cheaply. Administrative events are a small fraction of the volume and the most valuable for this kind of investigation.

What the alerts should look for

The most useful alerts are narrow. A reset of a factor or password on any administrative account. A new administrator added to the tenant. Any action recorded as performed by the provider’s support staff. A sign-in by an administrator from a device or location never seen before. Each of these is rare in a normal week, so the alerts generate little noise, and each is exactly the step an attacker with support access would take.

Who reads the alerts at night

An alert is only as good as the person who sees it. Many hospitals buy round-the-clock monitoring from a managed detection and response provider rather than staffing their own overnight team. That arrangement works if the provider actually ingests the identity logs, has rules for the narrow events above, and knows whom at the hospital to wake. Contracts for such services often list data sources in an appendix. Checking that the identity provider appears there, and testing it with a harmless administrative action, takes an hour and closes a common gap.

When the front door itself is in doubt

The clinical setting adds one more check. Clinicians need fast access, often at shared workstations, and authentication friction can delay care. Many health systems therefore rely heavily on single sign-on and tune it for speed. If the identity layer is unavailable, or must be distrusted while an incident is investigated, clinicians still need to reach the record.

Downtime procedures for the record are common: most hospitals have paper forms and read-only copies ready for when the electronic health record goes down. Downtime procedures for the identity layer above it are much less so. One common approach is break-glass accounts, emergency local logins that bypass the identity provider and are held under dual control, so that two named people must act together to use them.

Break-glass access needs its own discipline. The credentials are stored offline or in a sealed vault, use of them triggers an immediate alert, and every use is reviewed afterward. The accounts should be tested on a schedule, because a password that expired unnoticed in a vault is worse than none. Testing such procedures is the only way to know whether they work.

What a distrusted identity provider costs a hospital

A hospital that loses confidence in its identity provider takes damage in four places at once.

Patient safety

If a hospital has to distrust its identity provider during an investigation, every clinician’s access is in question at once. Without a tested fallback, the choice is between keeping a possibly compromised front door open and locking clinicians out of the record. Neither is acceptable for long. The middle path, resetting privileged accounts while leaving clinical sign-in running under closer monitoring, requires knowing in advance which accounts are privileged and how long their reset takes.

Regulatory exposure

Regulators expect covered entities to manage the risks of their business associates. A hospital that cannot show it asked basic questions about who can reach its systems, or that cannot reconstruct what happened because it kept no logs, will find its position harder to defend, whether or not patient data was touched. The HIPAA risk analysis is the natural home for this evidence. An analysis that lists the identity provider as a system but never examines its support access is a gap an investigator can find.

Money

Investigations are expensive, and they are far more expensive when evidence is missing. Every week spent trying to reconstruct events from incomplete records is paid for in outside forensic fees, staff time and delayed projects. Cyber insurers increasingly ask about multifactor authentication, privileged access and logging at renewal. Weak answers can raise premiums or narrow coverage before any incident occurs.

Partners who share the front door

Many health systems extend their identity service to people they do not employ: affiliated physicians, students and residents, research collaborators and vendors with remote access. Each of those groups depends on the same front door. An incident that forces a health system to reset or distrust identities ripples out to clinics and partners who may have no idea which provider sits behind the login page. Their contracts with the health system rarely say what happens to their access during such an event, or who will tell them.

Reputation and trust

Patients and staff do not distinguish between a hospital’s own failure and its supplier’s. The hospital’s name is the one that appears in the local news. Clinicians also remember. A week of disrupted logins during an investigation spends goodwill that the next security project will need.

Identity as a tier-one supplier

A health system that handles this well treats its identity provider as a tier-one supplier, in the same category as its electronic health record vendor. Concretely, that tends to mean:

• a named executive owner for identity, alongside the technical administrator;
• a contract that requires notice of security incidents affecting the hospital’s environment on a defined clock, or a documented record of having asked;
• a clear map of who outside the hospital can act in its tenant, refreshed at least yearly;
• identity logs copied into the hospital’s own monitoring and retained for an agreed period;
• alerts on support-initiated or otherwise unusual administrative actions;
• tested break-glass access for clinical systems, held under dual control.

Owners and evidence

Each item needs an owner and evidence. The identity executive owns the map of outside access and the annual review. Procurement and legal own the notice clause, and keep the vendor’s written answer if the clause is refused. The security operations team owns log retention and the alerts, and can show an auditor a sample alert and its handling. Clinical informatics owns the break-glass procedure jointly with security, and keeps the test records. The board’s audit or risk committee should see a one-page summary once a year.

Sequencing with limited staff

Few hospitals can do all of this at once. A sensible order starts with what the hospital controls entirely: exporting logs and setting the narrow alerts. Those take days and need no vendor agreement. Mapping outside access and testing break-glass follow within a quarter. Contract terms come last, at the next renewal, when the hospital has bargaining power and a clear picture of what to ask for.

Concentration, and the case for a second door

Some security leaders drew a broader conclusion from the episode: that one identity provider for everything is too much concentration. The case for spreading identity across two providers is real, since an outage or compromise at one would not take out every system. The case against is stronger for most hospitals. Two providers mean two sets of policies, two administrative teams and twice the places for a misconfiguration to hide. Clinicians would face more login friction, not less. A more practical form of diversity is narrower. Keep the break-glass path and a small number of administrative accounts independent of the main provider. If the front door itself is in doubt, the hospital can still reach its most important systems and repair the door.

The trade-off with speed

Requiring customer approval before support acts in the tenant slows support down. During an outage, waiting for an approver at 2 a.m. can lengthen downtime. The answer is a short list of approvers on call, with a defined response time, and a clear policy for which support actions need approval. Speed and control can coexist when the approval step is designed rather than improvised.

How it goes wrong

• Treating certifications as answers. A strong audit report tells you the vendor has controls. It does not tell you who can reset your chief nursing officer’s login.
• Reading notification clauses only through a privacy lens. If the clause triggers only when patient data is taken, it will be silent in exactly the incidents that matter most for identity.
• Relying on the vendor’s console for history. Retention windows are designed for day-to-day troubleshooting, not for investigations that start months late.
• Optimizing only for speed. Fast clinical login is a real good. Fast login with no tested fallback is a single point of failure.
• Assuming a smaller blast radius means no action. Even if you were not among the affected customers, the episode is a free rehearsal of a scenario you will one day face.

Who can open our doors

• How many people outside our organization, at the vendor and its subcontractors, can reset a password or second factor in our tenant? Where are they, and who employs them?
• If our identity provider told us tomorrow about an incident four months ago, could we search our own records for that period? How far back do our identity logs go?
• Would we be alerted today if someone other than our own administrators reset a privileged account?
• Does our contract require the vendor to tell us about security incidents affecting our environment, on a fixed timeline, even when no patient data is involved? If not, have we asked?
• If we had to stop trusting single sign-on for 24 hours, how would clinicians reach the record? When did we last test it?

Asking these needs no technical knowledge, and each deserves a specific answer, with a name and a date attached. For the supplier that holds the keys to every door in the hospital, that is a modest standard.

With hindsight

The facts, once in, were less severe than first feared. Okta concluded its investigation on April 20, 2022. The forensic review found that the attacker had controlled the support engineer’s workstation for 25 consecutive minutes on January 21 and had accessed two active customer tenants in the support tool. During that time the attacker could not change configurations, reset passwords or factors, or sign in directly to any Okta account. The initial estimate of up to 366 customers had been a worst case, drawn up before the investigation could narrow it.

Okta’s response was specific. It ended its relationship with Sitel, which had acquired Sykes the year before. It committed to manage directly all third-party devices that access its support tools and to require subprocessors to authenticate through its own identity platform. It also said it would restrict what support engineers could see and show support tool activity in customers’ own system logs. It also said it would change how it communicated security and availability issues to customers.

The group behind it turned out to be less sophisticated than its impact suggested. Lapsus$ relied on social engineering, SIM swapping and paying insiders rather than advanced tools. Social engineering means talking or tricking people into handing over access. SIM swapping means persuading a mobile carrier to move a victim’s phone number to a phone the attacker controls, so that text-message login codes go to the wrong person. Paying insiders is exactly what it sounds like.

The Cyber Safety Review Board, a federal review body set up to study significant cyber incidents, examined Lapsus$ and related groups in a report released in August 2023. It urged organizations to move away from text-message and voice codes toward phishing-resistant authentication such as FIDO2 security keys and passkeys. It called on mobile carriers to treat SIM swaps as high-risk transactions, on regulators to strengthen oversight of them, and on companies to write shared security responsibilities into contracts with outsourcing firms. The board itself was disbanded in January 2025, when DHS ended the memberships of its advisory committees.

The weak points Lapsus$ exposed were soon used by others. In late August 2023, Okta warned customers of a campaign in which callers persuaded IT service desks to reset multifactor authentication for highly privileged accounts. Similar help desk calls were widely reported in the attack on MGM Resorts weeks later. In April 2024, the HHS Health Sector Cybersecurity Coordination Center warned hospitals of callers posing as revenue cycle staff, who persuaded help desks to enroll new authentication devices and then redirected payer payments. Its advice included calling back the number on record before any reset.

The support channel at Okta was breached again. Between late September and mid-October 2023, an attacker used a stolen credential for a support service account to reach files in Okta’s customer support system. Some were browser recordings that customers had uploaded for troubleshooting, and they contained session tokens. Okta first said 134 customers were affected and that sessions at five of them had been hijacked; several of those customers had spotted the activity themselves. In late November, Okta disclosed that the attacker had also downloaded a report containing the names and email addresses of all its customer support system users, outside certain government environments. Once again the weak point was the support channel, not the core product.

The industry did respond. Identity providers have since added customer controls over support access and better log export, making it easier for customers to approve or limit what support can do and to keep their own records. The February 2024 attack on Change Healthcare, which UnitedHealth’s chief executive told Congress began through a remote access portal without multifactor authentication, kept identity at the center of health sector security debates. HHS proposed in January 2025 to make multifactor authentication an explicit HIPAA Security Rule requirement; that proposal was still not final in October 2026.

By this point in 2026, the arguments of March 2022 are routine in vendor reviews. Questions about who at a supplier can act in a customer tenant, and how the customer will see it, now appear in many security questionnaires. Identity infrastructure is widely treated as a primary target in health care. The better health systems review their identity provider with the same depth they apply to their record vendor. The most important questions about a critical supplier often concern the people two contracts away who can still open your doors, more than the supplier itself.