How a troubleshooting file handed over an administrator’s session in the Okta breach

The week

When something breaks in a software product, the vendor’s support team usually asks for evidence: a screenshot, a log, a recording of what the browser was doing. Customers send it without a second thought. They are trying to get a problem fixed, and the vendor is a trusted partner. In October 2023 that ordinary, helpful habit turned out to be the way in.

On October 20, 2023, identity provider Okta disclosed that an attacker had used stolen credentials to access its customer support case management system. An identity provider is the company that handles sign-in for other organizations’ staff, the system that checks who you are when you log in to work applications and then lets you into all of them. That makes it one of the most sensitive services an organization buys. The case management system is the separate tool Okta’s support staff use to track customer problems.

Inside that system, the attacker viewed files some customers had uploaded with support cases. Some were HTTP Archive (HAR) files, browser recordings used for troubleshooting. A HAR file captures everything a browser sends and receives while it is recording. That can include session cookies and tokens, the small pieces of data a website hands your browser after you sign in so you do not have to sign in again on every page. A session token works like a festival wristband: once you have shown your ticket at the gate, it gets you back in, and anyone wearing it looks like you.

In the following days, affected customers published their own accounts. BeyondTrust, a security company, said it had detected and blocked suspicious activity in early October and reported it to Okta. Cloudflare and 1Password described related activity in their environments. All three are themselves security-minded technology firms, which gave the episode an uncomfortable edge.

The customers’ accounts filled in a timeline that Okta’s first notice had not. 1Password said it detected suspicious activity on September 29 in the Okta tenant it uses to manage employee-facing applications. It terminated the activity and found that no user data had been accessed. BeyondTrust reported suspicious activity to Okta on October 2. Cloudflare said it detected attacks on October 18 and traced them to Okta more than 24 hours before Okta notified it.

Cloudflare’s account was the most specific. The attacker had used an authentication token taken from a support ticket that a Cloudflare employee had opened. With that open administrative session, the attacker compromised two Cloudflare employee accounts within Okta. Cloudflare said it contained the activity before the attacker reached customer data, customer systems or its production network. It also noted that this was the second time a breach of Okta’s systems had affected it, after the Lapsus$ episode of January 2022.

The gap between first report and confirmation unsettled security teams most. Customers had raised concerns for nearly three weeks before Okta identified its support system as the source. Okta later explained part of the delay. Its review had searched for one kind of log event, the viewing of files inside a case. The attacker had mostly used the system’s separate Files tab, which logged a different event type, and that activity went unnoticed for 14 days.

Okta’s detailed account followed on November 3. It put the attacker’s access between September 28 and October 17, 2023. In that period the attacker viewed files belonging to 134 customers, fewer than 1 percent of Okta’s customer base. Some of those files were HAR files containing session tokens, and the attacker used them to hijack the legitimate Okta sessions of five customers. Okta said it disabled the compromised account on October 17 and revoked the session tokens embedded in the HAR files.

Okta said the support system was separate from its production service, the live system its customers rely on for sign-in. In late November it widened its findings, saying the attacker had also downloaded a report with the names and email addresses of all its customer support system users.

For readers outside identity teams, the most important fact was how routine the requested file was. Vendors across the software industry ask for HAR files because they show exactly what a browser did when an error occurred: each request, each redirect, each response. Sign-in problems are especially hard to diagnose without one, because the failure often lies in a chain of redirects between an application and an identity provider. Support agents ask for them by habit, and customers send them by habit.

Cloudflare published a list of steps for other Okta customers. It urged hardware-based multi-factor authentication for all users, investigation of unexpected password and MFA changes and of suspicious support-initiated events, and a review of session expiration policies to limit session hijacking. Several of those items addressed what an attacker could do with a session once inside, rather than how the session was stolen.

Health systems send files to dozens of vendors every week, and for them the question was immediate: what have we been putting into other companies’ support queues?

In the Lapsus$ episode of 2022, an identity provider’s customers had waited to learn of a compromise in its support chain. The October 2023 incident raised a different question, about what customers themselves had put into that chain.

