# Identity for Education: School SSO, Rostering, FERPA, and COPPA Source: https://startwithidentity.com/articles/identity-for-education/ Last updated: 2026-10-16 License: content by Start with Identity. Cite the source URL. --- Identity in education is broader than almost any other sector: a single university directory can hold applicants, students, faculty, contractors, researchers from partner institutions, parents, and alumni, and a school district adds millions of minors to the mix. The job is to give each of them the right access as they move through the academic lifecycle, keep learning apps in sync with class rosters, and protect student records under FERPA and children's data under COPPA. See the [education vertical](https://startwithidentity.com/verticals/education/) page for the sector view. ## The student lifecycle drives everything The hard part of education identity is not authentication, it is change. A person may be an applicant in March, a student in September, a teaching assistant two years later, and an alumnus after graduation. Each transition should add and remove access automatically. When it does not, the result is the same accumulation problem corporate IT sees with [mover entitlement accumulation](https://startwithidentity.com/techniques/mover-entitlement-accumulation/) and [orphaned accounts](https://startwithidentity.com/techniques/orphaned-account-abuse/), at much larger volume. Practical lifecycle rules: - Source identity from the student information system (SIS) and HR system, never from manual account requests. - Tie learning-app access to current enrollment, so dropping a course drops the class membership. - Define an alumni role up front, with a narrow, documented set of services, and expire everything else at graduation. - Review dormant accounts each term. Unused student and alumni accounts are prime targets for [credential stuffing](https://startwithidentity.com/glossary/credential-stuffing/). ## School SSO and rostering [Single sign-on](https://startwithidentity.com/glossary/sso/) gets a student into apps with one login, but on its own it cannot tell an app which classes that student is in. That is the role of rostering. The [1EdTech OneRoster](https://www.1edtech.org/standards/oneroster) standard, currently version 1.2, defines a data model for users, courses, enrollments, organizations, and grades, exchanged as CSV files or through a REST API. K-12 districts often use [Clever](https://clever.com/), which combines rostering from the SIS with a single login portal for students and teachers. The design consequence is that roster quality equals access quality. A duplicate student record, a stale enrollment, or a teacher left on last year's section becomes an access error in every connected app at once. Higher education leans more on [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/) and [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) federation, including research and library federations such as [eduGAIN](https://edugain.org/), so a student or researcher can use a home-institution login at partner services. Young children add a usability constraint: they often cannot manage passwords or MFA prompts. Schools use picture passwords, QR badges, and shared classroom devices for early grades, which makes device management and session timeouts part of the identity design. Older students and staff should move to [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/) and [passkeys](https://startwithidentity.com/guides/authentication/passkeys-101/); the [MFA rollout playbook](https://startwithidentity.com/guides/authentication/mfa-rollout/) covers how to do that across a population that resists friction. ## FERPA: who may see education records The [Family Educational Rights and Privacy Act](https://studentprivacy.ed.gov/ferpa) protects the privacy of student education records. Under the Department of Education's guidance, a school may disclose records without consent to a ["school official"](https://studentprivacy.ed.gov/faq/who-school-official-under-ferpa) with a legitimate educational interest, which can include an outside contractor that performs an institutional function and stays under the school's direct control. For identity teams, that maps to concrete controls: - Role-based access to SIS and learning-management data, scoped by school, section, and job function. - Vendor and integration access limited to the data the function needs, with contracts that match. - Access logs that can show who viewed or exported which student records. ## COPPA and the 2025 amendments [COPPA](https://startwithidentity.com/regulations/united-states/coppa/) applies to online services that collect personal information from children under 13. The FTC's [COPPA FAQ](https://www.ftc.gov/business-guidance/resources/complying-coppa-frequently-asked-questions) allows a school to provide consent on a parent's behalf when a service is used solely for an educational purpose and not for commercial ends. The FTC [finalized amendments in January 2025](https://www.ftc.gov/news-events/news/press-releases/2025/01/ftc-finalizes-changes-childrens-privacy-rule-limiting-companies-ability-monetize-kids-data): separate parental consent before disclosing children's data to third parties, a written data retention policy, a written information security program, and an expanded definition of personal information that includes biometric identifiers. Per the [Federal Register notice](https://www.federalregister.gov/documents/2025/04/22/2025-05904/childrens-online-privacy-protection-rule), the rule took effect June 23, 2025, with most obligations due by April 22, 2026. The FTC chose not to codify the proposed school-authorization changes, so the existing guidance still governs that path. For identity design, that means collecting the minimum profile data at signup, keeping retention timers on child accounts, and treating biometric login for minors as regulated personal data. ## Vendor and support access is the weak point In December 2024, PowerSchool [reported](https://www.theregister.com/2025/01/09/powerschool_school_data/) that an attacker used a compromised credential to reach its PowerSource customer support portal and extract data from school student information systems. The lesson for every district and university: support portals, integration accounts, and vendor admin consoles hold access to many institutions at once, and they need phishing-resistant MFA, least privilege, and monitoring at least as strict as staff accounts. See [help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/) for the adjacent attack path. ## Choosing a platform Most institutions run a workforce-style directory for staff and students: [Microsoft Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/) is common where the institution already uses Microsoft 365, while [Okta](https://startwithidentity.com/vendors/iam/okta/) and [JumpCloud](https://startwithidentity.com/vendors/iam/jumpcloud/) suit mixed or budget-constrained environments. Weigh native SIS and rostering integrations, alumni and guest lifecycle support, and pricing that works at student scale. The [best IAM platforms](https://startwithidentity.com/rankings/best-iam-platforms/) and [IAM for SMB](https://startwithidentity.com/rankings/best-iam-for-smb/) rankings compare options, and the [regulations hub](https://startwithidentity.com/regulations/) tracks GDPR and other obligations for institutions outside the US. In education, the identity system is only as accurate as the roster behind it, so fix the data flows first and the access model follows.