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 credentials and direct-deposit instructions. According to Corteva’s Maryland AG substitute notice dated 31 March 2023, one employee’s payroll portal data was exposed. Phishing-proof MFA 2.0 hardens enrolment and recovery so a vendor helpdesk cannot re-issue transferable password access from weak knowledge-based proof alone. Once the attacker already held the changed portal password, payroll diversion sat past that gate. For the full attack chain, read the companion on legacymfa.sucks.

FAQ

Would MFA 2.0 have blocked the Corteva ADP call-center password reset?

Yes for the recovery gate that minted the new password. The Corteva ADP path succeeded because ADP’s payroll call center accepted name and date of birth, then handed the caller a portal link that enabled a password credential change. Phishing-proof MFA 2.0 removes phishable recovery factors across the identity lifecycle, so helpdesk cannot silently re-issue portal access or reset password factors from KBA alone. Public reporting does not establish any MFA step on the ADP portal, and it does not name TAP or AiTM. Closing that recovery path is prevention, not detection.

How is helpdesk KBA the same class as a coached fake login?

Helpdesk KBA and a coached fake login are the same social-engineering class against workforce identity. In both cases a live coach extracts a transferable factor: a temporary secret, a recovery answer, an OTP, a push approval, or a password the victim types. At ADP, name and DOB stood in for the real Corteva employee long enough for a password reset. MFA 2.0 stops both paths because there is no TAP, OTP, SMS code, email code, push, or recovery secret for IT to read out or for the user to type, and adding a device requires an already-enrolled device rather than a phishable enrollment code.

Do passkeys alone close this payroll recovery gap?

Not by themselves if enrollment and recovery still use phishable proof. Passkeys and WebAuthn are phishing-resistant at the login ceremony: origin-bound signatures harden authentication. They do not automatically protect helpdesk reset or new-factor onboarding when those flows still accept name, DOB, email OTP, SMS, or similar transferable proof. The Corteva ADP incident was a recovery failure first. MFA 2.0 is phishing-proof across registration, device onboarding, authorisation, authentication, and decommissioning, which is the gap beyond login-only resistance on the strength ladder: password < OTP/SMS < push < phishing-resistant < phishing-proof.

What still needs other controls after a successful payroll password reset?

After the attacker already held the changed ADP portal password, login MFA no longer undoes direct-deposit changes or exposure of that employee’s payroll portal data. According to the Maryland AG substitute notice, the affected record set for that one Corteva employee included name, address, SSN, bank information, email, and W-2 data. Prevention value sat upstream at the recovery gate. Residual work is revoke of the attacker-chosen credentials, monitoring of deposit-instruction changes, and vendor helpdesk process controls. Fooling a call center with KBA is easy relative to planting malware on an already-legitimate session; those are different problems.

What should CISOs demand for workforce payroll recovery?

CISOs should demand that payroll and HR portals treat recovery like authentication: no password or factor re-issue from name, DOB, or other knowledge answers alone, and no helpdesk path that mints a transferable secret. Require already-enrolled device proof for resets and new-device enrollment, bind vendor call-center actions to the real employee rather than KBA scripts, and treat direct-deposit changes as high-assurance events. Public reporting frames the Corteva ADP incident as vendor call-center impersonation against one employee payroll account, not as a Corteva corporate IdP or SSO breach. Harden the recovery gate first; everything after a successful password takeover is containment.