Corteva ADP call-center DOB reset diverted payroll

On 1 March 2023 a third party called ADP’s payroll call center, impersonated a Corteva Agriscience employee with name and date of birth, obtained a portal link, and changed that employee’s password and direct-deposit instructions. According to Corteva’s Maryland AG substitute notice dated 31 March 2023, one employee’s payroll portal data was exposed: name, address, SSN, bank details, email, and W-2 information. Public reporting does not name a threat actor, TAP, AiTM, or any MFA step on the portal.

If you want the prevention angle on hardening payroll recovery and helpdesk proofing, read the related article on mfa2point0.com.

FAQ

How did the Corteva ADP payroll diversion start?

The Corteva ADP payroll diversion started when a third party called ADP’s payroll call center on 1 March 2023 and impersonated a Corteva employee. The caller used the employee’s name and date of birth as identity proof, obtained a portal link from the call center, then changed password credentials on the employee payroll portal and rewrote direct-deposit instructions. Corteva’s Maryland AG substitute notice of 31 March 2023 documents that vendor call-center social engineering path. Public reporting does not establish malware on a Corteva endpoint or a corporate SSO compromise.

What proof did ADP’s call center accept before the password change?

ADP’s call center accepted knowledge-based proof: the Corteva employee’s name and date of birth. That was enough for the caller to receive a portal link and complete a password credential change on the payroll account. Public reporting does not establish a stronger employee-held factor, a live callback to a verified number on file, or any hardware-bound recovery step. Weak KBA at a vendor helpdesk is the same social-engineering class as coaching someone through a fake login: a transferable secret or knowledge answer stands in for the real person.

Did MFA fail on the Corteva ADP portal?

Public reporting does not establish that the ADP payroll portal required MFA, and the notice does not describe any MFA step. What failed first was recovery identity proofing at the call center. Name and DOB let a stranger obtain a portal link and set a new password. After that reset, the attacker held attacker-chosen credentials to the account. Login MFA, if it had existed, would not undo a password the helpdesk already handed over through weak recovery. The prevention value sat in the recovery gate, not in a later prompt.

What data was exposed in the Corteva ADP incident?

According to the Maryland AG substitute notice, one Corteva employee’s payroll portal data was affected: name, address, Social Security number, bank information, email address, and W-2 information. The operational hit was direct-deposit diversion after the password change. Public reporting does not establish a multi-employee blast radius, a ransom demand, or theft beyond that single payroll-portal account.

Was this a Corteva corporate IdP breach?

No. Public reporting frames the Corteva ADP incident as vendor call-center impersonation against an employee payroll portal account, not as a compromise of Corteva’s corporate identity provider, federation, or Microsoft 365 tenant. The attacker socially engineered ADP’s payroll support path with name and DOB, then controlled that one portal login after the password reset. A fix for this recovery class exists; the companion prevention piece covers how workforce recovery should bind to the real employee instead of call-center KBA alone.