Most of the world writes its children’s-privacy rules around one of two numbers. The United States built COPPA around 13 — verifiable parental consent kicks in only for data collected from children under that age. The EU wrote GDPR around a band, letting each member state set its digital-consent age anywhere from 13 to 16. Product teams have spent a decade internalising those thresholds: gate the under-13s, let the teenagers through.
India chose a third model, and it is the strictest of the three. Under the Digital Personal Data Protection Act, a child is anyone under 18, full stop — no member-state discretion, no lower teen tier. And with the DPDP Rules notified in November 2025, that principle stopped being an aspiration in a statute and became an engineering requirement with a hard clock attached. Substantive compliance, including the children’s-data provisions, lands on 14 May 2027 (India Briefing; MeitY / PIB).
If you run a platform that any Indian teenager might plausibly use — a game, a social app, an ed-tech product, a streaming service, a consumer fintech — this is not a footnote in your international-expansion deck. It is a design constraint that touches your sign-up flow, your ad stack, your analytics, and your data-retention posture, and the window to build it is measured in months, not years.
What the DPDP Act actually says about children
Two provisions do the work. Section 2(f) defines a “child” as an individual who has not completed eighteen years of age. Section 9 then attaches three obligations to that definition, and each one is more demanding than its Western analogue.
First, before processing any child’s personal data, a Data Fiduciary must obtain verifiable consent of the parent or lawful guardian. Second, the Act prohibits processing that is likely to cause any detrimental effect on the well-being of a child. Third — and this is the provision that quietly breaks a lot of business models — it prohibits tracking or behavioural monitoring of children and targeted advertising directed at them (DPDPIndia; KS Legal & Associates).
Read those together and the consequence is stark. For any user you have determined to be under 18, you cannot run behavioural profiling, you cannot serve targeted ads, and you cannot process their data at all without a verified parent standing behind the consent. There is no “teen account” middle path the way there is under GDPR. A seventeen-year-old in Mumbai is, for DPDP purposes, in the same protected category as a seven-year-old.
Rule 10: what “verifiable” now means
The Act said verifiable parental consent without saying how. The draft that circulated through 2025 left it open. The notified Rule 10 closed it, and it closed it toward hard identity assurance rather than a checkbox.
Under Rule 10, a Data Fiduciary must adopt appropriate technical and organisational measures to ensure that, before it processes a child’s data, the person providing consent is in fact an identifiable adult. It sets out two acceptable routes to that assurance. The first is to rely on details of identity and age already available with the Data Fiduciary — for an incumbent that already holds a verified adult record, that record can anchor the parental link. The second, and the one built for everyone else, is a virtual token mapped to the parent’s identity and age, issued by the Central or a State Government, or by an entity authorised by law — in practice, an Aadhaar-linked DigiLocker token (dpdpa.com Rule 10; Mondaq).
The token architecture is the elegant part. Instead of the platform collecting and storing a parent’s Aadhaar number or a scan of a government ID, the parent authenticates against DigiLocker, which issues an encrypted token attesting only the facts the platform needs — that this is a real adult, with a verified name and age — without handing over the underlying document. It is the same design instinct behind the EU Digital Identity Wallet’s age-verification flow and the broader move toward verify-once, prove-everywhere credentials: resolve a high-assurance check into a minimal, privacy-preserving signal, and don’t let the relying party hoard the raw identity.
This is a decisive move away from self-declaration. A parent clicking “I am over 18 and I consent” is exactly what Rule 10 is written to render insufficient. India has effectively arrived at the same conclusion the UK’s ICO reached when it fined Reddit and warned the market that self-declaration is not a control — only India has written the alternative into a rule with a national identity rail behind it.
The under-18 threshold is the hard part, and it comes first
Here is the trap most compliance summaries skip past. Rule 10 tells you how to verify the parent. But the parent’s verification only matters once you have already determined that the user is a child. That first determination — is the person in front of me under 18? — is an age-assurance problem, and DPDP hands it to you without a prescribed method.
That ordering has two uncomfortable implications.
The first is that you cannot scope the obligation to “kids’ apps.” COPPA’s under-13 line lets a mainstream service assume most of its users are adults and handle the occasional child as an exception. An under-18 line does not offer that comfort in a country where a very large share of the population and the internet-using base is young. If teenagers plausibly use your product, you have to be able to tell, at the point of entry, whether a given user is over or under 18 — which means age assurance stops being a niche add-on and becomes a gate every user passes through.
The second is that the accuracy demands run in both directions. Set the age check too loose and you process minors’ data unlawfully and trip Section 9. Set it too tight and you wrongly divert adults into a parental-consent flow they cannot complete, which is its own false-positive lockout problem — an adult who gets misclassified as a child and asked to produce a parent is an adult you have just lost. The 18-year boundary is also, statistically, one of the harder ones for facial age estimation to sit precisely on, which is why a serious deployment treats the region around the threshold as a place to escalate, not to guess.
The practical answer is the same layered pattern we argue for everywhere age assurance meets real traffic: a waterfall of methods rather than one universal check. Route the clear cases through low-friction estimation, and escalate anyone near the 18-year line — or anyone entering a flow where getting it wrong is expensive — to a stronger, document- or token-backed method before you either admit them as an adult or push them into the parental-consent path.
Where the token layer and the age-assurance layer meet
It is worth being precise about which problem the DigiLocker token solves and which it does not. The government token is built to verify an adult who chooses to authenticate — the parent, deliberately proving their identity and age to unlock consent for their child. It is not designed to silently classify an anonymous visitor at your front door as over or under 18. Those are two different jobs, and a compliant flow needs both.
So the architecture that actually satisfies DPDP is a chain:
- Age assurance at entry determines whether the user is likely a child. This is your estimation-or-verification layer, tuned so that the 18-year threshold escalates rather than guesses.
- If the user is a child, verifiable parental consent is triggered — the parent authenticates through a government-issued virtual token (or the fiduciary’s existing verified adult record) per Rule 10.
- The consent, and the parent-child link, are recorded in a form the fiduciary can produce on demand, while the underlying identity data stays minimised — ideally never stored as raw documents at all.
The registered Consent Manager regime under the Act (a Consent Manager is a Board-registered intermediary that manages consent on a user’s behalf) is designed to sit across step 2 and 3, giving parents a single place to grant, review, and withdraw consent (Ikigai Law). But the Consent Manager does not do your age assurance for you. Step 1 — the determination that a user is a child in the first place — remains the platform’s problem, and it is the step most teams underestimate.
The data-minimisation discipline running through all three steps is not optional polish. India’s own framework is built to avoid centralising raw identity, and the wider wave of age-verification data breaches through 2025 and 2026 is a standing reminder of why: every parent’s ID you store to prove consent is a liability you did not need to hold. The token model exists precisely so you can prove the check happened without becoming the honeypot.
The exemptions, and where they don’t save you
DPDP does carve out relief, and it is narrower than hopeful readers assume. Rule 12, read with the Fourth Schedule, exempts certain classes of Data Fiduciaries and certain purposes from the verifiable-parental-consent requirement in Section 9(1) and from the behavioural-tracking and targeted-advertising prohibitions in Section 9(3) (Tsaaro).
The clearest carve-out is for healthcare and mental-health establishments and healthcare professionals, and even that is conditioned: the exemption holds only where the processing is restricted to providing necessary health services to the child. Certain educational institutions and purposes related to a child’s safety and well-being get comparable, purpose-bound treatment. These are not blanket passes for the ed-tech or health-tech sectors; they are narrow, activity-scoped exceptions, and the moment your processing steps outside “necessary services” — into engagement optimisation, behavioural analytics, or advertising — the exemption falls away and the full weight of Section 9 returns.
For the platforms most people are actually asking about — social, gaming, streaming, general consumer apps — there is no exemption to lean on. The obligation applies in full.
The clock, and what it costs to miss it
The enforcement timeline is phased, which has lulled some teams into treating May 2027 as distant. It is not, once you account for what has to be true before it.
The Data Protection Board of India is already stood up. Consent Manager registration is expected to open around November 2026, roughly the twelve-month mark. And the substantive obligations — including the children’s-data provisions — become enforceable at eighteen months, on 14 May 2027 (Shardul Amarchand Mangaldas; Anand & Anand). If your plan is to design, build, integrate a government-token flow, wire up age assurance at entry, rebuild your ad and analytics stack to exclude minors, and validate all of it — starting in early 2027 — you have misjudged the effort.
The downside for getting it wrong is not nominal. Breaches of the children’s-data obligations carry penalties of up to ₹200 crore per instance — on the order of US$24 million — and the general schedule reaches ₹250 crore for failures of security safeguards (Vision IAS). For a global platform, the reputational exposure of being the company that profiled Indian minors after the law was clear is arguably worse than the fine.
There is a broader strategic point here too. India is not an outlier moving alone; it is the largest entry in a global convergence. The same year that produced the DPDP Rules produced Brazil’s Digital ECA, Australia’s under-16 social-media ban, and a thickening US state patchwork. Building your India stack as a one-off is a mistake; building it as one configuration of a jurisdiction-aware age-assurance and consent architecture is how you avoid re-solving the same problem every time another country draws its line.
What to build now
If you serve, or plan to serve, Indian users, four things belong on the roadmap this year rather than next.
Determine age at entry. You need a reliable, low-friction way to establish whether a user is under 18 before you process their data — accurate enough to trust, and tuned to escalate around the threshold instead of guessing. Design for the parental-consent path. Where a user is a child, you need a Rule 10-compliant flow that verifies a real parent’s identity and age through a government-issued virtual token or an existing verified adult record — not a self-declared checkbox. Minimise what you keep. Prove the check and the consent happened; do not become the store of raw parent and child identity documents that the next breach headline is written about. And segregate minors from your ad and analytics stack, because targeted advertising and behavioural monitoring of children are prohibited outright, not merely consent-gated.
Xident is built for the first two of those directly, and it is built to make the last two easier. Age-threshold classification handles the at-entry determination of whether a user clears the 18-year line, with document OCR, face match, and server-side liveness available to escalate the near-threshold and high-risk cases that estimation alone should never decide. Token-based returning-user verification and privacy-preserving age signals mean a user proves the fact once and re-presents a minimal attestation rather than resubmitting identity each time — the same minimisation logic India’s own token model is built on, which keeps you out of the honeypot business. The parental-consent rail itself (DigiLocker tokens, Consent Managers) is India-specific plumbing; Xident is the age-assurance layer that decides who has to walk down it, and interoperates with a token-based consent flow rather than duplicating it.
If you are mapping your DPDP readiness and want to pressure-test the age-assurance layer specifically — the “is this user a child” gate that everything else in Section 9 depends on — that is the conversation to have now, with eighteen months on the clock rather than eighteen weeks.
This article is for general information and does not constitute legal advice. The DPDP Rules are subject to further guidance from the Data Protection Board of India, and your obligations depend on your service, your users, and the classes and purposes involved. Validate your compliance approach with qualified Indian counsel against the notified Rules and any subsequent notifications.
