Former School IT Employee Sentenced After 21-Month Attack on Iowa District
#Cybersecurity

Former School IT Employee Sentenced After 21-Month Attack on Iowa District

Security Reporter
9 min read

A former Saydel Community School District IT employee received 21 months in prison after prosecutors said he kept access credentials and repeatedly disrupted school systems long after leaving the job.

A former school IT worker did not need a zero-day exploit to disrupt classrooms. Prosecutors say he had something more common and often more dangerous: old credentials, administrative knowledge, and months of unchecked opportunities.

Featured image

Ezekiel Dean Potter, 34, a former senior IT support specialist for the Saydel Community School District in Des Moines, Iowa, was sentenced on June 11, 2026, to 21 months in federal prison, followed by three years of supervised release. He must also pay $59,668.81 in restitution to the district and its insurer for remediation costs.

According to court documents summarized by prosecutors, Potter worked for the district from May 2022 through April 2023. After his employment ended, he retained access credentials and spent roughly 21 months targeting the district’s systems. The affected platforms reportedly included Facebook, Apple School Manager, managed MacBooks and iPads, GoDaddy, Schoology, Google administrator accounts, Gmail accounts, and other district services.

The government’s sentencing memorandum described the conduct bluntly: “For over a year and a half, Defendant was a plague on the Saydel Community School District.” Prosecutors said he deleted the district’s Facebook page, stripped employees of access to educational platforms, tried to reset usernames and passwords, and caused operational disruption for staff and students.

The case is a useful reminder for every school district, municipality, nonprofit, and mid-sized business: offboarding is not a paperwork step. It is an incident prevention control.

What Happened

The alleged activity began shortly after Potter left Saydel. Prosecutors said the district’s Facebook account was deleted first. Later, the attacker targeted Apple School Manager, deleting user accounts, passwords, phone numbers, billing information, and mobile device management server data.

That mattered because Apple School Manager is not just a web portal. In education environments, it often sits close to the center of device identity, enrollment, app distribution, and managed Apple account administration. If an attacker disrupts that layer, the impact can spread from an admin console into classrooms. In this case, prosecutors said the district was unable to manage MacBooks and iPads for roughly a week while staff worked with Apple to recover access.

The activity reportedly continued across other services. Court documents said there were unauthorized access attempts against GoDaddy and other online accounts. In January 2025, Potter allegedly accessed Schoology through a Google administrator account and deleted an IT employee’s account, disrupting teacher access to the learning management system for about two hours. A week later, prosecutors said he used another administrator account to delete nine Gmail accounts belonging to current and former employees, including the IT director and superintendent.

Investigators also said the attacker changed tactics after Google security alerts warned of unauthorized access. Potter allegedly began using a VPN service. Federal investigators later tied some activity to IP addresses associated with his other employers, including Casey’s Store Support Center and The Printer Inc. After leaving The Printer Inc. in January 2025, prosecutors said he asked a former coworker to retrieve and wipe a USB drive from his desk. The coworker instead turned it over to investigators, who allegedly found spreadsheets containing usernames and passwords for Saydel accounts and services.

Potter pleaded guilty in January 2026 to computer fraud charges under the Computer Fraud and Abuse Act without a plea agreement.

Why This Case Matters

This was not described as a sophisticated intrusion in the usual sense. The case reads like a failure of account lifecycle management, privileged access review, and third-party service ownership.

That is exactly why it matters.

Schools and small public-sector organizations often run complicated technology stacks with limited staff. A typical district may depend on Google Workspace or Microsoft 365, Apple School Manager, an MDM platform, student information systems, learning management systems, registrar tools, DNS and domain registrars, finance software, social media accounts, emergency notification services, and dozens of curriculum platforms. Many of those systems are administered by the same small IT team. Some accounts are shared. Some are tied to personal recovery emails or phone numbers. Some were created years ago by people who no longer work there.

That creates a dangerous gap. The attacker does not need to compromise the network perimeter if an old admin credential, recovery method, OAuth grant, API token, or registrar login still works.

The Center for Internet Security’s Account Management control frames the basic discipline clearly: organizations should use processes and tools to assign and manage authorization for user accounts, including administrator and service accounts. That sounds simple, but the Saydel case shows the operational detail behind the sentence. Account management must cover SaaS applications, device-management platforms, domain registrars, social media, recovery contacts, break-glass accounts, shared mailboxes, service accounts, and any private spreadsheets where credentials may have been stored.

NIST SP 800-53 Revision 5 also treats access control as an organization-wide risk management problem, not a single login setting. Its catalog includes controls for account management, access enforcement, audit logging, identification and authentication, and incident response. The useful lesson for smaller organizations is not to copy a federal control catalog word for word. It is to turn those concepts into operational checklists that can be executed every time a worker changes roles or leaves.

The Affected Platforms Tell the Real Story

The named systems are a map of modern school operations.

