COPPA in 2026: What the New Opt-In Rules Mean for Your Product

The FTC’s updated COPPA rule went into effect on April 22, 2026, and it changed the game for any product that touches users under 13. If you’re in ed-tech, gaming, social media, or any space where kids might use your product, you need to understand what shifted. The new requirements aren’t just legal abstractions. They have direct implications for how you build consent flows, handle data, and structure your product.

We work with ed-tech companies every day, and the confusion around these changes has been significant. Let’s cut through it.

What Actually Changed

The original COPPA rule from 2013 required “verifiable parental consent” (VPC) before collecting personal information from children under 13. The 2026 update tightened the definition of what counts as verifiable consent and expanded what counts as personal information.

Here are the changes that matter most for product teams.

The “email plus” method is dead for most use cases. Under the old rule, you could send an email to a parent, ask them to reply confirming consent, and call it done. The FTC narrowed this significantly. Email-based consent is now only acceptable for internal use of the data (like maintaining the account). If you’re sharing data with third parties, displaying it publicly, or using it for targeted content, you need a higher-assurance consent method.

Biometric and health data are now explicitly covered. The definition of “personal information” now includes biometric identifiers (face geometry, voiceprints) and health-related data. If your product uses face filters, voice recognition, or collects any health information from kids, you need consent for that data specifically.

Persistent identifiers used for targeted advertising require consent. This was always somewhat implied, but the new rule makes it explicit. If you’re using device IDs, ad IDs, or cookies to serve targeted ads to kids, that requires VPC. This effectively kills behavioral advertising to children unless you have robust consent infrastructure.

Data retention limits are now mandatory. You must retain children’s personal information only as long as reasonably necessary to fulfill the purpose for which it was collected. “We keep it forever in case we need it” is no longer an option. You need defined retention periods and automated deletion.

Schools can no longer consent on behalf of parents in all cases. The school consent exception, which many ed-tech companies relied on, is narrower now. Schools can still consent for educational purposes, but the FTC clarified that this doesn’t extend to commercial purposes or features unrelated to the educational context. If your product has a “fun” social feature alongside the educational content, the school’s consent doesn’t cover the social feature.

What “Verifiable Parental Consent” Actually Means Now

The FTC outlines several acceptable methods for VPC, ranked roughly by assurance level:

Government ID verification. The parent submits a government-issued ID, which is verified against the parent’s identity. This is the gold standard but creates friction and privacy concerns about collecting parent IDs.

Knowledge-based authentication. Asking questions that only the parent would know, pulled from public records databases. Think: “Which of these addresses have you lived at?” This works but has accuracy issues and can be gamed.

Video verification. The parent records a short video confirming consent, which is compared against their government ID. This is newer and has limited adoption.

Credit card or financial transaction verification. Charging a small amount to the parent’s credit card (which is then refunded) or verifying their financial account. This creates friction but is well-understood.

Signed consent form. The parent prints, signs, and returns a consent form via mail, fax, or scanned upload. Old school but still acceptable.

For most product teams, the practical choice comes down to government ID verification or credit card verification. Both have trade-offs. Government ID verification is higher assurance but requires you to handle sensitive documents (and delete them promptly after verification). Credit card verification is simpler to implement but creates a paywall-like experience.

How to Build Compliant Consent Flows

Here’s what the technical implementation actually looks like.

Step 1: Age gate. You need to determine whether a user is under 13. A date-of-birth input is standard. Do not use a “Are you over 13? Yes/No” toggle, because the FTC has specifically called that out as insufficient. If a user enters a birthday indicating they’re under 13, you must block data collection until VPC is obtained.

Critical detail: if a user enters a date indicating they’re 13 or older, do not let them simply go back and re-enter a different date. Store the age gate response (not the actual birthday) in a session or device-level marker. This prevents the obvious workaround of kids lying about their age after seeing the gate.

Step 2: Parent contact collection. When a child user is identified, collect a parent or guardian’s email address. Send a notification to that email explaining what data you’re collecting, why, and how to provide consent.

Step 3: Consent verification. Direct the parent to your consent flow, which must use one of the FTC-approved VPC methods. The consent must be specific. You can’t ask for blanket consent to “use your child’s data.” You need to explain each category of data collected, the purpose, and any third parties who receive it.

Step 4: Ongoing rights management. Parents must be able to review the data you’ve collected, request deletion, and revoke consent at any time. This means you need a parent dashboard or at minimum a documented process for handling these requests. Automate as much of this as you can because manual processes break under scale.

Step 5: Data handling controls. Once consent is in place, your backend needs to enforce the specific consent given. If a parent consented to data collection for educational purposes but not for analytics, your systems need to respect that boundary. This often means tagging data with consent scope and filtering at the application layer.

The School Consent Exception: What’s Left

Many ed-tech companies have operated under the assumption that a school district’s agreement covers COPPA consent. That’s partially true, but the 2026 rule tightened the boundaries.

Schools can consent on behalf of parents when the data is used solely for an educational purpose. The key word is “solely.” If your product collects data for educational features but also uses that data for product analytics, recommendation engines, or any commercial purpose, the school’s consent doesn’t cover those uses.

In practice, this means ed-tech companies need two consent tracks. One for the educational use case (which the school can authorize via a contract or agreement) and one for any commercial or non-educational features (which requires direct VPC from parents).

If you’re an ed-tech company that’s been relying entirely on school agreements, audit your data flows now. Map every piece of data you collect from student users and identify which uses are purely educational and which aren’t. The non-educational uses need direct parental consent or need to be turned off for under-13 users.

FTC Enforcement: They’re Serious

The FTC hasn’t been shy about enforcement. Recent actions show a clear pattern.

Penalties are increasing. The per-violation fine is now over $50,000, and the FTC has shown willingness to calculate penalties on a per-child, per-day basis. For a product with thousands of child users, the math gets alarming fast.

The FTC is specifically targeting companies that use “dark patterns” in age gates. If your age gate is designed to make it easy for kids to lie about their age, that’s a factor in enforcement. Similarly, if your consent flow is confusing or buries important information, that’s a problem.

They’re also going after companies that collect data from children without any age gate at all, claiming they “didn’t know” their users were under 13. If your product is reasonably likely to attract child users (games, educational content, platforms popular with teens), the FTC expects you to have age-gating in place. “We didn’t know” is not a defense.

Practical Steps for Product Teams

If you’re reading this and realizing your product needs work, here’s the priority order.

First, audit your data flows. Map every piece of data you collect from users who could be under 13. Include persistent identifiers, device information, and analytics data. Most teams undercount because they forget about third-party SDKs and analytics tools that collect data independently.

Second, implement or update your age gate. Make it robust. Store the response. Don’t let users retry.

Third, choose and implement a VPC method. If you’re building this yourself, budget 4-6 weeks of engineering time for a solid implementation. Alternatively, services like Privo, SuperAwesome (now Epic Games), and AgeCheq provide turnkey VPC solutions. Using a third-party service is often faster and shifts some compliance risk.

Fourth, build the parent dashboard. Parents need to review data, revoke consent, and request deletion. This isn’t optional.

Fifth, update your privacy policy. It must clearly describe your data practices for child users, the consent process, and parents’ rights. Have legal review this.

If you’re an ed-tech company navigating these changes, this is exactly the kind of compliance-meets-engineering challenge we specialize in. We’ve helped multiple ed-tech clients build compliant consent flows that satisfy the FTC without destroying the user experience. The technical requirements are specific enough that you want engineers who’ve done this before.