COPPA

COPPA Verified Parental Consent in 2025: The 8 Approved Methods and How to Implement Them

Promise Legal Staff

03 Jun 2026 • 27 min read

On April 22, 2026, the FTC's amended COPPA Rule takes full effect — bringing with it eight approved methods for obtaining verifiable parental consent, a new categorical prohibition on bundling advertising and AI training disclosures with core consent, and a $10 million reminder from the Disney enforcement action that failure to designate child-directed content triggers the same liability as any other consent failure. For EdTech founders and product teams, the compliance window is closing fast. This guide breaks down every approved consent method, the eligibility rules that eliminate most of them for most products, and the UX patterns the FTC has told you — through enforcement orders with dollar amounts attached — to avoid.

The Legal Floor: What COPPA Actually Requires Before Collecting a Child's Data

Before your app collects a single data point from a user who might be under 13, two questions determine whether COPPA's verifiable parental consent (VPC) obligation applies to you. Both are product-team questions, not just legal ones — and the 2025 Rule amendments made both harder to answer incorrectly without penalty.

The Two-Prong Trigger

COPPA's consent obligation activates under 16 CFR § 312.3 when either of two conditions exists: (1) your product is "directed to children," or (2) you have "actual knowledge" that you are collecting personal information from a child under 13. Either prong triggers full VPC requirements. A general-audience platform with actual knowledge of child users is just as obligated as an explicitly child-directed app.

The "directed to children" determination is a totality-of-the-circumstances multifactor test — not a binary based on whether your marketing says "for kids." The 2025 Rule amendments (90 FR 16977) expanded the evidentiary factors the FTC considers to include marketing materials and plans, representations made to consumers or third parties, user reviews, and the age composition of similar services. An EdTech platform cannot escape COPPA coverage by removing cartoon mascots if its App Store reviews describe a classroom tool used by 7-year-olds, or if comparable products in its category serve a child-majority audience.

The practical implication: every EdTech product team should document the directed-to-children analysis before launch and revisit it after any significant pivot in subject matter, marketing, or user demographics. If you later gain actual knowledge that children are using a product you previously classified as general-audience — through support tickets, user research, or school-district purchase patterns — the consent obligation activates from that moment of knowledge.

What the Internal-Operations Carveout Does (and Does Not) Cover

Many EdTech product teams believe that collecting only "technical" data — session IDs, device identifiers, analytics events — falls outside COPPA's consent requirements. This is partially correct but widely misapplied. Under 16 CFR § 312.2, the "internal operations" exception permits collection of persistent identifiers from children without parental consent only for a narrow set of purposes: maintaining site or service functionality, performing network communications, authenticating users, serving contextual advertising, protecting security, ensuring legal or regulatory compliance, or fulfilling a child's specific request.

The line between "in" and "out" matters enormously for product architecture decisions:

Contextual advertising falls inside the carveout — serving an ad based on the page a child is viewing does not require VPC as long as the data is not used for anything else.
Behavioral advertising falls outside the carveout — serving ads based on a child's browsing history, preferences, or inferred profile requires VPC even if the underlying data is just persistent identifiers.
Profile-building for any purpose falls outside the carveout — analytics SDKs that aggregate user events into per-user profiles, power recommendation engines, or feed machine-learning systems are not "internal operations" regardless of data type.
Contact with individual users using carveout data is prohibited — you cannot use a session ID collected under the internal-operations exception to send push notifications to child users.

This distinction is where third-party SDK integrations most often create undisclosed COPPA liability. An analytics SDK dropped into a child-directed app routinely builds the kind of per-user behavioral profile that the carveout expressly prohibits — even if the operator's own code never directly handles persistent identifiers. The FTC has made clear through enforcement actions like the 2025 Apitor settlement ($500K) that SDK behavior is attributed to the operator.

The 2025 Rule amendments added a second consent layer that applies even after your product has obtained valid VPC for data collection. Under the amended Rule, operators must obtain separate verifiable parental consent before disclosing a child's personal information to third parties for targeted advertising or for training or developing artificial intelligence technologies. The FTC explicitly stated that these purposes are "never integral" to any website or service — meaning there is no factual argument an operator can make that advertising or AI training is core to service delivery.

This dual-consent structure creates two distinct consent obligations that must be tracked separately in your data architecture and your consent UX:

Primary VPC: Required before collecting, using, or disclosing any personal information from a child.
Secondary disclosure consent: Required before sharing that information with third parties for advertising or AI training, and cannot be bundled with or conditioned on the primary VPC.

