PowerSchool: one login without MFA, 6,505 school districts exposed
A 19-year-old college student used a single stolen support-portal credential to reach the student records of tens of millions of children. PowerSchool paid to keep the data from leaking. The courts took it from there — and handed down four years, not the seven prosecutors asked for.
Background
PowerSchool runs the student information system that thousands of US school districts use to store grades, schedules, health notes and family contact details — the administrative backbone most parents never think about until something goes wrong with it. In December 2024, something went wrong with it: a single compromised credential at a contractor, used against a support portal with no multi-factor authentication, reached into the records of millions of children.
From one unprotected login to 6,505 districts
What actually happened
The entry point was ordinary: a credential belonging to a PowerSchool contractor, used to log into PowerSource, the company's own customer support portal. That account was one of the few at PowerSchool that didn't require multi-factor authentication — most of the company's systems did. Unauthorized activity began December 19, 2024; PowerSchool discovered it nine days later, on December 28, and disclosed publicly on January 7, 2025.
Once inside, the attacker didn't need to break into each district's system separately. PowerSource includes a tool built for PowerSchool's own support engineers — called Maintenance Access — that can pull data directly out of any customer's student information system. That tool is exactly what turned one stolen credential into a breach measured in thousands of districts rather than one.
The scope, as reported, reached 6,505 school districts, with figures cited around 62 million student and 9.5 million teacher records — though PowerSchool itself has not formally confirmed those exact totals. What was exposed varied by district, but could include names, addresses, phone numbers, Social Security numbers, GPAs, health notes and parent contact information. PowerSchool says fewer than a quarter of affected students had a Social Security number in the exposed data — meaning more than three in four did not.
PowerSchool confirmed paying a ransom to keep the stolen data from being published, without disclosing the amount. An independent audit by CrowdStrike, commissioned afterward, concluded the company had "failed to take basic precautions" to protect it.
Root cause
- A single contractor credential without multi-factor authentication was used to log into PowerSource, PowerSchool's own customer support portal, on December 19, 2024.
- Once inside, the attacker used Maintenance Access, an internal data-export tool built for PowerSchool's own support engineers, to pull records directly from customer districts' systems — this is what turned one compromised login into a breach measured in thousands of districts rather than one.
- PowerSchool paid an undisclosed ransom to prevent the stolen data from being published.
- An independent audit commissioned after the breach, performed by CrowdStrike, concluded PowerSchool had failed to take basic precautions to protect the data.
- Exactly how the contractor credential was first obtained isn't fully settled across public reporting on this incident: one account frames it as a stolen or reused login, while a separate report describes malware harvesting internal PowerSchool passwords from a compromised engineer's computer. These may describe the same underlying event from different angles, but PowerSchool's own disclosures don't resolve which account is accurate, and this case study doesn't pick one.
- Whether the unexplained access to the same portal using the same credentials between August 16 and September 17, 2024 was performed by the same attacker, a different party testing a stolen credential, or something unrelated has never been established. CrowdStrike found no evidence linking it to the later breach, but that is not the same as ruling it out.
Timeline
Detection
PowerSchool identified the unauthorized access itself on December 28, 2024, nine days after it began on December 19 — though the sources reviewed for this case study don't specify what internal signal actually surfaced it (an alert, a manual review, or the attacker's own extortion contact). PowerSchool disclosed publicly on January 7, 2025.
Nine days from first unauthorized access (Dec 19) to internal discovery (Dec 28), and about ten more days to public disclosure (Jan 7, 2025) — a reasonably tight window by industry comparison, per the case study's own control analysis.
- A separate set of logins to the same PowerSource support portal, using the same compromised credentials, occurred between August 16 and September 17, 2024 — months before the breach that was actually disclosed — and was apparently never investigated until after the real incident made it relevant.
- The compromised account was one of the few at PowerSchool exempt from multi-factor authentication, a standing exception that existed before the breach rather than something the attacker created.
What to monitor for in your own environment
A login to an MFA-exempt administrative or support-portal account, especially from a contractor credential
Identity/SSO authentication logs, filtered specifically for MFA-exempt accountsUse of an internal multi-customer data-export tool (like Maintenance Access) against an unusually large number of distinct customer or tenant records in a short window
Internal support-tool usage and audit logsA login to a sensitive support portal outside the expected contractor's normal working pattern or geography
Support-portal access logs cross-referenced with contractor work schedulesContainment, eradication & recovery
Containment
Dec 28, 2024 – Jan 7, 2025- Identified the unauthorized access on December 28, 2024, nine days after it began.
- Disclosed the breach publicly on January 7, 2025 and began notifying affected districts.
Eradication
Not itemized in public disclosure- PowerSchool's own disclosure, as reviewed for this case study, does not itemize specific technical eradication steps (credential revocation, MFA rollout on the exempt account, restriction of Maintenance Access). This case study does not assume what was done rather than report it as undisclosed.
Recovery
Dec 2024 – Oct 2025- Paid an undisclosed ransom to prevent the stolen data from being published.
- Commissioned an independent audit by CrowdStrike, which concluded PowerSchool had failed to take basic precautions to protect the data.
- Notified affected districts and families individually, disclosing that login credentials and payment data were not taken and that fewer than a quarter of affected students had an exposed Social Security number.
Security control analysis
PowerSchool enforced MFA almost everywhere except this one support-portal account — and that was the exact account used to start the breach.
Maintenance Access could reach any customer's data from a single compromised login. A tool with that much multiplying reach needs far tighter gating than ordinary support access.
A separate access window using the same credentials, months before the breach, was apparently never investigated until after the real incident made it relevant.
Nine days from first unauthorized access to internal discovery, and roughly ten more to public disclosure — a reasonably tight window by industry comparison.
PowerSchool could confirm credentials and payment data weren't taken and that most affected students had no exposed SSN, but has not formally confirmed the widely reported headline totals (6,505 districts, about 62M students) itself.
Paying to prevent publication addressed one specific risk, but didn't substitute for public disclosure, district notification, or the independent audit that followed and found real gaps.
Controls that would have prevented or limited this
Would have blocked the entire breach at its starting point — the compromised login was one of the few PowerSchool accounts not covered by MFA.
Would have prevented one compromised login from being able to export data across thousands of districts at once.
Would have surfaced and investigated the August–September 2024 access window months before the actual breach, rather than only connecting it afterward.
Blast radius
What was exposed
- Student and staff records across 6,505 school districts — names, addresses, GPAs, health notes, parent contacts
- Social Security numbers for a minority of affected students
- An unexplained earlier access window to the same portal, months before the breach, never fully accounted for
What PowerSchool says held
- No login credentials or passwords taken, per PowerSchool's own disclosure
- No evidence of banking or payment card data exposure
- More than three-quarters of affected students had no Social Security number in the exposed data
What prosecutors asked for, and what the court gave
What they got right
PowerSchool disclosed publicly within about ten days of discovering the breach, notifying affected districts rather than sitting on the news while deciding how to frame it.
Federal investigators built a case strong enough to secure a guilty plea rather than a contested trial, and tied restitution to confirmed financial harm across both of Lane's victims, not just PowerSchool.
The court imposed a specific, substantial restitution figure — about $14.1 million — rather than leaving every affected district and family to pursue recovery separately through civil court.
Why this keeps happening
A single credential without multi-factor authentication was the entire technical barrier between a 19-year-old working alone and the records of millions of children — not a sophisticated exploit, not a zero-day, just one unprotected login that happened to belong to someone with broad reach.
Internal support and maintenance tools built for a vendor's own engineers routinely carry far more reach than any single customer-facing login — exactly the kind of tool that turns one compromised account into a breach measured in thousands of organizations instead of one.
A guilty plea and a sentence resolve the criminal side of a breach like this, but the separate civil litigation over the breach itself is often still working through the courts long after the person responsible is already serving time. The criminal case closing is not the same as the story being over for everyone it affected.
Lessons for your own environment
- MFA has to be universal, not mostly universal
PowerSchool required MFA almost everywhere except the one account that mattered. A single exception is exactly where a patient attacker looks first.
- Support and maintenance tools are high-value targets, not back-office utilities
The tool that let one stolen login reach 6,505 districts was built for PowerSchool's own engineers to help customers. Treat internal support tooling with the same access controls as anything customer-facing.
- An unexplained earlier access event deserves investigation, not a shrug
A separate set of logins to the same portal months before the breach was never tied to a cause. An anomaly on a sensitive system is a lead, not background noise.
- A ransom payment doesn't end your obligations
PowerSchool paid to keep the data from being published, but still faced public disclosure, regulatory scrutiny and ongoing civil litigation regardless. Paying addresses one risk, not all of them.
- Contractor credentials need the same scrutiny as employee credentials
The compromised account belonged to a contractor, not a PowerSchool employee. Third-party access with broad reach is still your attack surface, whoever's payroll they're on.
- A criminal sentence closes one chapter, not the whole story
Lane's prosecution is resolved. The civil litigation from affected families and districts is not — a breach's legal aftermath often runs on two tracks that finish at very different times.
CISO & board lessons
- If your organization is a vendor whose support tooling can reach many downstream customers' data from one login, govern that tooling like the single most sensitive system you operate — a breach of it doesn't stay contained to one customer the way a typical account compromise does.
- Ask specifically, by account name, which logins in your environment are exempt from MFA and why. "MFA is enabled" as a blanket statement is exactly the kind of answer that hid PowerSchool's one real gap.
- Treat any unexplained prior access to a sensitive system as a standing, open finding that needs real investigation — not a footnote that only gets revisited after a larger, confirmed incident makes it relevant.
- A ransom payment reduces one specific risk (publication of stolen data). It is not a substitute for notification, regulatory engagement, or an independent security review — budget and plan for all of those regardless of whether a payment is made.
- Track your organization's criminal-case outcome and its own civil/regulatory exposure as two separate, independently resolving timelines. A sentencing headline does not mean your organization's own legal and reputational exposure is settled.
Action plan
First 24 hours
- Identify every account in your environment — internal and contractor/vendor — that is exempt from MFA, and treat each exemption as an active finding until it's justified or closed.
- If you operate any internal tool capable of reaching multiple customers' or tenants' data from a single login, confirm exactly who currently has access to it and whether that access is logged and actively monitored.
- Review authentication logs on your most sensitive support/admin portals for any unexplained access pattern beyond the suspected incident window, not just within it.
First 7 days
- Close remaining MFA exceptions across contractor and employee accounts alike — start with any account that can reach more than one customer's or business unit's data.
- Audit internal support/maintenance tools specifically for the blast radius a single compromised credential could reach, and add stepped-up authentication or approval gating proportional to that reach.
- Prepare a notification framework that can scale to a large number of individually affected parties (customers, districts, families) with specific, accurate detail per recipient — not one generic statement.
First 30 days
- Commission an independent security assessment of support and administrative tooling specifically, not just customer-facing production systems.
- Establish a standing process for investigating any anomalous access event on a sensitive system as soon as it's observed, rather than only in hindsight after a larger incident.
- Build a parallel tracking process for criminal-case status and civil/regulatory exposure — stakeholders will ask about both, and they resolve on different timelines.
Could this happen in your organization?
- Can you name every account in your environment that is exempt from MFA, and justify each exception specifically?
- Do you know which internal tools, if compromised through a single login, could reach data across multiple customers, tenants, or business units at once?
- Are contractor and vendor credentials monitored with the same rigor as employee credentials?
- If an anomalous access event occurred on a sensitive system today with no immediately obvious cause, would it actually get investigated, or noted and set aside?
- If you are a customer of a vendor like PowerSchool, do you know what access that vendor's own support staff and tooling have into your data, and how that access is controlled?
- Does your incident-notification process scale to individually informing a very large number of affected parties, or does it only work for a single-organization breach?
- Would your organization's response to a ransom demand be a considered, pre-planned decision, or an improvised one made under pressure?
If this happened to you: what to ask, and what to say
Knowing the lesson isn’t the same as knowing what to do with it Monday morning. A security lead, a CISO, and a customer-facing team each need something different from this incident.
- "Can we name every account in our environment that's exempt from MFA, and why?"PowerSchool's gap was a single account. Ask for the actual exception list, not a confirmation that "MFA is enabled."
- "Who has access to tools that can pull data across multiple customers or tenants at once?"The Maintenance Access tool is exactly this pattern. Name every internal tool with that kind of reach and confirm its access controls match the risk.
- "Do our contractors' and vendors' credentials get the same monitoring as employee accounts?"The compromised login belonged to a contractor. Confirm third-party access isn't quietly held to a lower standard.
- "If we saw an unexplained access event months before a confirmed breach, would we actually investigate it at the time?"PowerSchool's earlier, unconnected access window went unexamined until after the fact. Walk through how your team would handle an anomaly with no confirmed cause.
- State the technical cause plainly.No euphemisms — name the actual gap."A contractor credential without multi-factor authentication was used to access our support portal, and a tool built for our own engineers was used to extract data across affected districts."
- Separate what you can confirm from what's still being finalized.Don't round a still-moving number up or down for convenience."We can confirm the entry point and the tool used. The full scope of affected individuals is still being finalized with each district."
- Address the ransom decision directly.A payment is a risk-management decision, not a resolution — say so."We made a payment to prevent the publication of stolen data. Doing so did not end our legal, regulatory or notification obligations, and we are treating it as one response among several."
- Acknowledge what's still unresolved.The criminal case closing isn't the same as the story being over."The individual responsible has been prosecuted. Civil litigation related to this breach is ongoing, and we will continue to update affected districts and families as that proceeds."
- Tell families directly whether their child's SSN was involved.Don't make parents guess from a general notice."Our records indicate whether your child's Social Security number was part of the data affected. We are notifying every family individually rather than issuing one general statement."
- Explain the support-portal failure in plain terms.A parent doesn't need "PowerSource" or "Maintenance Access" — they need the plain version."The data was accessed through an internal support system, not through your school's own login or systems directly."
- Offer a specific, concrete protective step.A generic warning helps no one; a free, actionable service does."We are providing free credit monitoring for every affected student and staff member; enrollment instructions are included with this notice."
- Warn about the long-delayed risk specific to children's stolen data.A minor's SSN is often misused years later, not immediately."Stolen Social Security numbers belonging to minors are frequently used years later, once the child is old enough to apply for credit. We recommend a credit freeze with each bureau now, even though no misuse has been detected yet."
References & confidence
- ConfirmedBleepingComputer — coverage of the PowerSchool breach and its scope
- DisputedTechCrunch — malware stole internal PowerSchool passwords from an engineer's hacked computer — Describes a different-sounding initial-access mechanism (malware on an engineer's machine) than the contractor-credential narrative used elsewhere; not reconciled across sources, so both accounts are presented as unresolved rather than this case study picking one.
- ConfirmedNBC News — PowerSchool breach and MFA-gap reporting
- ConfirmedThe Register — PowerSchool breach timeline and disclosure
- ConfirmedSecurityWeek — PowerSchool portal compromised months before the breach — Independent corroboration of the earlier, unexplained access window.
- ConfirmedK-12 Dive — PowerSchool hacker sentencing and lessons for districts
- ConfirmedSecurity Affairs — Matthew Lane sentencing coverage
- ConfirmedWRAL — CrowdStrike audit findings and PowerSchool's MFA response
- ConfirmedThe 74 — coverage of Matthew Lane's sentencing hearing