Health systems run on vendors: EHR, imaging, identity, revenue cycle, interface engines, telehealth, and dozens of smaller products. Troubleshooting each one means sending the vendor something, such as logs, screenshots, configuration exports, browser recordings or test extracts. Most of this traffic is invisible to leadership. It happens in thousands of small exchanges between analysts, clinicians, billing staff and vendor support agents, each trying to get a system working again.

The exposure of any support artifact has three parts, which together determine what an attacker gains by reading it: what it contains, what it is under HIPAA, and how long it stays usable. A short tour of the vocabulary comes first.

Logs, tokens and business associates

An EHR, or electronic health record, is the main clinical system in which doctors and nurses document care. An interface engine moves messages between systems, for example sending a lab result from the laboratory system into the EHR. It speaks standard health data formats. HL7 is a long-established format for such messages. FHIR, pronounced “fire,” is a newer standard that lets systems exchange health data over the same kind of web connections that power ordinary websites and apps.

A log is the running record software keeps of what it is doing. Most systems can be set to log at different levels of detail. At “debug” level, used when chasing a problem, they record a great deal, sometimes including secrets they should not.

A configuration export is a file that captures how a system is set up, so a vendor can reproduce it. A service account is an account used by software rather than a person, for instance the account the interface engine uses to sign in to the EHR. Its password often sits in the configuration. An API key is a long secret string that lets one program call another, effectively a password for software.

A session is the period during which a system treats you as signed in. When you log in, the system issues a token, and your browser presents it with every request. Whoever holds the token is treated as you, without needing your password or the second sign-in step that multi-factor authentication adds. A stolen token is valuable because it skips the front door entirely.

How a HAR file gets made

Producing a HAR file takes about a minute. The user opens the browser’s developer tools, switches to the network panel, reproduces the problem and exports the recording. Support instructions often add a step to preserve the log across page loads, so that sign-in redirects are captured. That step is also what sweeps the session cookies and tokens issued during sign-in into the file.

The export is a plain text file in a structured format. Anyone who opens it in a text editor can read every header and, in many cases, the body of each response. Nothing in the format marks the sensitive parts or encrypts them. The person who made it usually never looks inside.

Three kinds of token

Not every token is equally dangerous. A session cookie tells one website that the browser is signed in. An access token, common in modern application interfaces, lets a program call an interface for a limited time, often an hour or less. A refresh token lets the holder obtain new access tokens without signing in again, and it can last days or weeks. A file that captures a refresh token or a long-lived administrative cookie is worth far more to an attacker than one holding a short-lived access token.

Finally, a business associate, in HIPAA’s vocabulary, is an outside organization that handles protected health information on a health system’s behalf, and a business associate agreement is the contract that binds it to HIPAA’s safeguards.

Since the HIPAA Omnibus Rule of 2013, the chain extends further. A subcontractor that creates, receives, maintains or transmits protected health information on behalf of a business associate is itself a business associate. That matters for support systems, because many vendors run case management on a commercial platform operated by another company.

Secrets inside a troubleshooting file

A HAR file records everything a browser sends and receives, including cookies and authorization headers, the parts of each request that prove who is asking. Captured during an administrator’s signed-in session and uploaded unredacted, it hands the reader that session. Okta’s customers had done what support asked. The danger lay in the file’s contents.

Why multi-factor authentication did not help

The attack went around controls that many organizations regard as their strongest. Multi-factor authentication checks a person at the moment of sign-in. Once that check passes, the identity provider issues a session, and the session does not ask again. A token copied from a HAR file was minted after the second factor had been satisfied. To the identity provider, the attacker presenting it looked like an administrator who had signed in properly a little earlier.

Phishing-resistant methods such as hardware security keys raise the cost of stealing a password and a code. They do nothing about a session that has already been established and then copied. The defenses for that problem lie elsewhere: in how long sessions last, whether they are tied to a device or network, and whether sensitive actions demand a fresh check.

Other artifacts carry similar material. Application logs at debug level often record tokens and connection strings, the details a program uses to reach a database, sometimes including the password. Configuration exports from interface engines can contain service account passwords for HL7 or FHIR connections. Screenshots of an administrator console may show API keys. Database extracts sent to reproduce a defect contain whatever the query returned.

