Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
Clorox alleges that Cognizant helpdesk workers repeatedly reset employee passwords and multifactor-authentication (MFA) settings without properly verifying callers, enabling an attacker to enter its network in August 2023. The company filed suit against Cognizant in California on July 22, 2025, seeking about $49 million in direct remediation damages and $380 million in total damages. Cognizant disputes responsibility, saying it provided a limited helpdesk service rather than managing Clorox’s cybersecurity. The complaint’s allegations have not been proven in court.
What Clorox says happened
Clorox’s complaint describes an identity and helpdesk compromise, not an attacker defeating encryption or breaking MFA cryptography. Its account is that a caller impersonated an employee and used the support process to obtain access in a series of resets. The alleged events began on August 11, 2023.
- An Okta password reset: Clorox alleges the caller persuaded Cognizant helpdesk personnel to reset an employee’s Okta password without adequate identity verification.
- MFA recovery changes: The complaint says the attacker then obtained a reset involving Microsoft MFA and a change to the employee’s phone number used for SMS authentication.
- A second employee targeted: Clorox alleges the process was repeated against another employee in its cybersecurity organization, helping the attacker escalate privileges and move through the network.
- Broader network access: The attackers allegedly used the compromised accounts to gain wider access. Clorox attributes the activity to a cybercriminal associated with the group commonly known as Scattered Spider.
In this alleged sequence, the attacker did not need to defeat an authentication factor if a support workflow could be persuaded to reset or replace it. That distinction matters: MFA can protect a login, but weak account-recovery procedures can provide another route to the same account.
Free tools Windows power users keep installed
One-click scans. No signup required.
Clorox says its service-desk procedures had been updated in January 2023 and alleges Cognizant failed to follow them. The complaint also alleges that Cognizant did not send required notifications to the affected employee or manager, granted further access after suspicious resets, and had represented that personnel were trained and following the procedures. Clorox further alleges shortcomings in incident response, including delays and inaccurate information during containment. These are claims in the lawsuit, not findings by a court. Read the complaint.
#1 Best Overall
Disruption and the damages claim
Clorox reportedly detected the intrusion within about three hours and disconnected or shut down multiple critical systems. The resulting disruption affected production and shipping. Reporting has put the incident’s impact near $400 million, while Clorox’s lawsuit seeks $380 million in total damages and identifies about $49 million in direct remediation damages. Those figures describe reported impact and the company’s claim; they are not a court-determined award or an independently established loss amount. Computer Weekly’s account of the lawsuit and operational impact provides further context.
What Clorox is suing for
Filed July 22, 2025, in Alameda County Superior Court against Cognizant Worldwide Limited and Cognizant Technology Solutions U.S. Corporation, the complaint asserts four causes of action:
- Breach of contract.
- Breach of the covenant of good faith and fair dealing.
- Gross negligence.
- Intentional misrepresentation.
Clorox’s theory is that the alleged conduct was not just one employee’s mistake: repeated failures to follow procedures breached contractual service obligations and contributed to substantial losses. Filing those claims does not mean a judge or jury has accepted the allegations or decided that Cognizant is liable.
Cognizant’s response and the central dispute
Cognizant rejects Clorox’s account of responsibility. It says its assignment was a narrow helpdesk-services engagement, not management of Clorox’s overall cybersecurity, and argues that Clorox’s internal security controls were inadequate. In its public response, Cognizant characterized Clorox’s internal cyber defenses as inept. Computer Weekly reported Cognizant’s position.
Rank #3
The dispute therefore involves two layers of control. Cognizant’s alleged role concerns how helpdesk agents verified callers and handled password and MFA resets. Clorox’s potential responsibilities include identity-system design, access privileges, monitoring, network segmentation, and incident response. A vendor may control the support interaction while the customer controls the identity platform; the lawsuit puts the boundary between those responsibilities in question.
The service agreement may be pivotal. Relevant issues include what services and security procedures it required, how training and audits were handled, whether the contract allocated incident-response duties, and what indemnities or damages limits apply. The effect of any liability cap—and whether it applies to claims such as gross negligence or intentional misrepresentation—cannot be determined from the damages demand alone. The complaint states Clorox’s position; the contract’s terms and later court proceedings would be needed to assess the dispute.
Why Scattered Spider and helpdesks matter
Scattered Spider is associated with social engineering that targets helpdesks and call centers, impersonates employees, exploits password and MFA recovery, and seeks access to identity-provider accounts or privileged personnel. Clorox’s complaint supplies the allegations about the reset sequence in this case; attribution to a named threat group should be treated separately and cautiously. It is more accurate to describe the incident as activity attributed to or reportedly associated with Scattered Spider than as a court-established finding about the group’s role.
The broader security point is that a service desk able to reset passwords, replace authentication factors, or restore access acts as an identity-control plane. It is part of the security boundary even if its contract describes the work as support rather than cybersecurity. A strong MFA deployment can be undermined if an attacker can persuade an authorized agent to alter the enrolled factor.
Best Value
Controls for organizations that outsource IT support
Companies can use the allegations as a prompt to review the entire account-recovery path—not just the identity provider’s login settings:
- Verify through a trusted channel: Require confirmation using a previously enrolled factor or a known, independently verified contact path. Do not treat employee IDs, manager names, or other internal facts as proof of identity.
- Separate high-risk changes: Do not let one agent reset a password and replace the MFA recovery factor in the same unreviewed interaction. Require a second approver or security escalation for privileged, finance, executive, and security-team accounts.
- Confirm and notify: Send alerts to the account owner and, when appropriate, a manager or security contact after credential or factor changes. Establish a defined path for employees who have lost their phone or cannot access their enrolled device.
- Monitor combinations and repetition: Alert security operations when password, phone-number, MFA, VPN, or recovery changes occur close together, or when an account receives repeated reset attempts. Review activity involving privileged accounts promptly.
- Limit agent authority: Apply least privilege, keep break-glass recovery controlled and monitored, and distinguish customer support duties from security-operations powers where possible.
- Keep an evidence trail: Log the caller, agent, verification method, reset type, approvals, and timestamps. Retain call recordings where appropriate and lawful, along with procedure versions, training records, ticket history, and identity-provider audit logs.
- Test the real process: Train and audit vendor staff against the customer’s actual procedures. Use authorized social-engineering exercises to see whether agents follow those procedures under pressure, across shifts and subcontractors.
- Make the contract specific: Define verification steps, escalation rules, notification duties, audit rights, incident-response cooperation, evidence retention, and responsibility for vendor and subcontractor actions. Review indemnities, liability limits, and cyber-insurance arrangements against realistic operational losses.
There are trade-offs. More verification can slow legitimate recovery, particularly for remote or traveling employees and during production emergencies. Centralizing support can make procedures consistent, but it also creates a high-value target. SMS may be easier to recover than a hardware-backed key or passkey, but phishing-resistant authentication does not eliminate the risk if a helpdesk can replace the factor without strong checks. The aim is not to make recovery impossible; it is to make exceptional recovery deliberate, independently verified, and visible to security teams.
What remains unresolved
The lawsuit was filed in 2025, and the materials available for this account establish the filing and the parties’ competing positions, not a final judgment, settlement, or allocation of responsibility. The case should therefore be read as a contested civil complaint. Evidence that could matter includes helpdesk recordings and reset logs, training and procedure records, the service contract, identity-provider audit trails, incident-response timelines, and communications between the companies. No conclusion about liability follows from the size of the claim alone.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
