Would MFA stop PowerSchool PowerSource login?

Would multi-factor authentication have stopped the PowerSchool PowerSource support-portal breach? In December 2024, attackers signed into PowerSchool's PowerSource customer support portal with a compromised technical-support subcontractor maintenance password on an account that had no MFA, then used legitimate remote-support tooling to export student and teacher data from customer SIS instances. According to TechCrunch, PowerSchool spokesperson Beth Keebler confirmed that subcontractor account was not protected with MFA. Phishing-proof, device-bound MFA on that workforce support login would have blocked password-only sign-in. Once a valid support session existed, login MFA could not undo authorized export tooling. For the full attack-chain narrative, read the companion on legacymfa.sucks.

FAQ

Would MFA have stopped the PowerSchool PowerSource breach?

Yes for the credential-phase PowerSource portal login, and no for the post-authentication data export. The PowerSchool PowerSource breach began because a technical-support subcontractor maintenance account had no multi-factor authentication, so a stolen password was enough to sign in. Keebler told TechCrunch the subcontractor's account used to breach the customer support portal was not protected with MFA. Requiring phishing-proof device-bound MFA on that support-portal account would have blocked sign-in with only the stolen password. After authentication, attackers used legitimate maintenance remote-support tooling to export Students and Teachers table data. No login MFA undoes that session-stage use of authorized tooling. Public reporting does not establish how the maintenance credential was first obtained. Separate TechCrunch reporting on LummaC2 password theft from a PowerSchool engineer endpoint is not established as this portal path.

What MFA actually blocks a PowerSource-style support password login?

Any enforced second factor would have raised the bar above a bare password on PowerSchool's PowerSource portal. Legacy OTP, SMS, and push still leave transferable factors that can be coached or relayed if attackers later target those channels. Phishing-proof MFA 2.0 uses device-bound public-key credentials with no OTP, SMS code, push approval, or recovery secret to type or read out, so a stolen password alone never completes sign-in. The prevention-focused design removes that credential attack surface at login rather than detecting misuse after the fact. PowerSchool later said it rolled out MFA on the affected portal path and ran a full password reset for PowerSource customer support portal accounts.

Why doesn't login MFA stop SIS data export after PowerSource access?

Because the PowerSchool PowerSource data export happened after a valid support session already existed. Attackers used maintenance remote-support tooling the portal already authorized for that account. Login MFA only gates authentication. Once the session is live, stopping export is portal authorization, session controls, tooling least privilege, and monitoring work. Closing the password-only login stops this path from opening. CrowdStrike's initial analysis, as described by PowerSchool, found no malware, virus, backdoor, or system-layer access on this portal path, so the residual problem here is privileged tooling after a clean credential login, not in-memory token theft from malware.

Are passkeys enough for workforce support portals like PowerSource?

Passkeys are phishing-resistant at the login ceremony, which would already beat a password-only PowerSchool PowerSource account. Full phishing-proof coverage still matters for support and contractor identities because enrollment, device onboarding, and recovery can reintroduce phishable factors unless the deployment forbids them. MFA 2.0 keeps device-bound proof across those lifecycle stages so a compromised password cannot stand in for an enrolled device. For high-privilege support portals that reach customer SIS data, that lifecycle gap is where resistant login alone can still fail later. The enrolment model is where that gap closes or reopens.

What should CISOs change after PowerSchool PowerSource?

Treat every third-party and subcontractor maintenance account on a support portal as a privileged workforce identity, not a shared-password niche. Enforce phishing-proof, device-bound MFA before any PowerSource-class remote-support session can open. Pair that with least-privilege tooling so a single support login cannot bulk-export Students and Teachers tables across districts. PowerSchool stated employees and contractors already use SSO and MFA elsewhere and that internal systems including Slack and AWS are MFA-protected; the gap that mattered was the PowerSource support account without MFA. Password reset after the fact is hygiene. Prevention is requiring a hardware-bound signature that a stolen maintenance password cannot satisfy.