The controls are practical. Staff can use sanitizing tools that strip cookies, authorization headers and known secret patterns from HAR files and logs before upload, and Cloudflare, among others, released an open-source HAR sanitizer after the incident. Captures can be made with test accounts rather than privileged ones, so that even an unsanitized file opens only a sandbox. The service desk can keep a short list of artifact types that require a security review before leaving the organization, such as configuration exports and database extracts. And the person who shares an artifact should note what it was, so it can be found again if the vendor reports a breach.

Where sanitizers fall short

Sanitizing tools work by pattern. They remove cookies, authorization headers and values that match known formats. Tokens can also hide in less obvious places: query strings in redirect addresses, the bodies of sign-in responses, custom headers an application invented, or form fields posted during sign-in. A sanitizer tuned for one vendor’s format may miss another’s. Staff should treat sanitizing as a strong default, not as proof that a file is clean.

There is also a direct trade-off with what the vendor needs. Some sign-in problems are caused by the very cookies and headers a sanitizer strips, and the vendor cannot diagnose them without seeing what was sent. The answer in those cases is to capture the file in a session that will be thrown away. That means a test account, or a privileged session that is ended and revoked as soon as the capture is uploaded.

Controls on the way out

A second line of defense works at the network edge. Many health systems already run data loss prevention tools on outbound email and web uploads to find patient identifiers. The same tools can look for the shapes of secrets. Tokens in the widely used JSON Web Token format, for instance, begin with a recognizable string of characters. A rule that flags a HAR attachment, or a token pattern in a file bound for a vendor domain, catches what a busy analyst forgets.

Such rules generate false positives and need tuning. They also cannot see uploads made through a vendor’s web portal over an encrypted connection unless the organization inspects that traffic. Each health system has to weigh the inspection it is willing to run against the privacy and performance costs. A simpler control is to route vendor uploads through one sanctioned path, so that the inspection point and the record of what was sent are in the same place.

What to ask of the vendor’s support desk

The customer controls only half of the exchange. The other half is how the vendor runs its support system, and a vendor security review can ask about it directly. Useful questions cover whether the support portal scans or strips tokens from uploaded files, and whether attachments expire automatically. Others cover whether support staff can see every customer’s files or only those of cases assigned to them, and whether downloads of attachments are logged and monitored. Okta’s own account showed why the last point matters: the attacker’s file activity went unnoticed partly because it generated a log event nobody was watching.

The answers will rarely be perfect, and few customers have the bargaining power to change a large vendor’s support platform. They still shape behavior on the customer side. A vendor whose support system keeps every attachment indefinitely, visible to its whole support staff, should receive only sanitized, low-value files. Smaller health systems, with the least bargaining power, gain the most from that rule, because it depends on nothing the vendor has to agree to. It can start the same day.

Volume makes this a process question rather than a training question. A large health system opens thousands of vendor cases a year across clinical, financial and infrastructure teams, many of them outside IT. A short procedure that applies to all of them, built into the service desk tool and the vendor management checklist, will do more than an annual awareness module. Measuring it is straightforward: sample a few dozen recent vendor cases each quarter and check what was attached.

The shape of the procedure varies with the organization. An academic medical center may have dozens of departmental application teams, each with its own vendor relationships and habits. It needs the procedure embedded in a central vendor case tool and enforced by sampling. A community hospital with a small IT team often outsources its service desk to a managed service provider, whose staff are then the ones sending files. There the procedure belongs in the provider’s contract. An ambulatory network on a vendor-hosted EHR sends fewer files, but most of them go to a single, critical vendor.

Patient data in a support ticket

A screenshot of an EHR error, a log from an interface engine or an extract used to reproduce a billing defect may contain protected health information, or PHI, the identifiable health data HIPAA protects. A vendor that receives PHI to provide services to a covered entity is generally a business associate and needs a business associate agreement. Most major health IT vendors have signed one.

The rules that apply to a support upload

