COPPA Obligations for EdTech Products Serving Minors

COPPA turned 25 this year, and the FTC just gave it the biggest update since 2013. If you build EdTech products that touch kids under 13, the compliance ground shifted under you in April 2025, and the deadline to catch up is closer than the calendar makes it feel.

Here's the base layer, in case anyone forgot it's binding law and not a suggestion: COPPA lives at 15 U.S.C. § 6501, with the actual mechanics spelled out in 16 CFR Part 312, and it's been on the books since 2000. The core deal has never changed: get verifiable parental consent before you collect personal information from a kid under 13. Two things trigger that obligation, and only one has to be true: either your site or service is directed to children, or you have actual knowledge you're collecting from a child under 13. That second trigger is the one that catches platforms who swear up and down they're "not for kids" while their own analytics dashboard is full of second-graders, because you can't disclaim what you can see.

Personal information under COPPA was already broad. Names, photos, location, contact info, and persistent identifiers like device IDs, cookies, and IP addresses all count, and that last category is why "we don't collect names" has never been a real defense; if your analytics SDK is quietly assigning a persistent ID to a seven-year-old, congratulations, you're in scope. And none of this requires you to market to kids. If children actually use your product and you know it, the rule applies whether you wanted them there or not.

How the 2025 final rule changed the compliance baseline

Twelve years is a long time in tech. The last COPPA Rule update happened in 2013, back when the iPhone 5 was cutting-edge and nobody had said the words "large language model" out loud. The FTC opened a comment period in 2019, issued a formal notice of proposed rulemaking on January 11, 2024, reviewed 279 comments, and then voted unanimously to adopt the final rule. It published in the Federal Register on April 22, 2025, and became effective June 23, 2025.

Mark the real date on your calendar, though: April 22, 2026, because that's the compliance deadline for most of the substantive provisions. Teams treating June 2025 as the finish line are giving themselves less runway than they think, and less runway than they'll want once legal review starts finding gaps.

Five changes matter most for EdTech builders specifically. The definition of personal information expanded to include biometric and government identifiers (more on that below). Consent for third-party disclosures, including targeted advertising and AI training, now has to be separate and unbundled from your general consent flow. Operators need a written data retention policy, published in the privacy notice, that spells out purpose, business need, and a deletion timeline. There's now a requirement for a written information security program, reviewed at least once a year. And direct-to-parent notice requirements got stricter, running in parallel with public notice requirements, so updating one without the other leaves you non-compliant on its face.

What didn't change matters just as much. The core consent obligation is still there, the school authorization exception is still structured the same way, and verifiable parental consent is still required. This is an addition, not a replacement; the 2025 amendments stack on top of the original rule rather than swapping it out.

What now counts as personal information under the expanded definition

Two new categories joined 16 CFR 312.2: government-issued identifiers, and biometric identifiers usable for automated or semi-automated recognition of a person. The final rule actually lists them out: fingerprints, handprints, retina patterns, iris patterns, genetic data (DNA sequences included), voiceprints, gait patterns, facial templates, and faceprints.

Read that list again and think about what EdTech actually builds: voice-based tutors, attendance systems running facial recognition, and adaptive learning tools analyzing a kid's speech patterns to adjust difficulty. All of that now touches regulated data the moment a user under 13 is involved.

Here's the interesting part, though, and the part that trips people up: the FTC pulled voice-derived data, facial-derived data, and gait-derived data out of the final definition. Those were in the 2024 proposal, and public comments pushed back hard enough on overbreadth that the Commission dropped them. So a raw voiceprint is covered, but analytics derived from someone's voice, and that don't rise to the level of a voiceprint themselves, might not be. That's a genuinely fine line, and it's not one your engineering team should be drawing on their own judgment; that call belongs to a lawyer, not a Jira ticket.

The takeaway that should stick: if your product generates or stores a biometric template, even as a side effect of something helpful like an accessibility feature, you now need the full COPPA consent machinery before you collect it. And the FTC's whole pattern here has been to widen definitions as tech moves forward, so assuming a data type is fine because it wasn't listed in the year-2000 version of the rule is exactly the wrong instinct.

How the "directed to children" determination actually gets made

You don't get to self-certify your way out of this one. The 2025 rule lays out four kinds of evidence the FTC will actually look at when deciding who your audience really is: your marketing materials, what you've told consumers or third parties, reviews from users or outside observers, and the age makeup of users on comparable platforms. In other words, what you call your product doesn't override what the market and the reviews say it actually is.

The rule also formalized a category that had been floating around informally for a while: the mixed-audience service, now codified at 16 CFR § 312.2. That's a platform that's directed to children but where kids aren't the primary audience. If you fit that definition, you have to run a neutral age screen before collecting any personal information from anyone, and that's mandatory, not a suggestion or best practice.

And "neutral" has teeth. The FTC specifically calls out age-collection methods that default to a set age or nudge visitors toward fibbing about their age. A pre-checked "I'm over 13" box fails. A dropdown that lists ages in descending order, making the under-13 options awkward to scroll to, fails. A birth-year picker that opens on 1990 fails too. The design of your age gate is itself a piece of the compliance puzzle, not just a UX decision your product team gets to make in a vacuum.

This is exactly where a lot of EdTech products live, whether they realize it or not. A district-licensed tool used simultaneously by teachers, administrators, and students sits right on the mixed-audience line. If that's your architecture, the age-screen requirement isn't optional just because most of your logged-in users are adults.

The school authorization exception: what it permits, what it does not

