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

The week

On March 22, 2022, the extortion group known as Lapsus$ posted screenshots it said showed access to internal systems at Okta, a major provider of identity and single sign-on services. Okta responded that the images related to an incident in January. An attacker had then had remote access, for a period, to the computer of a customer support engineer who worked for a third-party support provider. Okta said such engineers could reset passwords and multifactor factors for users but could not obtain passwords. It initially said that up to about 2.5 percent of its customers might have been affected. Okta’s leadership later said the company should have moved faster to understand the January report from its subprocessor. The group had claimed attacks on other large technology companies in the same period.

For many health systems, the identity provider 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. The Okta episode showed that the supplier’s own support arrangements, two contracts away from the hospital, sit inside the hospital’s trust boundary. It also showed how long a customer might wait to learn about a problem there. We look at three parts: the tier where the compromise happened, the time it took to reach customers, and what a customer could check without waiting.

The tier where it happened

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. Support staff at an identity provider need some power over customer tenants, because helping customers often means resetting credentials or authentication factors. Those powers were bounded by design. Even bounded power over identity is sensitive, since a reset of the right account can open everything behind it.

Most third-party risk programs 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. A health system can reasonably ask its identity provider for the list of roles with tenant access, the locations and employers of the people in those roles, the device controls applied to them, and whether the customer can require approval before support acts.

The time it took to reach customers

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.

For health systems, that is partly a contract problem. Vendor contracts usually include breach notification clauses tied to personal data, often written to meet HIPAA business associate requirements. 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. 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.

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.

Notice is only useful if the customer can act on it. A short playbook for a critical-vendor security notice should name who receives it, who decides whether to rotate administrator credentials and reset factors for privileged users, and which logs are pulled first. It should also set 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.

What a customer could check alone

Identity providers log administrative actions, including password and factor resets, session activity and configuration changes. 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.

That points to three standing controls for any critical identity service. Logs should flow into the health system’s own monitoring and be kept long enough to investigate events disclosed months later. Alerts should fire on administrative actions that do not originate from the health system’s own administrators, including support-initiated resets. And 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.

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. Downtime procedures for the identity layer above it, such as break-glass local accounts held under dual control, are much less so. Testing them is the only way to know whether they work.

With hindsight

Okta’s forensic review concluded that the attacker had controlled the support engineer’s workstation for about 25 minutes and had acted in two customer tenants, far fewer than first feared. Okta later ended its relationship with the subprocessor. Lapsus$, which relied on social engineering, SIM swapping and paying insiders rather than advanced tools, was the subject of a 2023 Cyber Safety Review Board report, and members were prosecuted in the UK and elsewhere. In late 2023, Okta disclosed a separate breach of its customer support case system, in which files customers had uploaded for troubleshooting were accessed. Identity providers have since added customer controls over support access and better log export. By this point in 2026, 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.