Several HIPAA provisions apply at once. The minimum necessary standard requires a covered entity to limit the protected health information it discloses to what is reasonably needed for the purpose, and it applies to disclosures to business associates. An extract of ten thousand patient rows, sent to reproduce a defect that one row would show, is hard to defend under that standard.

The breach notification rule sets the clock if something goes wrong. A business associate must notify the covered entity of a breach of unsecured protected health information without unreasonable delay and no later than 60 days after discovery. The covered entity must notify affected individuals within the same outer limit of 60 days from its own discovery. Breaches affecting 500 or more people also require prompt notice to HHS, and those involving more than 500 residents of a state require notice to prominent media there.

Some records carry extra restrictions. Records from federally assisted substance use disorder programs are governed by 42 CFR Part 2 as well as HIPAA, and a log from a behavioral health application can contain them without anyone noticing. State laws on HIV status, mental health or reproductive health can raise similar issues. Organizations should ask counsel how those laws treat a disclosure to a vendor for support.

Fewer health systems have checked whether the vendor’s support platform, often a separate commercial case management service, falls within that agreement’s safeguards, or whether the vendor treats it as a subcontractor. The distinction sounds technical, but it decides whether patient data sitting in a support ticket is covered by the same promises as patient data sitting in the product.

Under the subcontractor rule, a commercial case management platform that stores attachments containing protected health information is generally a business associate of the vendor. The vendor should have its own agreement with that platform. The health system has no direct contract with the platform, and often no visibility of where it stores data or how long it keeps it. The questions therefore have to be put to the vendor, in writing, with the answers kept alongside the agreement.

Every vendor review should establish three things: whether the business associate agreement covers the support system and any third-party platform it runs on; whether the vendor notifies the customer of a breach of the support system, as well as of its product; and whether the health system can get a list of the PHI-bearing attachments it has uploaded, so that a privacy officer can assess notification obligations with counsel quickly.

Internally, the simplest control is to steer PHI away from uploads altogether. Offer redaction tools that blank out names and record numbers. Prefer live screen-sharing sessions where the vendor sees but does not keep the data. And require privacy office approval for any extract containing patient records.

Screen sharing has its own fine print. Many support tools record sessions by default, and a recording of an EHR screen is a file of patient data held by the vendor, as surely as an uploaded extract. Remote-control features can also let a vendor agent act inside a clinical system. Staff should know how to share a single window rather than a whole desktop. The vendor review should establish whether sessions are recorded and how long recordings are kept.

A file kept inside the health system cannot be exposed by a breach of a vendor’s support system.

When the vendor needs real data

The strongest objection from application teams is that some defects cannot be reproduced without real records. A billing rule that misfires on one payer’s claims, or an interface that rejects one particular message, may depend on details that synthetic data lacks. Banning real data outright pushes staff to send it anyway through informal channels, which is worse.

HIPAA offers two routes to de-identification: removing a defined list of 18 identifiers under the safe harbor method, or a qualified expert’s determination that the risk of re-identification is very small. Either takes effort, but a de-identified test extract can often be reused across many cases. For the remainder, a short approval path through the privacy office, with a named recipient at the vendor and a deletion date, keeps real data rare and traceable rather than forbidden and hidden.

How long a stolen session stays live

A stolen token is only as valuable as its remaining lifetime. Administrative sessions that last for many hours, or refresh silently for days, make a week-old HAR file dangerous. A token that expires within the hour is worth far less to a thief than one valid all weekend.

Sessions bound to a device or network, short idle timeouts for administrative consoles, and re-authentication for sensitive actions all shrink the window. Binding a session to a device means the token only works from the computer it was issued to, so a copy used elsewhere is refused. Health systems can ask each identity and critical application vendor which of these protections exist and turn them on for privileged roles. Ending administrative sessions after a support capture is a simple habit that removes most of the risk: sign out, and the token in the file becomes worthless.

Binding sessions, and what each method costs

Session binding comes in several strengths. The simplest ties a session to the network it came from, so a token presented from a different internet provider forces a fresh sign-in. Okta added an option of this kind for administrators after the incident. It is cheap to turn on. Staff who move between hospital Wi-Fi, a home connection and a mobile hotspot will be asked to sign in more often.

