From late 2023, Okta mandated a short list of security controls for all critical software-as-a-service (SaaS) providers used to support our operations.
These controls proved essential in insulating Okta and our customers from the compromise of Salesloft Drift in August 2025, and have since insulated Okta and our customers from the more recent compromise of customer success management software provider, Gainsight.
I have written this blog post to both reassure customers about the security of their interactions with Okta, but also to guide all CISOs on the work that needs to be done to limit the blast radius of future SaaS supply chain attacks.
August 2025: the Salesloft Drift attack
In August 2025, the critical business applications of 700+ entities were compromised by threat actors [pdf] who stole and replayed access tokens from AI-powered chatbot provider, Salesloft Drift.
The attack proved that in a highly-interconnected technology environment, the compromise of any given supplier can lead to data breaches at even the most capable and well-defended entities.
Okta used the Drift application, but was not one of the impacted entities. While the threat actors accessed and attempted to replay access tokens used to connect the Drift application to Okta’s CRM environment, these attempts were unsuccessful because of the controls detailed below.
October 2025: the Gainsight attack
From late October 2025, threat actors compromised Gainsight, another popular SaaS application, and abused this access to steal and replay valid tokens for an undisclosed number of Salesforce organizations (tenants).
Just as with Salesloft Drift, Okta is a Gainsight customer. The Gainsight application uses OAuth tokens to connect to Okta Salesforce instances.
And again, Okta was not impacted by this incident.
Okta’s critical SaaS controls
Okta’s Security Architecture team defines a set of threat-informed standards and configuration practices that all SaaS providers used to support our operations are expected to meet. These expectations vary according to the sensitivity of the systems or data involved, with certain baseline requirements applicable across all environments.
While many technology providers have adopted these essential measures, some regrettably have not. We continue to apply pressure to ensure they deliver the security capabilities we consider fundamental in the modern SaaS era.
A subset of those requirements relate to identity and access management and are especially relevant to the two supply chain attacks in question:
Strong authentication (via SSO): Okta requires apps to support centralized identity federation and authentication using single sign-on.
Strong identity governance (via SCIM): Okta requires apps to support automated access provisioning, deprovisioning, and entitlement management.
Interactive session security: Okta requires apps to support allowlisting by IP for interactive user access.
Non-interactive session security: Okta requires apps to support allowlisting by IP and client for non-interactive (machine-to-machine) access, including API access.
Strong audibility: Okta requires apps to support specified logging and alerting for real-time detection and other monitoring.
Strong authentication
While the threat actors taking credit for these software supply-chain attacks use a variety of methods for initial access to their targets, one routine form of abuse is the replay of passwords of accounts stolen using infostealer malware.
In 2024, these attackers replayed passwords unearthed in infostealer dumps against the tenants of dozens of Snowflake customers. In many, if not most cases, access to these Snowflake accounts did not require multifactor authentication (MFA), as the accounts in question were either not federated to an identity provider or could be accessed directly via a non-SSO endpoint.
That’s why it’s critical that SaaS providers support identity federation standards (SSO) and that customer security teams are empowered with the tools to discover and remediate non-federated accounts.
Single-sign on is one of the primary controls included in IPSIE, the Interoperability Profiling for Secure Identity in the Enterprise. Think of IPSIE as the blueprint for the core security features apps need to support to cut it in the enterprise.
Strong identity governance
Very often, the non-federated accounts abused in attacks derived from infostealer infections or credential stuffing were for partially offboarded users or were the ghosts of past service accounts. These accounts often lack a clear owner and were less frequently subject to strong password policies, MFA, and other authentication requirements.
It’s for this reason that automated account provisioning and deprovisioning is so critical to security. SCIM-based provisioning ensures that all accounts used to access SaaS applications are up to date and protected.
SCIM provisioning is also one of the controls included in IPSIE.
Interactive session security
In the vast majority of account takeover events studied by Okta Threat Intelligence, adversaries replay stolen credentials from network locations and services that would be atypical for the valid user of the compromised identity.
It’s for this reason that user access to sensitive business applications should be constrained to trusted networks.
User access to applications can be constrained at the identity provider (using Network Zones in Okta, for example, or Tenant Access Control Lists in Auth0). However, access controls implemented at the identity provider do not constrain any residual direct, non-federated access to the SaaS application. Attackers rarely take the sanctioned path to a targeted application, they take the path of least resistance.
On this basis, SaaS applications must also support IP allowlisting for direct sign-in events. Administrators should be able to constrain direct access to a SaaS application to a set of trusted IPs.
At Okta, for example, we limit interactive access to Salesforce and other critical applications to a set of private IP exit nodes associated with the corporate VPN used by Okta personnel.
Non-interactive session security
The same “defense-in-depth” principles above apply to machine-to-machine access.
In today’s threat environment, we need to assume that access keys and tokens — or any secret for that matter — could be discovered by attackers. So we need to design systems and processes that assume secrets will be compromised. In other words, we need to apply “zero trust” thinking to machine access.
A key or a token should only be able to be used in a specific, known context.
This shouldn’t be as hard as it sounds. Unlike a user, a client presenting access tokens to a resource server/API will typically connect from a relatively fixed IP range.
To allowlist a set of trusted locations for this access:
The client application that’s requesting access must declare a network range used for access (it’s a credit to both applications that declared IP ranges were available from both Salesloft Drift and from Gainsight in advance of these attacks).
The requested server application should support restricting API access by IP address. Salesforce provides this capability for connected applications, as detailed in its documentation here.
Administrators can also choose to constrain the use of valid tokens to the client the tokens were issued to. This way, an attacker that extracts valid tokens from a supplier (as is the case during attacks on Salesloft Drift and Gainsight) is not able to replay those tokens from an attacker-controlled device.
There are numerous mechanisms available for constraining a token to any given client. Mutual TLS (mTLS) uses public key infrastructure to mutually authenticate client and server.
The Demonstrating Proof of Possession (DPoP) extension to OAuth also cryptographically binds a token to the client that requested it from an authorization server.
Controls like these make attacks more expensive. In a scenario where an attacker has a “target-rich environment” to work with — such as unauthorized access to tokens for 700+ or 200+ organizations at a time — these controls buy time for resource-starved defenders and create compelling detection opportunities.
Strong auditability
All SaaS applications that target the enterprise market need to support logging and monitoring requirements.
Returning to the machine-to-machine context: when the network and location context of a machine integration is relatively stable, it’s far more straightforward to detect anomalous access. So in many respects, strong auditability is a product of the previous four controls and is difficult to achieve without them.
An effective response to a software supply-chain attack also requires an ability for customers of a compromised software partner to very quickly understand whether they are impacted, and the extent of that impact.
At a minimum, SaaS providers need to provide:
Programmatic access to security and activity logs
Comprehensive context for every log event
Support for the Shared Signals Framework, as defined in the OpenID IPSIE profile
In summary
I urge all participants in the ecosystem — both application providers and their customers — to embrace these controls as a minimum set of hygiene requirements.
Our job at Okta is to make these simple and meaningful controls as easy as possible for our customers to implement. Both Auth0 and Okta provide broad support for single sign-on, the automated provisioning and deprovisioning of accounts, discovery of local (non-SSO) accounts, and the ability for application builders to constrain the use of tokens by IP and by client.
Consider us your partners in getting this important work done.
