One reusable secret on a partner file-transfer login was enough to open California's statewide assessment pipeline for nearly four months. According to SecurityWeek, citing California Department of Education notices, an unauthorized party used a compromised login credential on an Educational Testing Service (ETS) SFTP site that exchanges CAASPP and ELPAC data with the state, and copied student files at various times from May 22 through September 18, 2026. Phishing-proof, device-bound authentication on that partner transfer account would have raised the bar before any session was issued if the gate depended on a password or other replayable factor. Months of bulk copy after a successful login are a different problem: monitoring, least privilege, and fast disablement, not a second prompt at the password box.
What a single ETS SFTP credential opened
According to the CDE breach notice quoted by SecurityWeek, the investigation determined that an unauthorized party used a compromised login credential at various times from May 22, 2026 to September 18, 2026 to access the SFTP site and copy files containing California student information. ETS provides CAASPP and ELPAC assessment work for California under contract with CDE. The SFTP site was the operational pipe for that exchange. Once the credential worked, each later pull looked like ordinary partner traffic: sign in, copy files, leave, return.
ETS identified the unauthorized activity on September 25, 2026, disabled the compromised account, and took the SFTP site offline. CDE notified county and district superintendents and charter administrators on October 2. Student and family notifications began October 16, 2026, and were expected to run into early November. During the response, ETS suspended some enrollment processing and testing work while it evaluated security, then stood up a replacement SFTP site with enhanced controls.
Copied material included names, Statewide Student Identifiers (SSIDs), dates of birth, addresses, demographics, disability and program participation data, and assessment results. The same reporting states the files did not contain Social Security numbers, passwords, or payment-card details. Public-school enrollment in California exceeded 5.7 million students in 2025-2026; that is scale context, not a confirmed unique-victim headcount. Some former-student records could reach back to 2006. CDE and ETS said that after working with law enforcement and cybersecurity experts, ETS took steps to reduce the risk of public accessibility. No evidence has been reported that the copied sets were posted or sold.
How the login credential was first obtained has not been publicly explained. Whether the SFTP account required any second factor is also undisclosed. Adjacent education-sector items in the same SecurityWeek coverage (Canvas platform data theft and Mount Royal University ransomware theft) are related reading only, not proven links to this intrusion.
If you want more detailed information about this attack, read the related post on legacymfa.sucks: how a compromised ETS SFTP credential exposed California student records.
Why ordinary second factors still lose on partner transfer logins
Partner file-transfer identities are workforce identities with bulk-data privileges. An SFTP account that moves statewide assessment extracts is not a low-stakes folder share. When access hangs on a login credential that can be copied, shared, emailed, or pasted into a script, theft of that secret becomes theft of the pipeline. Public notices establish only that a compromised credential worked repeatedly. They do not establish password spray, stuffing, phishing email, helpdesk reset, or insider misuse as the acquisition path, and they do not say whether any MFA sat on the account.
Many partner SFTP and managed-file-transfer accounts still authenticate with a long-lived password, a shared service account secret, or a soft second factor that another system can read out. OTP, SMS, email codes, and push approvals are transferable. Anyone who holds the secret, or who can intercept or coach the soft factor, completes the same login the legitimate automation or operator would complete. A reverse-proxy kit is not required for that failure mode. A credential that still works is enough.
Even when teams add a conventional second factor to a transfer account, the failure modes stay familiar. Shared soft tokens live in ops inboxes. Hardware tokens get left in a drawer and replaced with temporary SMS. Service accounts skip interactive MFA because scheduled jobs cannot tap a phone. None of those patterns is confirmed for this ETS account. They are the default industry posture that makes a single compromised login credential a credible explanation for four months of authenticated pulls.
After the login succeeded, copying CAASPP and ELPAC files was ordinary use of an authorized channel. No second factor un-copies bytes already taken between May and September. Detection arrived on September 25, more than four months after first unauthorized access. Partner transfer accounts often sit outside the same monitoring intensity as interactive employee cloud SSO. Quiet bulk copy can look like scheduled exchange until volume, destination, or account behavior finally trips a review.
| Gate | What public sources show | Prevention implication |
|---|---|---|
| SFTP login secret | Compromised credential worked from May through September 2026 | Remove replayable secrets at sign-in |
| Second factor on account | Not disclosed | Do not assume MFA existed |
| Post-login file copy | Repeated authenticated pulls | MFA does not undo authorized sessions |
| Discovery | Sept 25 after months of access | Monitor partner transfer volume |
What device-bound MFA changes on file-transfer accounts
Device-bound, origin-aware authentication changes the partner login gate, not the physics of a session that already exists. Private keys stay on enrolled hardware. The server stores public keys only. There is no central password database for that factor and no OTP seed worth stealing. A signature is demanded fresh for the real transfer service. A copied password string, a pasted shared secret, or a code read from another channel does not complete that ceremony.
If the ETS SFTP account depended on a password or other replayable factor, moving that workforce and partner login to phishing-proof device-bound credentials would have blocked the unauthorized party from obtaining a fresh authenticated transfer session with the stolen secret alone. That is prevention, not detection: the bulk copy path never starts because the login never finishes. Official disclosures do not prove the account was password-only; that conclusion remains conditional on the factor model sources leave open.
What stronger sign-in does not do is rewind May through September. Once a legitimate-looking SFTP session is open, file listing and download are application-layer work. Revoke the account, take the site offline, rotate secrets, rebuild the transfer service with tighter controls. ETS did versions of that after September 25. Those steps contain damage. They do not replace removing the replayable login surface that made quiet re-entry cheap for months.
Malware on an already-signed-in operator workstation is a harder, different path. Nothing in the CDE or SecurityWeek reporting describes endpoint malware or session-token theft from memory for this incident. The documented story is a compromised login credential presented to an SFTP service. Closing transferable factors on partner transfer accounts addresses that documented class. Endpoint compromise after a clean login still needs host controls, egress inspection, and least-privilege share design.
Secure automation still fits. Scheduled jobs can hold device-bound credentials on locked-down transfer hosts instead of shared passwords in config files. Human break-glass paths should demand an already-enrolled device, not a helpdesk-readable temporary code. The operational goal is simple: a partner pipeline that moves millions of student records should not open because one secret still worked.
Passkeys and FIDO2 on transfer-style logins
Passkeys and FIDO2 put a key pair on the enrollee's device. The private key never leaves hardware. The identity provider receives only a public key and verifies origin-bound signatures at authentication. Industry language correctly calls that phishing-resistant at the login act: a fake host cannot obtain a reusable secret to replay elsewhere. On a generic enterprise IdP that issues only hardware-bound signatures for partner operators, a stolen password file no longer equals a live SFTP session. That hardens the moment of sign-in. It is not yet a full-lifecycle guarantee if recovery still ships a soft code.
Closing the partner enrollment gap
FIDO2 and passkeys are phishing-resistant at login. Enrollment, device replacement, and recovery can still reintroduce email OTP, SMS, or a helpdesk-issued temporary secret unless policy forbids it. MFA 2.0 is phishing-proof because no phishable factor appears at registration, device onboarding, authorisation, authentication, or decommissioning. Sources on the ETS incident do not describe how the SFTP credential was issued or reset. Partner transfer programs still commonly mint shared passwords through ticket queues. Tight enrolment that requires an already-enrolled device before any new transfer identity becomes active is what keeps a resistant login from being undone by a soft recovery path.
Key Takeaways for Defenders
- Inventory every SFTP, MFT, and vendor drop-box account that can pull or push student, HR, or assessment bulk files, and treat those logins as privileged workforce identities.
- Replace shared or long-lived transfer passwords with device-bound credentials on locked-down transfer hosts; ban SMS, email OTP, and inbox-shared tokens for those accounts.
- Require an already-enrolled device for any new partner transfer identity or recovery path; do not issue transferable temporary secrets for bulk-data pipes.
- Alert on partner-account volume, unusual source IPs, and off-hours bulk download, and set disablement playbooks measured in minutes, not months.
- Minimize fields in exchange files and split high-sensitivity extracts so one compromised transfer login cannot empty multi-year statewide sets.
Education assessment vendors and state agencies share dense longitudinal records, long retention, and operational accounts that must run on a schedule. Those accounts rarely receive the same ceremony as an employee interactive cloud login, yet they often expose more PII per connection. The ETS California case is what that design looks like when one credential still works and copy traffic goes unnoticed until late September. Close the replayable login first. Then instrument the pipe so the next quiet summer never lasts four months.
FAQ
Would phishing-proof MFA have stopped the ETS SFTP intrusion?
Phishing-proof, device-bound MFA would have stopped the ETS SFTP intrusion at sign-in if the compromised account relied on a password or other replayable factor, because a stolen secret alone cannot complete a hardware-bound signature ceremony. According to CDE notices reported by SecurityWeek, an unauthorized party used a compromised login credential to access the ETS SFTP site from May 22 to September 18, 2026. Public sources do not state how the credential was obtained or whether any MFA already protected the account. Prevention conclusions therefore rest on removing transferable factors rather than on a documented bypass of a named second factor.
Why can't stronger MFA undo the California student file copies?
Stronger MFA cannot undo the California student file copies because those pulls happened after successful authentication to the ETS SFTP channel. Once the compromised credential produced an authorized session, listing and downloading CAASPP and ELPAC-related files was ordinary use of that session. Login controls prevent the next sign-in. They do not erase bytes already transferred between May and September 2026. Containment still needs account disablement, site takedown, monitoring, and least-privilege share design, which ETS began after discovering the activity on September 25, 2026.
How should partner SFTP accounts be enrolled after the ETS breach?
Partner SFTP accounts after the ETS breach should be enrolled only onto device-bound credentials on controlled transfer hosts, with no email OTP, SMS, or helpdesk-readable temporary secret in the path. The ETS incident does not publish the original enrollment or reset process for the compromised credential. Programs that still mint shared passwords through tickets recreate the same replayable surface. Require an already-enrolled device before activating any new bulk-transfer identity, and retire shared service-account passwords for statewide assessment pipelines.
Are passkeys enough to protect education file-transfer logins?
Passkeys are phishing-resistant at the login act for education file-transfer operators, but they are not automatically enough if enrollment or recovery still uses phishable factors. Passkeys bind signatures to the real origin and keep private keys on device, which blocks simple password replay against a partner SFTP or MFT portal fronted by a modern IdP. Full phishing-proof coverage also removes soft factors from registration, device onboarding, and recovery so an attacker cannot enroll a new device with a coached code and then look legitimate forever.
What monitoring still matters if partner logins become device-bound?
Monitoring still matters after partner logins become device-bound because post-login bulk copy, mis-issued shares, and endpoint compromise on an already-authenticated transfer host remain outside the login ceremony. In the ETS California student records incident, unauthorized access continued for months before discovery on September 25, 2026. Device-bound sign-in shrinks credential replay. Volume anomalies, destination checks, short-lived access windows, and rapid disablement shrink the damage if something still goes wrong after a session exists.