Stronger methods tie the token to a cryptographic key held on the device. Standards bodies have defined ways to do this for application tokens, such as certificate-bound tokens and the proof-of-possession method known as DPoP. Browser makers have worked on the same idea for ordinary cookies. These make a copied token useless elsewhere, but they need support in both the application and the browser or device, so coverage is uneven.

Clinical and administrative sessions are different problems

Health systems have good reasons to resist short sessions everywhere. Clinicians move between shared workstations many times an hour, and badge-tap single sign-on exists so they do not retype passwords. Aggressive timeouts on clinical workflows cost care time and push staff toward workarounds. The case for short, bound sessions is strongest for administrators of identity, EHR configuration, interface engines and cloud consoles. Those accounts are few, their holders can tolerate friction, and a stolen session gives an attacker the most.

A workable split is to define a privileged tier, require phishing-resistant sign-in and short bound sessions for it, and give its members separate administrative accounts. Troubleshooting captures for that tier then come either from a test tenant or from a session revoked immediately after upload.

The artifact itself also has a lifetime. Support platforms often keep attachments for as long as the case exists, and cases are rarely purged. A configuration export sent three years ago may still hold valid service account credentials if the passwords were never rotated. Rotating a credential means changing it, so that an old copy no longer works.

Rotation is harder than it sounds for integration accounts. An interface engine’s service account may be referenced in dozens of connection definitions, and changing its password can break message flows to the EHR, laboratory and pharmacy at once. Many health systems therefore leave such passwords untouched for years. A secrets vault that holds the credential in one place, and lets connections fetch it, turns rotation from a change-window event into a routine task. Until one exists, the list of credentials that have ever left the building becomes the rotation queue.

Contracts can set retention limits for support attachments, such as deletion a set number of days after a case closes. Health systems can rotate any credential that was ever included in an artifact, and they can ask vendors for a deletion certificate when a major case closes. Taken together, short-lived sessions and short-lived attachments mean that a future support breach exposes old files without live secrets in them.

One Tuesday, three uploads

Take a mid-sized health system on an ordinary Tuesday. In the morning, an interface analyst is chasing a problem with lab results arriving late in the EHR. The vendor asks for a configuration export and a debug log, and the analyst, under pressure from the laboratory, sends both. The export contains the service account password the interface engine uses to reach the EHR. The log contains a handful of patient names and test results.

At lunchtime, an identity administrator is troubleshooting a sign-in error in the company’s identity platform. Support asks for a HAR file. The administrator records one while signed in with full administrative rights and uploads it. In the afternoon, a revenue cycle manager sends a billing vendor an extract of claims to reproduce a defect.

Nobody here did anything unusual. Each followed the vendor’s instructions to get an urgent problem solved. By the end of the day, the health system has placed an administrator’s live session, an integration password and two sets of patient data in three different companies’ support systems. Whether any of that matters depends entirely on what happens next at those vendors, which it cannot see or control.

Now run the same day with a few habits in place. The analyst sends a sanitized log and a configuration export with secrets stripped, after a quick check by security. The administrator captures the HAR file with a test account and signs out of the session afterward. The revenue cycle manager uses a screen-sharing session instead of sending the extract. All three log what they sent. If any of the vendors later reports a breach of its support system, the health system can answer within an hour what was exposed, and in most cases the answer is nothing of value.

The stakes are concrete. For an identity provider’s support system, a live administrative session can mean an attacker inside the organization’s sign-in system, the keys to everything. For PHI in a support ticket, it can mean a reportable breach, notification costs, regulatory attention and patients reading about their data in a vendor’s incident report. For credentials in an old export, it can mean an attacker reaching the EHR through an integration nobody was watching. Each risk is small per file, and much larger multiplied across thousands of cases a year.

The day a vendor calls

The value of the record shows on the day a vendor reports a support-system breach. With a log of what was sent, the first hour is a query: which cases, which files, and which of them contained secrets or patient data. The security team rotates any credential that appears, revokes sessions, and checks the identity provider’s logs for use of the affected accounts since the upload. The privacy office reviews any file that held patient data and starts the HIPAA risk assessment with counsel.

