Okta's support system leaked a report, not a password

The workload

Choosing an identity vendor pushes a category of risk onto that vendor's own support infrastructure, not just its authentication servers, and the workload a founder inherits shows up only when something goes wrong there. Okta, an identity provider smaller SaaS teams may use for single sign-on, disclosed on 20 October 2023 that an intruder had used a stolen credential to access its support case management system. Okta's own original disclosure, published that date, states this as verified vendor fact: the intruder "was able to view files uploaded by certain Okta customers as part of recent support cases," specifically HAR files uploaded for troubleshooting.

What the documents show

The verified risk named in the original disclosure is specific: "HAR files can also contain sensitive data, including cookies and session tokens, that malicious actors can use to impersonate valid users." Okta's notice separates this from its production service, which it states "is fully operational and has not been impacted." A second Okta document, its 29 November 2023 update and recommended-actions notice, adds a more specific, separately verified fact: the intruder "ran and downloaded a report that contained the names and email addresses of all Okta customer support system users" on 28 September 2023 at 15:06 UTC, a report Okta states had most fields blank and no credentials or sensitive personal data. Together the documents describe two related but distinct actions inside one intrusion, viewing HAR files and separately downloading a contact report, not one fully specified event.

The operating cost

Neither document states a dollar figure Okta paid or charged customers; the operating cost landing on a founder is the labour of Okta's own recommended remediation. The November update's verified list includes enabling multi-factor authentication for administrators, enrolling users in "phishing resistant authenticators (such as Okta Verify FastPass, FIDO2 WebAuthn, or PIV/CAC Smart Cards)," binding admin sessions to new-IP re-authentication, session timeouts, and phishing-awareness training, each an hours-of-configuration task, not a line item Okta prices. Assigning an hourly rate to that labour would be an estimate this entry does not make.

The stop condition

Okta's documents name a scope boundary rather than a stop condition: all Workforce Identity Cloud and Customer Identity Solution customers were affected, "excluding those in FedRamp High and DoD IL4 environments," and the incident was treated as closed once the November notice's controls were applied. Editorially, since neither document states how many customers' data was actually misused, the stop condition for the remediation workload is the point at which every recommended control has been verified applied, not merely recommended.

• Were any support cases this app's account raised with its own identity vendor accompanied by an uploaded HAR file?
• Are admin sessions on the auth vendor's dashboard bound to re-authenticate from new IP addresses, per Okta's own recommendation?
• Does the vendor's own incident-disclosure history show a pattern, or a single event?

The two Okta notices establish what the vendor itself says happened and recommended, dated 20 October and 29 November 2023; no figure for customers whose data was actually misused appears in either document, and none is asserted here.