The April 22, 2026 compliance deadline means operators must have both consent flows operational and auditable before that date. The "reasonable effort" standard referenced in the VPC definition is not a soft target — it is defined operationally by the 8 approved methods the FTC has blessed in § 312.5(b), which are covered in the next section. Using a method outside that list does not satisfy the standard regardless of how careful your engineering team was.

The bottom line for product and legal teams: document your directed-to-children determination, audit every SDK for behavioral data use, design two distinct consent flows, and verify that neither is bundled into a terms-of-service checkbox. Everything downstream in this guide builds on that foundation.

The School Official Exception: How EdTech Vendors Plug Into It (and Its Limits)

The school official exception is the legal mechanism that allows schools to share student education records with EdTech vendors without obtaining prior parental consent. It is also the provision that most EdTech companies misunderstand, misapply, or quietly violate once their commercial interests diverge from their educational mission. Understanding the exception's three-element structure is not optional for any vendor receiving student data — it is the baseline for determining whether your data access is lawful at all.

The Three-Element Test

Under 34 CFR § 99.31(a)(1)(i)(B), outside parties — including contractors, consultants, and technology vendors — may qualify as "school officials" with legitimate access to education records only when all three of the following conditions are met:

Institutional function: The vendor performs a service or function that the school would otherwise use its own employees to perform. An LMS provider substitutes for the school's own course management infrastructure. An assessment platform substitutes for in-house testing administration. A product that does something the school would never do with employees — like targeted advertising or commercial profile-building — fails this element on its face.
Direct control: The vendor operates under the school's direct control with respect to the use and maintenance of education records. This means the school, not the vendor, determines what data is accessed, for what purpose, and under what limitations. A vendor that collects data beyond the scope of the school contract, or that uses data for its own product development without school authorization, is not under the school's direct control.
Use and redisclosure limitations: The vendor is subject to the requirements of 34 CFR § 99.33(a), which prohibits using or redisclosing education records for any purpose other than the purpose for which the disclosure was made. This requirement must be reflected in the written agreement between the school and the vendor.

The Department of Education's Student Privacy Policy Office has further clarified that school officials may access only those education records in which they have a "legitimate educational interest" — meaning access must be tied to the specific educational function being performed, not to the vendor's own product objectives. Schools are required to use reasonable methods to ensure that school officials, including vendors, obtain access only to records in which they have that legitimate interest. In practice, this means overly broad data access provisions in school contracts — provisions that give the vendor access to entire student databases rather than the specific fields needed for the contracted service — are not compliant with the exception's requirements.

Where Vendors Cross the Line

The most common way EdTech vendors violate the school official exception is by using student data received under a school contract for purposes that serve the vendor's commercial interests rather than the school's educational mission. Training machine learning models on student interaction data, improving non-school-facing product features, generating aggregate analytics sold to third parties, and conducting behavioral profiling for product development purposes are all uses that fall outside the scope of what the exception permits. The exception permits data use for the specific institutional function the vendor is performing under the school contract — nothing more.

The structural problem, which researchers and advocacy organizations have documented extensively, is that FERPA provides no mandatory contract requirements and no clear regulatory definition of "direct control." The Public Interest Privacy Center has noted that there are no standard security requirements that EdTech vendors must meet before receiving student data, and no requirement that schools have written contracts with all vendors they use. This creates a gap where vendors can nominally claim school official status while operating with data practices that would never satisfy the exception's requirements if subjected to scrutiny.

The Enforcement Reality — and Why It Doesn't Mean What You Think

Here is a fact that surprises many EdTech counsel: the Department of Education has never withheld federal funding from a school due to a FERPA violation. The SPPO's enforcement mechanism — withdrawal of federal funding — is theoretically available but has never been used. The Student Privacy Policy Office can also impose a five-year bar prohibiting a vendor from receiving student data from any school that receives federal funds, but this remedy has similarly not been deployed in a publicized enforcement action against an EdTech vendor to date.

This enforcement gap is not a green light. It is the reason state law enforcement and FTC jurisdiction have become the operative accountability mechanisms for EdTech data practices. California, New York, and Colorado have enacted vendor-direct data privacy statutes that impose obligations regardless of FERPA's enforcement posture. And the FTC — which enforces COPPA and has broad authority over unfair or deceptive trade practices — has demonstrated that it will act where FERPA enforcement has not.

Edmodo: The Precedent Every EdTech Developer Needs to Know