Schools can consent on behalf of parents, but only for a genuinely school-authorized educational purpose. The school is standing in as the parent's agent here; it is not handing the vendor a get-out-of-COPPA-free card.

What it does not cover: building marketing profiles from student data, training AI models on that data without separate authorization, sharing it with outside partners beyond the educational purpose, or any commercial use at all. Advertising, profiling, or selling access all void the school's authority to consent, and the vendor now needs direct parental consent instead.

The FTC's 2023 case against Edmodo is the cleanest real-world marker of where this line sits. Edmodo's terms of service told teachers they were "solely responsible for complying with COPPA." The FTC called that "nonsensical" and tossed it out as a defense, then ordered the company to delete machine learning models it had trained on student data collected improperly. The lesson writes itself: a data processing agreement cannot hand your legal obligation to a school district, much like a restaurant can't blame food poisoning on the customer for choosing to eat there.

DPAs still matter, to be clear. They should spell out what you can collect, how you'll use it, how long you'll keep it, and how you delete it. But a DPA documents your obligations; it doesn't make them disappear.

Products with two front doors, one for schools and one for consumers, run into a structural wall here. You can't run a single consent flow across both. The school-mediated path can lean on school authorization if the use is genuinely educational. The direct-to-consumer path gets no exception at all; you need verifiable parental consent, full stop, with no school standing in the middle to shortcut it.

Verifiable parental consent: the nine approved methods and how to choose among them

The approved list of verification methods grew from five to nine under the 2025 amendments, and three of the new ones are worth knowing by name: government-issued ID verification, facial recognition matched against a government ID, and knowledge-based authentication built from public records. Add those to the older standbys: signed consent forms returned by mail or fax, credit card verification tied to an actual transaction, video conference with a parent, email plus additional confirming steps, phone or electronic scanning, and text message plus confirming steps.

More options sounds like more flexibility, and it is, but it comes with a real tradeoff. High-assurance methods like ID verification cut down on fraud and create friction that tanks completion rates, so parents drop off. Low-friction methods like email-plus-confirmation are easier to complete but easier to fake. The right call depends on what you're actually collecting; a platform gathering anything biometric shouldn't be leaning on email confirmation alone and calling it a day.

The bigger structural shift, though, is the one buried in § 312.5(a)(2): you can no longer bundle consent for third-party disclosure, whether for advertising or for AI training, with your general consent flow. That has to be its own separate, standalone consent event, not a checkbox tucked into your existing sign-up flow, however clearly worded. If your product currently bundles that consent, it's non-compliant once the 2026 deadline lands, no matter how good your legal copy reads.

And notice requirements run on their own parallel track. Direct parental notice and the public privacy notice have different content rules now. Updating your privacy policy and leaving the direct notice untouched leaves you non-compliant, even if you genuinely thought you'd covered it.

Third-party SDKs, sub-processors, and where compliance gaps actually appear at the code level

Every SDK you bolt on, every analytics tool, every third-party service touching student data is inside the compliance perimeter. COPPA's obligations extend to operators' relationships with third parties handling children's data, not just your own systems.

Teams tend to overlook the same handful of categories: cookie syncing and tag management platforms, crash reporting and performance monitoring tools, A/B testing and feature-flag services, and in-app analytics SDKs quietly assigning persistent device IDs to every user who opens the app. None of these feel like "collecting personal information from children" when you're wiring them up, but under COPPA, a persistent identifier is personal information the moment it's generated, not the moment a human on your team happens to look at it.

Your contracts with these vendors need to actually say something: purpose limitation, so data collected for the school-authorized purpose stays there and doesn't wander off into marketing or ad targeting; a ban on secondary use without explicit sign-off; a maintained sub-processor list you can hand to a school on request; and flow-down language requiring your sub-processors to bind their own sub-processors to the same terms, so the obligation doesn't evaporate three layers down the vendor chain.

The unbundled AI-training consent requirement has a very literal engineering consequence. Any pipeline feeding student interaction data into a model training run needs its own separate parental consent event tied specifically to that use. You cannot quietly route student conversation logs to a third-party AI provider and assume your general COPPA consent already covers it, because as of 2025, it explicitly does not.

Start with a data flow audit: map every third-party integration, what data it touches, what it's used for, and whether the contract terms actually meet the flow-down standard. That audit isn't just a compliance nicety; it's also the raw material for the written information security program the 2025 rule now requires you to have.

What the FTC declined to codify about EdTech — and why that leaves the compliance obligation on vendors

Here's the part that'll frustrate anyone hoping for a tidy rulebook. The 2024 proposal included EdTech-specific language: formal definitions of "School" and "School-authorized education purpose," and provisions that would have codified the school authorization exception directly into the rule. None of it made the final cut, and the Commission chose not to finalize any school-specific or EdTech-specific amendments at all.

Why? The FTC said it was deferring to the Department of Education, which has its own plans to update FERPA regulations, and wants to see how that process plays out before layering more COPPA text on top of it. The Commission's language was that it would "continue to enforce COPPA in the ed tech context consistent with its existing guidance" while it watches FERPA developments unfold.

Practically, that means vendors don't get to wait around for a cleaner rulebook before shipping compliant products. Enforcement doesn't pause while regulators sort out their paperwork; it continues under the existing rule plus the 2025 amendments, right now. And without a codified definition of "school-authorized education purpose," the line between what's allowed and what isn't remains a matter of FTC guidance and enforcement history rather than clean statutory text you can point to. The Edmodo case is still the sharpest real signal available of where that line actually sits, which means it's worth treating less as a cautionary tale and more as the closest thing to a rulebook EdTech vendors currently have.