Cloudflare’s response to the Okta support breach

On March 22, 2022 at 03:30 UTC, Cloudflare learned of a compromise affecting Okta, the identity provider used internally for employee authentication. After a full investigation, Cloudflare found no evidence that its own systems were breached as a result. Okta is not used for customer accounts, and Cloudflare customers do not need to take action unless they themselves use Okta.

What happened

During January 2022, attackers outside Okta gained access to an Okta support employee’s account and could perform actions as that employee. A screenshot shared on social media revealed a Cloudflare employee’s email address and a popup indicating the attacker, posing as an Okta employee, could have initiated a password reset.

Cloudflare’s Security Incident Response Team (SIRT) first learned of the issue when an employee emailed a link to a tweet at 03:30 UTC. Several other employees flagged the issue to SIRT over the next two hours.

Investigation timeline

Cloudflare’s response was rapid. Key steps included:

  • 03:38 UTC: SIRT identified Cloudflare information (logo, user data) in the tweets.
  • 03:41 UTC: An incident room was opened and key personnel assembled.
  • 03:50 UTC: No relevant audit log events, such as password changes, were found for the employee in the screenshot.
  • 04:13 UTC: Cloudflare contacted Okta directly for detailed information.
  • 04:23 UTC: All Okta logs ingested into Cloudflare’s Security Information and Event Management (SIEM) system were reviewed for suspicious activity spanning the previous three months.
  • 05:03 UTC: The account of the Cloudflare employee whose email appeared in the screenshots was suspended.
  • 05:06 UTC: Access logs, covering IPs, locations and multifactor methods, were reviewed for affected users.
  • 05:38 UTC: Cloudflare publicly acknowledged the issue.
  • 05:44 UTC: A list of all users who changed their passwords in the previous three months was compiled, and all accounts were forced through a password reset.
  • 07:57 UTC: Okta confirmed there were no relevant events in its support console indicating malicious activity for Cloudflare instances.

Because the compromised Okta support employee had the ability to force password resets on customer accounts, Cloudflare reviewed every employee who reset a password or modified multi-factor authentication (MFA) since December 1, 2021. That list included 144 employees. All were forced to reset passwords and were notified of the change.

How Okta is used at Cloudflare

Okta serves as Cloudflare’s internal identity provider, integrated with Cloudflare Access to protect internal resources. This setup adds layers of defense beyond a standard password reset. An attacker would also need to change the hardware (FIDO) token tied to the same user account, making compromised accounts relatively easy to spot by reviewing their hardware keys.

Cloudflare also stores Okta logs in its own systems, not just in the Okta console. This provides longer log retention than the 90 days available in the Okta dashboard and ensures a compromise of Okta’s platform could not alter evidence already collected. Okta does not handle customer authentication, and no customer data is stored in it.

Specific actions taken

  1. Cloudflare reached out to Okta to gather all known attack details.
  2. The one Cloudflare account visible in the attacker’s screenshots was suspended.
  3. Okta System logs were searched for signs of compromise, including user.account.reset_password, user.mfa.factor.update, system.mfa.factor.deactivate, user.mfa.attempt_bypass and user.session.impersonation.initiate. Cloudflare reads these logs every five minutes and stores them in its SIEM. Okta’s communications had not yet made clear what System Log Actor would be expected from a compromised Okta support employee.
  4. Google Workplace email logs were checked to confirm password resets. This separate source was used because Okta had itself been breached and the reliability of its logging was uncertain.
  5. Every Cloudflare employee account that changed a password in the last three months was required to reset again. As part of recovery, each user joined a video call with the IT team to verify identity before the account was re-enabled.

Advice for Okta customers

Organizations using Okta should contact the company for detailed information and consider the following steps:

  • Enable MFA for all accounts. Passwords alone are insufficient; hardware keys are strongly preferred because other MFA methods can be phished.
  • Review all password and MFA changes across Okta instances, with particular attention to support-initiated events. Treat password resets as suspect and force new ones if there is any doubt. If suspicious MFA events appear, confirm only valid keys remain on affected accounts.
  • Maintain additional security layers so that a single failure does not expose the environment.

Cloudflare’s security and IT teams continue to work with Okta on this incident. If further information indicates compromise outside the January timeline, Cloudflare has said it will publish additional details.