The FTC's 2023 enforcement action against Edmodo is the controlling case for the data practices this section describes. Edmodo was a school-facing EdTech platform that received student data under school agreements — precisely the school official exception framework — and then used that data for commercial purposes including behavioral profiling and targeted advertising. When the FTC challenged these practices, Edmodo's defense was that its Terms of Service had told teachers they were "solely responsible for complying with COPPA." The FTC found this argument "nonsensical" and flatly rejected it.

The Edmodo settlement established several compliance benchmarks that now function as the de facto floor for EdTech data practices:

Data retention must be limited — the Edmodo order required a one-year maximum retention limit for student data
School agreements must specifically describe all personal information collection and use — generic data processing terms are insufficient
Vendors must post clear privacy notices before collecting children's data — not in terms of service, but in accessible, pre-collection notice
Models and algorithms trained on improperly obtained children's data must be deleted — including commercial AI products built on that training data

That last point deserves emphasis: the FTC required Edmodo to delete machine learning models and algorithms that had been trained on student data obtained without proper consent. For any EdTech company building AI-powered features, this is not a hypothetical risk. If the underlying training data was not properly authorized under the school official exception — or if school authorization was defective because the data was also used for commercial purposes — the FTC has now established that it will require deletion of the commercial data assets built on that foundation. The school official exception is not a passive safe harbor. It is a compliance obligation with real enforcement consequences.