Without the record, the same work starts with an email to every department asking who has opened cases with that vendor in recent years. Answers trickle in over weeks, and credentials are rotated on suspicion. Meanwhile the notification clock runs from when the breach was known, or would have been known with reasonable diligence.

Who owns support artifacts inside a health system

Part of what makes this risk persistent is that it falls between the lines of most organization charts. Security teams think about attackers breaking in. Privacy offices think about patient data in the EHR and in business associate relationships. Vendor management thinks about contracts at signing and renewal. The service desk thinks about closing tickets quickly. Support artifacts flow through all four without being anyone’s particular concern.

The people actually sending the files are spread even more widely. In a typical health system they include interface analysts, EHR application teams, imaging specialists, pharmacy informatics staff, revenue cycle managers, identity administrators and network engineers. Some sit in IT. Many sit in clinical or financial departments and report to leaders who have never been asked about vendor support practices. Each group develops its own habits, usually shaped by whatever the vendor’s support agent asks for.

That suggests a simple division of ownership. The chief information security officer owns the procedure: what may be sent, how it is sanitized, which file types need review, and how sessions are configured. The privacy officer owns the PHI rules and the business associate questions, including whether each agreement covers the support platform. Vendor management owns the contract terms on breach notice and retention and checks them at each renewal. The service desk owns the tooling, so that sanitizing and logging what was sent are built into the ordinary way of opening a vendor case. And each department leader whose staff open vendor cases is accountable for following the procedure, with the quarterly sample of recent cases as the measure.

Evidence an auditor would ask for

The HIPAA Security Rule already requires a risk analysis covering electronic protected health information wherever it goes. Vendor support uploads are one of those places, and a risk analysis that omits them has a gap an investigator can find. The evidence that closes it is modest: the written procedure, the sanitizing tool and its configuration, the log of artifacts sent, the quarterly sample results, and vendor agreements with their support-platform clauses.

A few measures show whether the procedure works. Useful ones are the share of sampled cases with an unsanitized HAR file or log, and the number of captures made with privileged accounts. Others are the number of credentials found in artifacts and rotated, and the time taken to list everything sent to a named vendor. The last measure matters most on the bad day, and a drill can test it.

The fix needs no new committee. It needs a page of guidance, a few changes to existing tools and contract templates, and a named owner for each piece. The cost is modest. The return is that when the next vendor announces a support-system breach, as some vendor eventually will, the health system’s response is a lookup rather than an investigation.

A board or audit committee can ask a correspondingly simple question: if one of our critical vendors told us tomorrow that its support system had been breached, could we say by the end of that day what we had sent it, and whether any of it still works?

Treating vendor support as a data flow

A health system in good shape treats vendor support as a data flow, not a series of favors. There is a short, written procedure for what may be sent, built into the tools staff already use. Sanitizing tools are available and easy. Privileged captures are the exception. PHI rarely leaves, and when it does, the privacy office knows. Vendor agreements cover the support platform, require notice of support-system breaches and set retention limits. Administrative sessions are short and bound to devices. And there is a record of what went where.

The usual failures are understandable. Organizations focus on the vendor’s product and forget the vendor’s support system, which often runs on a different platform under different terms. They rely on annual training rather than a procedure in the workflow. They assume business associate agreements cover everything the vendor touches. They leave long administrative sessions at default settings because shorter ones irritate staff. They never rotate credentials that once appeared in a ticket. And they keep no record of what was shared, so that when a vendor reports a breach, the privacy officer starts from a blank page.

The case against all this

Three objections deserve an answer. The first is that a vendor’s support breach is the vendor’s failure, and the vendor should bear its consequences. Contracts can shift some cost, but HIPAA places notification duties on the covered entity, and patients hold their hospital responsible. A stolen administrator session also hurts the customer directly, whoever lost it.

The second is that friction slows urgent fixes. A lab interface that is down affects patient care within hours, and nobody wants a security review holding up the cure. The procedure can allow for this with an emergency path: send what is needed, record it, then review and rotate afterward. Speed and record-keeping can coexist.

