PowerSchool’s widely reported compromise of its PowerSource support portal created a wake-up call for organizations that host or rely on student information systems that also carry health data. Investigations by third parties and reporting by multiple outlets found that a threat actor used compromised support credentials to access a maintenance tool in PowerSource and export the Students and Teachers tables from affected SIS instances, with some exports containing medical alerts, medication schedules, and other health-related fields.

The attack vector was not a novel zero day. Instead it was credential abuse against a customer support pathway that had maintenance-level access into customer databases. CrowdStrike’s investigation and reporting indicate the same set of compromised credentials show activity months earlier, meaning the window for detection and recovery was much larger than initially believed. Reports also detail how stolen credentials and infostealer malware on an engineer’s machine contributed to risk.

Why healthcare fields inside an SIS matter

Student health data inside an SIS is often treated differently from hospital records. In the U.S., health information created and maintained by a school or an entity acting on behalf of a school is typically an education record governed by FERPA, not the HIPAA Privacy Rule. That legal distinction does not reduce the operational need to protect those data. Health fields reveal vulnerabilities that are attractive to attackers: identity attributes, special needs indicators, medication schedules, and emergency contacts. Exfiltration of those fields can create real-world safety and privacy harms.

Where defenses failed

The PowerSource incident shows several recurring failures seen in infra compromises: overprivileged support access, insufficient multi-factor enforcement on external maintenance accounts, weak credential hygiene, limited log retention for long-term detection, and endpoint hygiene gaps that allow infostealers to harvest credentials. When maintenance portals are architected to let a single support account pivot into many customer instances, the blast radius of a single compromised login multiplies.

Immediate technical mitigations every SIS operator and customer should require

  • Enforce strong, modern authentication on any support portal or maintenance account. Require multi-factor authentication and prefer phishing-resistant authenticators such as FIDO/WebAuthn where possible. Follow NIST digital identity guidance when choosing authenticator assurance levels.
  • Segment and restrict maintenance access. Put support tools behind a bastion or VPN that requires device attestation and contextual policy checks. Do not allow broad administrative sessions from unmanaged endpoints. Implement least privilege so export or bulk-read capabilities are separate, logged, and require elevated just-in-time approvals.
  • Harden privileged credentials and lifecycle. Rotate support and maintenance credentials on a short schedule, enforce long random passwords where single factor remains, and use ephemeral session credentials or dedicated service principals rather than long-lived user accounts. Record and audit every privileged operation.
  • Field-level protection for health data. Encrypt sensitive health fields at rest with application-level or field-level encryption and maintain separate key management and access controls for decryption operations. Tokenize or redact high-risk fields for anything that does not need cleartext for operational use.
  • Endpoint and supply chain control. Require managed devices, EDR, and attestation for any engineer or contractor with elevated access. Limit the use of personal devices for administrative work and mandate vendor security baselines for subcontractors. The incident reports show infostealer malware on a developer or contractor device amplified risk.
  • Longer and richer logging plus proactive detection. Ensure audit logs for support portals are retained for a long enough window to detect slow intrusions, and forward logs to a tamper-resistant SIEM. Build detections that flag mass exports, lateral use of maintenance tooling, and uncommon IP geographies for privileged sessions.

Policy, contracts, and governance fixes

  • Update vendor agreements and SLAs. Require vendors that host SIS or support portals to meet explicit security controls: MFA for support accounts, device management for support technicians, field-level encryption for health attributes, and mandatory breach notification timelines.
  • Treat subcontractors as high-risk third parties. Require the same controls of subcontractors as of primary vendors, and insist on proof through independent audits or SOC 2 type reports. If a support vendor is given maintenance-level access, granularly scope that access and require ephemeral session tokens.
  • Data minimization and retention policies. Districts and vendors should catalog which health fields are essential, reduce collection where possible, and apply minimization policies so less sensitive production data is available in environments that are accessible to support personnel.
  • Clarify legal coverage and communication. Because most student health records at K-12 institutions fall under FERPA, districts must ensure their privacy notices, parental communications, and data sharing agreements account for that. Legal teams should coordinate with vendors on notification obligations and corrective steps.

Incident response and restoration posture

  • Assume compromise. Plan to rotate credentials, revoke sessions, and isolate maintenance tooling the moment suspicious activity is detected. A delayed credential rotation allows the attacker to return.
  • Preserve and centralize forensic data. Investigators require logs to attribute activity and understand timeline. In the PowerSource case, investigation scope and attribution were complicated by insufficient older logs.
  • Negotiate carefully and document decisions. If an organization engages a negotiator or pays a ransom, record the decision-making process, what assurances were received, and any technical evidence of deletion. External monitoring for leaked data should continue indefinitely, and remediation plans should assume some data will surface later. Reporting by multiple outlets indicates that PowerSchool engaged a negotiator in response to extortion, which underscores the reality that many response decisions will include legal and risk tradeoffs.

Practical prioritized checklist for defense

1) Enforce MFA and phishing-resistant authenticators for all support, contractor, and engineer accounts. 2) Move support portals behind managed access gateways with device attestation and conditional access. 3) Implement field-level encryption and tokenization for health and SSN fields. 4) Require managed endpoints and EDR for any user with maintenance privileges. 5) Shorten credential lifespans, use ephemeral sessions for maintenance, and log all exports to a central SIEM with long retention. 6) Update contracts to require proof of security practices for vendors and subcontractors. 7) Run regular tabletop exercises with vendors and districts that include scenarios where support portals are abused.

Final note of caution

Education systems carry sensitive health information that directly affects student safety. The PowerSource incident shows that a single compromised support pathway can expose millions of records when systems are designed for broad maintenance access. Fixing this requires both immediate technical hardening and sustained changes to how vendors provision, audit, and govern privileged maintenance capabilities. Organizations that treat support portals as routine helpdesks rather than high-risk attack surfaces will continue to be attractive targets. The recovery must be technical, contractual, and cultural: push vendors to reduce blast radius, demand proof of controls, and insist that privileged maintenance access be treated with the same rigor as any other production-critical infrastructure.