The FERPA/COPPA Intersection: When Both Laws Apply (and Who's In Charge)

Before examining the current state of COPPA's school authorization framework, a correction is necessary: the FTC's 2025 COPPA Rule amendments did not create a new school authorization exception, and they did not codify the existing informal school consent mechanism into Rule text. A substantial number of compliance articles published after April 2025 have stated or implied otherwise. The actual text of the Final Rule tells a different story — one with significant implications for any EdTech product currently structured around school-provided COPPA consent.

What the 2025 COPPA Rule Actually Did (and Didn't Do)

The FTC's April 2025 Final Rule (90 FR 16977, Apr. 22, 2025) made significant amendments to the COPPA Rule — tightening the definition of personal information, adding new parental consent methods, and imposing stricter data security requirements. What it did not do was codify the school authorization exception. In the ed tech section of the preamble, the Commission stated directly: "To avoid making amendments to the COPPA Rule that may conflict with potential amendments to DOE's FERPA regulations, the Commission is not finalizing the proposed amendments to the Rule related to ed tech and the role of schools at this time."

This deferral was not an oversight. The FTC's 2024 Notice of Proposed Rulemaking had specifically proposed codifying new Rule-text definitions of "School" and "School-authorized education purpose" and creating explicit provisions for school-authorized data collection. All of those proposed provisions were dropped from the Final Rule. The Commission committed to monitor the DOE's pending FERPA rulemaking and consider revisiting school authorization after DOE finalizes its amendments.

The Standard That Currently Governs

What governs school COPPA authorization today is the same informal standard that has applied since 2000: FTC guidance contained in the original Rule's Statement of Basis and Purpose and in subsequent FAQ documents, not binding regulatory text. Under that guidance, a school may provide COPPA consent on behalf of parents only when the EdTech operator collects personal information from students "for the use and benefit of the school, and for no other commercial purpose."

The operator must still provide the school with all information required under COPPA — a direct notice describing what personal information will be collected and how it will be used, the opportunity to review and delete the child's information, and the ability to prevent further collection or use. The school's consent substitutes for parental consent only within the educational context. The moment the vendor's data use extends beyond the school's contracted purpose — into product improvement, commercial profiling, or any use that benefits the vendor rather than the school — the school's consent authorization is no longer sufficient, and the vendor must obtain direct parental consent for the additional use.

Why the FTC Deferred: The DOE Rulemaking

The reason the FTC declined to codify school authorization is the Department of Education's pending rulemaking under RIN 1875-AA15. That rulemaking proposes to amend 34 CFR Part 99 — the FERPA implementing regulations — to clarify the rules governing nonconsensual disclosures of student personally identifiable information to third parties, including EdTech vendors specifically. DOE listening sessions in 2022 surfaced significant stakeholder concern about online applications in the classroom collecting student data without parental knowledge or appropriate authorization.

Had the FTC codified a school authorization exception in its Rule before DOE finalized 34 CFR Part 99 amendments, the two regulatory regimes could have produced directly conflicting requirements. The FTC's deferral is a deliberate decision to let the FERPA rulemaking set the baseline before locking COPPA Rule text around it. For EdTech counsel, this means the operative compliance question is not "what does the COPPA Rule say about school authorization" — because the Rule says nothing, and the guidance is informal. The operative questions are what the FTC informal guidance requires and what DOE's eventual 34 CFR Part 99 amendments will require, and whether your product's school authorization architecture will survive the transition.

The Dual-Pathway Risk

The scenario that creates the highest FERPA/COPPA intersection risk is a product with two access pathways: a school-licensed version (where the school provisions student accounts and mediates data access) and a direct-to-consumer version (where students or parents create accounts independently). Many EdTech products are built this way — a classroom tool that students can also access from home, or a district-licensed platform with a companion consumer app.

The regulatory implication, confirmed by FTC guidance, is that these two pathways cannot share a single consent architecture. For the school-mediated pathway, school authorization may apply — subject to the "for the use and benefit of the school" limitation. For the direct-to-consumer pathway, there is no school involved, and COPPA requires the operator to obtain verifiable parental consent directly before collecting personal information from children under 13. A product that relies on school authorization to cover both pathways is not in compliance with COPPA, regardless of what its privacy policy says.

The practical design implication is that dual-pathway products need separate data collection flows, separate consent mechanisms, and potentially separate data stores for school-mediated and direct-consumer user sessions. The data a student generates during a school-licensed session is governed by FERPA and the school official exception framework. The data a student generates during a parent-created consumer session is governed by COPPA — with independent parental consent required before any data collection begins. Mixing these data streams into a unified analytics pipeline without separate consent coverage for each is precisely the pattern the FTC targeted in the Edmodo enforcement action.

Edmodo as Enforcement Anchor

Edmodo had school authorization. The platform operated under agreements with school districts, functioned as an LMS, and was nominally within the school official exception framework. What it did not have was clean school authorization for the commercial uses it layered on top of the educational service: behavioral profiling, targeted advertising, and the training of machine learning models on student interaction data. The FTC's position — upheld in the 2023 consent order — was that school authorization is condition-specific. It authorizes data collection for the school's educational purpose. It does not authorize data collection for the vendor's commercial purposes, even when the vendor has a valid school contract for the underlying service.

The consent order required Edmodo to delete models and algorithms developed using personal information collected from children without verifiable parental consent. Not to stop collecting data going forward — to delete the commercial AI assets already built on defectively authorized data. Any EdTech company currently training models on school-provided student data, running analytics pipelines across school and consumer data, or using school-authorized data for any purpose beyond the specific educational service contracted by the school should treat the Edmodo outcome as the roadmap for their own exposure.

UX Design Anti-Patterns That Fail COPPA

The FTC's enforcement history has produced a vocabulary of specific UX patterns that violate COPPA's verifiable parental consent requirements — not as a matter of legal theory but as cited violations in settlement orders. Epic Games' $275 million settlement (2022–2023) is the most detailed public anatomy of a COPPA dark-patterns case, and its consent-related prohibitions translate directly into UX specifications that product teams can apply. Understanding what the FTC finds actionable is more useful than understanding what it technically requires.

Category 1: Age-Gate Manipulation

An age-gate that is designed to be passed rather than to accurately identify child users fails COPPA's intent and creates direct enforcement exposure. The FTC's Epic order explicitly prohibits "design elements or default settings that lead a reasonable user to believe a choice is being made when no choice is being made, or that obscure the user's ability to make a choice." In the age-screening context, this prohibition covers:

Default birth year set to an adult year — pre-populating the year field to 1990 or using a year picker that opens at the current year and requires scrolling to reach any year that would identify a child. If the default state of your age input would cause a 10-year-old to appear to be an adult without any deliberate manipulation, the gate is non-compliant.
Date picker UX that punishes accurate input — year selectors that require 10+ scroll taps to reach a child's birth year create a friction asymmetry that effectively steers users toward misrepresentation. Courts and the FTC treat foreseeable user behavior as designed behavior.
Leading questions that reveal the "correct" answer — "Are you 13 or older to continue?" framing, particularly when combined with a large green button for "Yes" and a small gray link for "No," constitutes a leading design that does not constitute a neutral age-screening mechanism.
Single-screen age disclosure without consequence — an age field that accepts any input without triggering different consent flows for users who enter a child's age provides no actual protection and demonstrates the operator was not making "reasonable efforts" to identify child users.

Bundling COPPA consent with terms of service acceptance is one of the most common and most clearly prohibited patterns in EdTech onboarding flows. The FTC's Epic order specifically prohibits "presenting the privacy policy or terms of service in a manner that obscures or minimizes the required disclosures." Under 16 CFR § 312.5, VPC must be a deliberate, affirmative consent act — not a checkbox buried in a terms flow or a pre-checked option that a parent must actively uncheck.

Anti-patterns in this category include:

Pre-checked consent boxes — any data collection or disclosure consent that is active by default. The 2025 Rule's prohibition on bundling secondary disclosures (advertising, AI training) with primary consent makes pre-checked analytics or marketing boxes independently actionable.
Single ToS acceptance bundling privacy consent — "By clicking Agree, you consent to our Terms of Service and Privacy Policy" where the privacy policy contains consent to data collection practices. This structure does not constitute verifiable parental consent — it constitutes ToS acceptance with privacy information disclosed, which is a meaningfully different legal posture.
Consent that activates before the parent sees the notice — any collection of personal information that begins as part of the account creation flow before a separate consent screen is presented and affirmatively confirmed.

The Epic Games order drew a direct line between dark-pattern design and COPPA violations in the post-consent user experience. The order cited Epic for "making it difficult for users to understand how to cancel or undo an action, or for making consent necessary to use a feature or game mode in a way that overrides a parent's previous settings." In practice, this prohibits three post-consent design patterns that are common in subscription and freemium EdTech products:

Features that default on after consent — if a parent consents to data collection for core service use but a new feature (push notifications, profile sharing, in-app messaging) defaults to active without a separate consent prompt or opt-in, the operator has exceeded the scope of the initial consent. Each new data use beyond what was specifically consented to requires its own disclosure.
Buried or difficult consent revocation — 16 CFR § 312.6 grants parents the right to revoke consent at any time and requires operators to provide a clear mechanism for doing so. Epic was specifically cited for requiring parents to "jump through unreasonable hoops" to exercise deletion and revocation rights. A revocation path that requires submitting a support ticket, waiting for a response, and then navigating a multi-step email confirmation sequence has been treated as effectively denying the right.
Feature gates that require consent overrides — designing a product so that children cannot access core functionality unless a parent consents to data uses beyond the core service is prohibited. If a homework tool's primary features are only unlocked after a parent enables advertising data sharing, the service gate is impermissible.

The Design Review Checklist

Before launch, product teams should walk their consent flow against this minimum review list drawn from the Epic order and FTC enforcement guidance:

Does the age-input mechanism have a neutral default state that does not favor any particular age range?
Does entering a child's age route to a materially different flow (parental consent) rather than a generic error?
Is COPPA consent presented on its own screen, not bundled with ToS acceptance?
Are all consent checkboxes unchecked by default?
Is consent to secondary disclosures (advertising, AI) presented separately from primary collection consent?
Is there a clear, accessible revocation and deletion mechanism reachable within three taps from the account settings screen?
Do new features with new data uses trigger new consent prompts rather than inheriting prior consent?

Each item on that list corresponds to a cited violation in a published FTC enforcement action. The design review is not a compliance exercise — it is an enforcement-risk audit.

The most consequential change in the 2025 COPPA Rule amendments for EdTech product architecture is not a new approved VPC method or a revised privacy notice requirement — it is the categorical prohibition on bundling consent to third-party disclosure for advertising or AI training with any other consent. The operative word in the FTC's commentary is "never," and it removes the factual flexibility that operators previously used to argue their disclosure practices were integral to service delivery.

The Categorical Bar: Advertising and AI Training Are Never Integral

Under the amended Rule (90 FR 16977), operators must obtain separate verifiable parental consent before disclosing a child's personal information to third parties for any purpose that is not integral to the website or service. The Rule then explicitly defines two categories of disclosure that are categorically non-integral:

Disclosure for targeted advertising or for receiving monetary compensation related to advertising
Disclosure to third parties for training or developing artificial intelligence technologies

The FTC's use of "never" in its commentary is deliberate and load-bearing. There is no factual argument available to an operator that advertising or AI training is core to its service delivery. A personalized learning platform cannot argue that targeted advertising is essential to its tutoring functionality. A kids' content app cannot argue that sharing interaction data with a third-party AI vendor is necessary to serve educational content. The categorical nature of the bar means product counsel cannot negotiate this point in an enforcement context — the only question is whether a separate consent was obtained.

The Three UX Implications

1. A separate consent screen or toggle is required. The secondary disclosure consent must be distinct and specific — it cannot appear as an additional checkbox on the primary VPC screen, and it cannot be embedded in a data processing addendum that a parent signs as part of initial registration. The consent must specifically identify the category of disclosure (advertising or AI training), the third parties who will receive the data, and the purposes for which they will use it. This is a product design requirement, not just a legal drafting requirement: your consent architecture needs a second, distinct consent flow for secondary disclosures.

2. The service gate cannot depend on consent to these uses. The amended Rule explicitly requires that operators give parents the option to consent to data collection and core service use without consenting to disclosure for advertising or AI training. Under the Gibson Dunn analysis of 90 FR 16977: "An operator must give the parent the option to consent to the collection and use of the child's personal information without consenting to disclosure of his or her personal information to third parties." A product flow that denies core service access to children whose parents declined secondary disclosure consent is non-compliant — the secondary consent must be genuinely optional.

This is the anti-bundling rule that directly prohibits the common "accept all or leave" data consent pattern. If your product's business model depends on advertising revenue from child users, you cannot design a consent flow that conditions educational access on advertising consent. Parents who decline advertising consent must still receive the core service.

3. Timing is flexible — feature-triggered consent is permitted. The FTC clarified in its Rule commentary (per the Data Protection Report analysis) that operators are not required to collect secondary disclosure consent at registration. Operators "could obtain parental consent during the initial verifiable parental consent flow or at a later time, such as when a child seeks to interact with a feature that implicates third-party sharing." This timing flexibility enables a progressive disclosure UX pattern: collect primary VPC at registration, then trigger secondary consent only when a child first encounters a feature (e.g., a recommendation engine or teacher-sharing tool) that requires third-party disclosure.

The progressive disclosure approach reduces upfront consent friction and improves completion rates for the primary VPC flow — parents are not confronted with complex secondary disclosure language before they understand what the product does. The tradeoff is that the feature must be hard-gated until secondary consent is received: a child cannot use the sharing or advertising-adjacent feature in "try-it-first" mode while secondary consent is pending.

The Internal AI Development Gap

The 2025 Rule's AI training consent requirement applies specifically to disclosures to third parties for AI development. Operators using children's data internally to develop their own AI features — a personalized tutoring algorithm trained on their own user data, for example — appear to face a different regulatory analysis, because the specific third-party disclosure rule does not expressly cover first-party AI development.

This gap is real but should not be treated as a safe harbor. The FTC's enforcement posture in the 2025 rulemaking comments signaled expansive interest in AI use of children's data, and the regulatory gap between internal and external AI development may be addressed through future rulemaking or enforcement. EdTech companies building proprietary AI features on child interaction data should document their legal basis for that use carefully and monitor FTC guidance for developments in this area.

A note on terminology: "targeted advertising" for COPPA purposes references the behavioral advertising definition in § 312.2 — advertising based on the monitoring of a specific individual's online activities over time. Contextual advertising (ads based on the page content rather than the user's profile) does not fall within the separately-consented category and remains available under the internal-operations carveout. Operators whose advertising partners argue that their product is "contextual" should verify that claim against the § 312.2 definition before relying on it.

COPPA compliance is not a one-time consent event at account creation — it is a lifecycle obligation that runs from the moment of first data collection through the deletion of the last record. The 2025 Rule amendments formalized the retention and deletion requirements that were previously implied by COPPA's general principles, and the FTC's enforcement record has made clear that the deletion side of the consent lifecycle is independently actionable. Building the consent lifecycle into your product architecture from the start is significantly cheaper than retrofitting it under enforcement pressure.

The Three Parental Rights

Under 16 CFR § 312.6, parents have three distinct rights that must be supported by operational UX flows — not just acknowledged in a privacy policy:

1. The right to review. On request, operators must provide a parent with a description of the specific types or categories of personal information collected from their child and a means of reviewing that information. "A description of categories" is a lower threshold than providing a complete data export, but "a means of reviewing" the information suggests more than a list of data types — it implies some form of access to the actual records. At minimum, a compliant review flow should allow a parent to see what categories of data exist, receive a summary of the data held, and request a fuller export if they want it. The verification requirement applies: the operator must take reasonable steps to confirm the requestor is actually the child's parent.

2. The right to revoke consent. Parents may at any time refuse to permit the operator's further use or future online collection of personal information from their child. The operator must provide a clear mechanism for revocation that is reachable without contacting support. Revocation does not require the operator to delete data already collected (that triggers the deletion right), but it does require the operator to stop collecting and using data from that child prospectively. Products should design for a clear "revoke consent" action in account settings that immediately halts collection and queues the account for restricted-mode operation.

3. The right to delete. On parental request, operators must delete the child's personal information from their systems and direct any third parties who received that information to delete it as well. The deletion right is triggered by the parent's request — not automatically by account closure or inactivity. Operators must maintain a deletion request mechanism that is accessible, responsive, and non-burdensome.

The Epic Games Deletion-Friction Standard

The FTC v. Epic Games settlement (2022, $275 million) established that deletion UX difficulty is independently actionable as a COPPA violation — not merely an inconvenience or a secondary issue behind the primary consent failures. The FTC alleged that Epic "required parents who requested their children's personal information be deleted to jump through unreasonable hoops, and sometimes failed to honor such requests." This allegation was cited as a distinct COPPA violation in the settlement alongside the dark-patterns and consent failures.

What does "unreasonable hoops" look like in practice? While the FTC has not drawn a bright line between acceptable verification and excessive burden, the enforcement record suggests the following patterns cross the line:

Routing deletion requests exclusively through a generic support ticket queue with no dedicated deletion workflow
Requiring parents to call a phone number during business hours as the only deletion mechanism
Multi-step email confirmation sequences that expire if not completed within a short window
Requiring parents to submit documentation (birth certificate, guardianship papers) for routine deletion requests absent specific grounds
Failing to acknowledge deletion requests or confirm completion within a reasonable timeframe

A compliant deletion flow should be accessible within three taps from account settings, confirm receipt automatically, complete within a defined and disclosed timeframe, and send a confirmation to the parent when deletion is done. The verification step — confirming the requestor is the parent — should be proportionate: the same identity confirmation used for the original VPC is generally sufficient for deletion requests from the same contact information.

The Written Retention Policy Requirement

The 2025 Rule amendments codified a retention limit in 16 CFR § 312.10: operators may retain children's personal information only as long as is reasonably necessary to fulfill the specific purpose for which it was collected. More specifically, operators must now establish, implement, and maintain a written data retention policy that specifies:

The purposes for which children's personal information is collected
The business need for retaining the information
A specific timeframe (not an open-ended "as long as necessary") for deletion

This written policy must be disclosed in the operator's online privacy notice — it is not an internal compliance document. Engineering teams need to implement automated deletion workflows that honor the disclosed timeframes, because the policy's public availability means the gap between stated timeframe and actual practice is discoverable by the FTC without any investigative effort beyond reading the privacy notice.

The Third-Party Deletion Gap

A compliance gap that the 2025 Rule leaves partially unresolved involves data already shared with third parties when a parental deletion request arrives. The amended Rule requires operators to "take reasonable steps to determine" that third parties will maintain adequate data security and to obtain written assurances of security measures from vendors — but it is largely silent on what happens to information already shared with third parties when a parent requests deletion. The Rule addresses forward-looking restrictions more clearly than retroactive deletion across third-party recipients.

Practically, this means your vendor contracts are the primary enforcement mechanism for third-party deletion obligations. Service agreements with analytics vendors, AI providers, and advertising partners should include specific deletion obligations, response timeframes, and confirmation requirements. When a parent requests deletion, you need a documented process for notifying each third-party recipient and tracking their compliance — and if a vendor's contract doesn't include deletion obligations, you have a compliance gap that COPPA's text may not require you to close but that the FTC's enforcement posture suggests you should address proactively.

The enforcement penalty ladder for COPPA violations in 2024–2025 is steep: FTC v. Cognosphere ($20 million, January 2025) for collecting children's data without parental consent after gaining actual knowledge of child users; FTC v. Epic Games ($275 million, 2022–2023) for dark-pattern consent flows and deletion friction; FTC v. Disney ($10 million, 2025) for failing to designate child-directed videos as "Made for Kids," resulting in collection and sharing of children's data without consent; FTC v. Apitor ($500K, 2025) for SDK-driven geolocation disclosure to an advertising analytics provider. These are not isolated enforcement events — they reflect the three highest-frequency triggers in recent COPPA actions, which your compliance program should prioritize closing first.

This checklist is built from the 2025 Rule requirements, the Epic Games consent order, and the enforcement-trigger pattern across 2024–2025 FTC actions. Each item maps to a cited or implied violation in the enforcement record.

1. SDK disclosure audit completed. Every third-party SDK, vendor API, and analytics integration in the product has been evaluated for data collection and disclosure behavior. The audit is documented. SDKs that disclose children's PI to advertising or AI training purposes are either removed or covered by separate consent. (Enforcement anchor: Apitor $500K, Disney $10M)
2. Directed-to-children determination documented. The multifactor analysis under the 2025 Rule's expanded criteria is in writing, signed off by counsel, and includes a review of marketing materials, user reviews, and comparable service demographics. (Enforcement anchor: all recent COPPA actions)
3. VPC method selected, justified, and matched to disclosure profile. If the product discloses PI to third parties for non-integral purposes, email-plus and text-plus are eliminated. The selected method is documented with the rationale. (Regulatory anchor: 16 CFR § 312.5)
4. Email-plus eligibility confirmed or escalated. If email-plus is the selected method, the SDK disclosure audit confirms no disqualifying third-party disclosures. If there are disqualifying disclosures, the method has been escalated to KBA, credit/debit card, government ID, or another eligible method.
5. Separate consent screens for advertising and AI training disclosures. Secondary disclosure consent is presented on its own screen, not bundled with primary VPC or ToS acceptance. The secondary consent screen specifically identifies disclosure purposes and third-party recipients. Core service access does not depend on consent to these uses. (Regulatory anchor: 90 FR 16977)
6. Age-screen neutrality verified. The age input has a neutral default state. Entering a child's age routes to a parental consent flow. The age screen does not visually or structurally favor any particular age range. (Enforcement anchor: Epic Games consent order)
7. Consent not bundled into ToS. COPPA consent is presented on a dedicated screen with an affirmative action. Pre-checked boxes are absent. ToS acceptance and privacy consent are separate flows. (Enforcement anchor: Epic Games consent order)
8. Deletion flow accessible and non-burdensome. The parental deletion mechanism is reachable within three taps from account settings, acknowledges requests automatically, completes within a disclosed timeframe, and sends a confirmation. No support-ticket-only routing. (Enforcement anchor: Epic Games $275M)
9. Written retention policy published in privacy notice. The policy specifies collection purposes, business need, and specific deletion timeframes for each data category. Engineering has implemented automated deletion workflows to honor those timeframes. (Regulatory anchor: 16 CFR § 312.10)
10. Safe harbor program status assessed. If seeking ESRB Privacy Certified or kidSAFE certification, the assessment reflects the 2025 Rule's heightened safe harbor oversight requirements. Certification is tracked as a compliance tool, not a substitute for actual compliance.

Safe Harbor Programs: What They Cover (and What They Don't)

FTC-approved COPPA safe harbor programs — primarily ESRB Privacy Certified and kidSAFE — provide participating operators with a compliance presumption against FTC enforcement. If you are certified and a complaint is filed, the FTC will initially look to the safe harbor program's own oversight and disciplinary process rather than initiating a direct enforcement action. For EdTech companies with limited legal staff, that presumption has real operational value.

The 2025 Rule amendments imposed new oversight obligations on safe harbor programs that make the presumption more conditionally reliable. Programs must now: publicly list all subject operators and certified services, submit detailed compliance reports to the FTC including consumer complaints, and update operator lists every six months. This increased transparency means that a lapsed or non-renewed certification is now more visible — and the FTC's enforcement posture is less likely to treat an expired certification charitably.

Critical limitations to understand before pursuing certification:

State attorney general enforcement is not covered. The safe harbor presumption applies to FTC enforcement actions. State AGs can independently enforce COPPA, and many state privacy laws (California, Texas, Virginia, and others) incorporate COPPA standards or create parallel children's privacy obligations. ESRB or kidSAFE certification does not create a presumption in state enforcement proceedings.
The presumption is rebuttable through the program's own process. If the safe harbor program's independent assessment finds compliance failures, its disciplinary process can result in decertification — which ends the presumption and may itself flag the operator to the FTC.
Certification does not substitute for actual compliance. The program assesses compliance with its guidelines, which are substantially similar to the COPPA Rule but not identical in every respect. Operators should treat certification as a compliance tool and audit mechanism, not as a substitute for maintaining independent compliance documentation.

For the specific scope and current certification requirements of ESRB Privacy Certified and kidSAFE — including whether a particular EdTech product category or AI-powered feature is eligible for certification — operators should consult the programs' current program guidelines directly. Scope and eligibility criteria are updated to reflect regulatory changes and should not be assumed from prior certification cycles.

A note for EdTech teams finalizing their compliance program: the FTC published a policy statement on age-verification technologies in February 2026 (FTC.gov/news-events/news/press-releases/2026/02/) that may contain updated enforcement postures on age-verification methods relevant to VPC implementation. The statement was not retrieved in time for this article and operators should consult it directly when finalizing their VPC method selection.

Promise Legal helps EdTech companies design COPPA-compliant consent flows and defend against FTC enforcement. Contact us to discuss your compliance stack.