The third is that Okta was an outlier. The record suggests otherwise. Okta’s January 2022 incident also ran through support, in that case a workstation at a third-party support contractor. Support functions hold privileged access and sensitive customer files at many vendors, and they are staffed and secured differently from the product itself. The weakness is structural, so the controls belong in routine process.

Support uploads need clean files, covered vendors and rotated secrets

• Do staff have an easy way to sanitize HAR files and logs before they upload them?
• Do administrators capture troubleshooting files with test accounts, and sign out afterward?
• Do our business associate agreements cover each vendor’s support platform, and require notice if that platform is breached?
• If a key vendor called tomorrow to report a support-system breach, could we list what we had sent it?
• Have we rotated every password and key that ever appeared in a file we sent to a vendor?

With hindsight

Okta’s late-November update, that the attacker had downloaded names and email addresses of all support system users, widened the incident and raised concern about targeted phishing of administrators. Phishing is the use of convincing fake messages to trick people into handing over credentials or approving access. A list of exactly who administers sign-in at many organizations is a valuable starting point for that.

The details of that report were less alarming than the headline. Okta said it listed every user of its customer support system, but for 99.6 percent of them only a full name and email address were recorded. It contained no credentials. Customers in Okta’s FedRAMP High and Department of Defense IL4 environments used a separate support system and were not affected. Okta noted that many support system users were administrators, and it advised watching for phishing and social engineering aimed at them and at IT help desks.

The root cause, when it emerged, was strikingly ordinary. Okta reported in early November that initial access came through a service account whose credentials had been saved to an employee’s personal browser profile on a company laptop. A convenience feature, the browser offering to remember a password, became the bridge between a personal account and a corporate system. On February 28, 2024, Okta launched what it called the Secure Identity Commitment, a long-term program with four pillars: its products, customer best practices, the wider industry and its own corporate infrastructure.

The specific fixes Okta listed make a useful checklist for any vendor. It disabled the compromised service account and blocked personal Google profiles in Chrome on company laptops. It added detection rules for the support system. For customers, it introduced an option forcing administrators to sign in again when a session is reused from a different network. It also set default Admin Console limits of a 12-hour session and a 15-minute idle timeout, rolled out to all production customers by January 2024. Each change shortened or narrowed the life of a stolen session.

The wider trend moved in the direction this episode suggested. Session token theft grew as a technique as more organizations adopted multi-factor authentication. As the front door got stronger, attackers increasingly looked for ways to steal a signed-in session rather than the password. Identity providers and browser makers expanded features for binding sessions to devices, making stolen tokens harder to reuse.

Google’s Device Bound Session Credentials work in Chrome is one example. It ties a session to a key held in the device’s secure hardware, so a copied cookie stops working when presented elsewhere. Its value depends on websites and identity providers adopting it, and older systems will lag. The 2024 intrusions into Snowflake customer accounts showed the other side of the trend. Attackers used credentials stolen by infostealer malware to reach accounts that lacked multi-factor authentication. Stolen secrets, whether passwords or tokens, remained a staple of intrusions.

For health systems, the Change Healthcare attack in 2024 showed in a much larger way how dependent providers are on a single vendor’s environment. That event dwarfed anything in Okta’s support system. UnitedHealth Group’s chief executive told Congress that the attackers had entered through a remote access portal that lacked multi-factor authentication. But it made the same point at scale: a health system’s risk extends to wherever its data and access live, including places it does not run.

Regulation moved in the same direction. In January 2025 HHS proposed the first major update to the HIPAA Security Rule in more than a decade. Among other things, it would require multi-factor authentication, an inventory of technology assets with a map of how protected data moves, and annual written verification from business associates that required safeguards are in place. A data-flow map of that kind would naturally include what leaves through vendor support channels. Whatever the final rule contains, the proposal showed where expectations were heading.

Vendor support channels remain a smaller, less visible part of that dependence, and one that health systems can largely control through what they send, what their agreements cover and how long their sessions last. Much of vendor risk is out of a health system’s hands; this piece is not. A few habits, a short procedure and some contract language turn every future support-system breach from a potential crisis into, in most cases, a non-event.