Facebook affected public communications. A deleted page can break community announcements, event notices, emergency updates, and public trust.

Apple School Manager affected device administration. Losing control of managed Apple accounts and device-management links can interfere with MacBooks and iPads used by students, teachers, and staff.

GoDaddy affected domain and web infrastructure risk. A registrar account can control DNS, email routing, website records, and ownership of public-facing domains. Registrar compromise can become a broader identity problem because email and domain control are often used to reset passwords elsewhere.

Schoology affected classroom instruction. Learning management systems are not optional back-office tools. They host assignments, class materials, grading workflows, student communications, and teacher routines.

Google administrator access affected identity and email. Google Workspace admin accounts can manage users, reset credentials, suspend accounts, review logs, configure security settings, and interact with connected applications. Google’s own security checklist for medium and large organizations recommends multifactor authentication, security keys for admins and other high-value accounts, regular review of alerts and activity reports, admin email alerts, and controls to prevent unauthorized access after an employee leaves.

That last point is the center of the case. The harm was not limited to one account. Once identity administration is exposed, the attacker can cause second-order failures by deleting users, resetting passwords, removing access, changing recovery details, or blocking legitimate admins from responding.

Practical Advice for Defenders

Start with a real offboarding inventory. HR may know when a person leaves, but IT needs a list of every system where that person had direct access, delegated admin rights, shared credentials, API keys, device tokens, SSH keys, recovery email access, or billing-owner permissions. The list should include cloud identity providers, SaaS tools, MDM, DNS and registrar accounts, social media, payment systems, backup tools, remote access tools, code repositories, and vendor portals.

Suspend first, delete later. Google’s administrator guidance on suspending users explains that suspension blocks access without deleting email, documents, calendars, and other data. That model is useful across platforms. During offboarding, preserve data and logs while immediately removing the person’s ability to authenticate. Deletion can happen later after legal, retention, and ownership requirements are handled.

Rotate shared secrets every time an administrator leaves. This includes passwords stored in spreadsheets, shared browser profiles, password-manager vaults, Wi-Fi admin portals, local administrator passwords, break-glass credentials, registrar logins, social media passwords, recovery codes, and service account keys. If the organization cannot tell which secrets the person knew, assume they knew all shared secrets used by the team.

Review privileged roles, not just active users. A former employee’s named account may be disabled while a second account, vendor account, shared mailbox, unmanaged consumer account, or emergency admin remains active. Google Workspace admins should review role assignments, super admin membership, recovery settings, third-party app access, and audit logs. Apple School Manager admins should review roles and privileges through Apple’s school administration documentation, then confirm MDM server connections and account ownership.

Protect domain registrars like identity systems. DNS and domain ownership are recovery paths for many other accounts. Registrar accounts should use phishing-resistant MFA where available, role-based access, locked domains, restricted transfer settings, monitored DNS changes, and a documented recovery process that does not depend on a single employee’s email or phone.

Turn alerts into response playbooks. Google recommends reviewing account activity, admin status, 2-Step Verification enrollment, risky sign-ins, and Admin audit logs. Alerts only help if someone owns them. A useful playbook should answer who receives the alert, how quickly they must respond, how they validate whether the action was legitimate, how they revoke sessions, and when they escalate to legal or law enforcement.

Watch for behavior that crosses systems. In this case, prosecutors described activity across social media, Apple administration, learning systems, Google accounts, and domain services. Many organizations monitor each platform separately, which makes a slow insider attack look like isolated annoyances. A better pattern is to send admin events from core SaaS platforms into a central log system or SIEM, then alert on sequences such as deleted users, password resets, role changes, recovery setting changes, MFA changes, registrar logins, and VPN-anonymized admin access.

article image

Test the process before a crisis. Run a tabletop exercise using a realistic scenario: a senior IT admin leaves under tense circumstances, and 24 hours later an LMS account is deleted. The exercise should verify whether the organization can identify all admin accounts, revoke sessions, rotate secrets, preserve logs, contact vendors, restore deleted users, recover device-management access, and communicate with teachers and leadership. This is where breach and attack simulation, log review, and manual walkthroughs can expose gaps before an attacker does.

The Takeaway

The Saydel case is not just a story about one former employee. It is a warning about trust that remains wired into systems after the employment relationship ends.

For schools, the highest-risk accounts are often the ones that feel routine: Google admin, Apple School Manager, MDM, LMS, registrar, payroll, help desk, and social media. They are not glamorous targets, but they can halt instruction, erase communications, disable devices, and force expensive recovery work.

The practical fix is disciplined and repetitive: know every privileged account, remove access immediately when roles change, rotate shared credentials, protect admin accounts with strong MFA, centralize logs, test recovery, and make sure no single person quietly owns the keys to critical services. That is not just compliance hygiene. It is how a district keeps classrooms running when trust breaks down.

Comments

Loading comments...