COPPA, Kids' Platforms and Device Signals

Children’s platforms have the same abuse problems as everyone else, and some extra ones. Edtech products get bot signups and credential sharing. Kids’ games deal with account farming, stolen accounts, chat spam and fraudulent in-app purchases. The protections that work elsewhere, like recognizing a returning device or spotting automation, rely on persistent identifiers. In the United States, the Children’s Online Privacy Protection Act treats those identifiers as children’s personal information.

This post covers where device signals fit under COPPA, the exception fraud and security work may rely on, and how to set up collection so it stays inside that exception. It’s an engineering guide, not legal advice. COPPA questions are fact-specific, so take your design to counsel.

Who COPPA applies to

COPPA applies to operators of websites and online services directed to children under 13, and to general-audience operators with actual knowledge that they collect personal information from a child under 13. Mixed-audience services, such as a game that appeals to kids and adults, usually age-screen users and apply the child rules to those under 13.

If you’re in scope, the default is verifiable parental consent before collecting personal information from a child, plus notice, data security, retention limits and parental rights to review and delete.

Persistent identifiers are personal information

The COPPA Rule’s definition of personal information isn’t limited to names and emails. It includes a persistent identifier that can be used to recognize a user over time and across different websites or online services, and gives examples such as a customer number held in a cookie, an IP address, and a unique device identifier.

A device intelligence visitorId is designed to recognize the same browser or device over time. Treat it, and the IP addresses that come with each identification, as personal information on any child-directed property.

The internal operations exception

The Rule doesn’t require parental consent when an operator collects a persistent identifier, and no other personal information, solely to provide support for the internal operations of the site or service. The definition of internal operations lists specific activities, including:

• maintaining or analyzing the functioning of the service,
• authenticating users,
• protecting the security or integrity of the user, website or online service, and
• ensuring legal or regulatory compliance.

Fraud prevention, bot defense and account protection map most naturally to the security-and-integrity item. The exception comes with strict conditions: the information can’t be used to contact a specific individual (including through behavioral advertising), to amass a profile on a specific individual, or for any other purpose.

The FTC’s 2025 amendments to the Rule, which reached their compliance date in April 2026, added transparency on top of this. Operators relying on the exception are expected to describe in their online notice the specific internal operations they collect identifiers for, and how they make sure the identifiers aren’t used for prohibited purposes. Check the final text with counsel. The direction is clear, though: if you lean on the exception, say so, specifically, in your notice.

Designing collection to fit the exception

The exception is only as good as your discipline about purpose. A few design rules keep you inside it.

Collect at security decision points only

Run identification where there’s a security decision to make: signup, login, password reset, purchase, and sending a chat message or friend request. Don’t load it on every page for analytics. Tag each call so its purpose is recorded with the event:

const prynt = await Prynt.load({ apiKey: 'pk_live_…', respectGPC: true });

// only on the actions you protect
const { requestId } = await prynt.identify({ tag: { action: 'login' } });

Keep the identifier inside security workflows

Device identifiers and events should feed fraud decisions, moderation and account protection, and nothing else. No ad targeting, no personalization, no growth analytics, no export to a marketing tool. Enforce it with access controls, not only policy: the people who query device data should be the people who handle abuse.

Turn off cross-service sharing

Prynt’s cross-customer reputation network is opt-in, and on a child-directed property it should stay off. Sharing a child’s device reputation with other services goes beyond protecting your own service, and it’s hard to square with the “no profile” condition. The same reasoning applies to email or phone enrichment: COPPA’s exception covers persistent identifiers only, so don’t send children’s contact details to an enrichment API under it.

Minimize what you store

• IP addresses. Self-hosted deployments can store truncated IPs or none (PRYNT_IP_MODE=truncate or none) when your rules don’t need full addresses.
• Account linking. Use an opaque internal user id as linkedId, never a child’s name, username or email.
• Retention. COPPA requires keeping children’s information only as long as reasonably necessary for the purpose. Set a short retention window and document why it’s long enough for abuse investigations.

Data minimization for fraud signals goes through each lever in more depth.

Make deletion easy

Parents can ask to review and delete their child’s information. Make sure a request maps to device data: erasure by linkedId removes every event and label tied to that account, and erasure by visitorId covers a device directly. Both are available in the Prynt console.

When to ask for consent instead

Some uses fall outside the exception: anything beyond security, or collection of other personal information alongside the identifier. If you need those, the answer is verifiable parental consent, and the agent can wait for it:

const prynt = await Prynt.load({ apiKey: 'pk_live_…', requireConsent: true });
// after verifiable parental consent is recorded:
prynt.setConsent(true);

For mixed-audience services, a common setup is: under-13 users get the minimal, security-only configuration; teens and adults get your standard one. Some US states have their own laws for minors that extend past 13, so check whether your audience triggers them. CCPA and fingerprinting covers the California side.

Abuse patterns worth the effort

Within those limits, device signals still catch a lot on kids’ platforms:

• Bot signups and spam accounts that flood chat or user-generated content, caught by bot, formBot and automation behavior signals.
• Ban evasion, where a removed account comes back from the same device. This matters most for safety moderation.
• Account takeover of children’s accounts, where an unfamiliar device appears together with a password reset.
• Purchase fraud, such as chargebacks from repeated accounts on one device.

Each is a security-and-integrity purpose, which is the use the exception was written for.

Checklist

1. Confirm whether you’re child-directed, mixed-audience or general-audience with actual knowledge.
2. Identify only at security decision points, with a tag stating the purpose.
3. Describe those security uses specifically in your online notice.
4. Keep the reputation network and contact-detail enrichment off for child users.
5. Minimize IPs, use opaque linkedIds, set short retention.
6. Route parental deletion requests to erasure by linkedId and visitorId.

For the broader legal picture, see is device fingerprinting legal, and the privacy page for Prynt’s defaults.