Decision brief · implementation blueprint · risk register
A role-based playbook for preparing products, architecture, governance and investment decisions for the proposed EU KIDS Act—without hard-wiring a draft into your stack.
COM(2026) 681 final
Proposed 17 September 2026
2026/0286(COD) · procedure ongoing2
Primary-source review: 2026-10-08
All cards shown.
Prepare for the proposal. Continue meeting the laws that already apply.
Fund capabilities that remain useful as the text changes: configurable eligibility rules, minimal-data assurance, youth-safe defaults, accessible appeals and evidence of control effectiveness. Keep methods and providers replaceable. Do not confuse “15+ can hold this account” with “18+ is an adult,” or either with consent or parental responsibility.
Approve scoped discovery, privacy-preserving architecture and safety improvements now. A prototype is not a compliance certificate. Do not use the unfinished KIDS Act as a reason to postpone applicable GDPR or Digital Services Act duties; the 2025 DSA minors guidelines are guidance, not a separate law or compliance guarantee.789
Classify services and product surfaces—not just company names or app-store categories.
Article 6 gates accounts where specified risky features are present. Separate account eligibility from the broader safety duties in Articles 8–13.1
Games and gaming platforms are expressly included. Map Article 15, including under-13 guardian-tool access and the specific controls it imports—not a blanket 15+ gameplay ban.1
Article 16 addresses age ratings, age-inappropriate access and purchases, and the EU assurance solution. Store compliance does not automatically discharge the underlying service’s duties.1
Article 29(6) concerns sharing an age signal already obtained through compliant assurance, with consent. Do not invent a universal duty to collect everyone’s age or an automatic safe harbour.1
Article 14 addresses dependency risks, testing and guardian tools. The default-off rule specifically concerns embedded AI features. A narrowly task-bound assistant is not automatically a general conversational chatbot.1
Article 2(4) lists specific service-level exclusions, including certain nonprofit repositories and open-source developing/sharing platforms. It is not a blanket exemption for nonprofit status, educational branding or any open-source app.1
No general SME exemption. Article 14(1)(f) exempts micro/small AI providers only from the post-market monitoring duty in that point—not from pre-market testing or all safety obligations.1
Article 2 covers relevant services offered to recipients located or established in the EU, irrespective of provider establishment; AI has a placing-on-market/putting-into-service test. Review exclusions against the actual service. Independently map existing EU and national obligations—KIDS readiness is not the whole legal analysis.178
A draft-to-control translation—not an enacted checklist. Patterns and owners are recommendations.
Article 7 permits a narrow child-video route for ages 3–12 through a guardian’s own account, not a child account: qualified service, protective conditions and at most one hour daily. It ends at 13.1
Article 6(2) permits a supervised account: guardian tools always on, a daily limit no greater than one hour, and guardian contact approval and contact limits. This is a defined exception, not a general waiver.1
Scope key: Article 8 is the cross-service safety baseline. Articles 9–13 address social/video services; Article 14 also imports selected controls for AI, including spending safeguards. Article 15 imports specified controls for games, and Article 16 covers stores. Consult the full wording and exceptions, including guardian tools and accessible complaints. Existing DSA restrictions on profiling-based ads to minors remain a separate baseline where applicable.18
Separate proof validity, the age claim and the policy decision. The design below is a recommended pattern.
An unsuccessful 18+ claim does not prove under-15 status. A proof of adulthood does not prove parental responsibility.1612
The dedicated Commission profile uses OpenID4VCI for issuance, ISO mDoc as the underlying attestation format, and W3C Digital Credentials API / OpenID4VP presentation paths. ZKP presentation currently uses the Digital Credentials API; the verifier must also validate the accepted circuit. The profile supports optional age-over-NN attributes but focuses on 18+: prove actual 13/15 support and boundary behaviour in the chosen implementation.4
Do not infer adulthood or childhood from an outage. Keep the restricted action unavailable, offer bounded retries and any legally acceptable alternative, and preserve safe access to unaffected content. Include accessible support and appeal.
Keep a valid “threshold not met” result distinct from invalid or indeterminate evidence. Test false accepts, false rejects, disability access, shared devices and guardian abuse. An adult credential is not a parental-responsibility credential.16
Re-evaluate only what the retained signal actually proves. A new threshold may require a new proof; do not infer a detailed age band or collect identity evidence merely to make future policy changes convenient.
These are internal planning phases, not statutory deadlines. Each phase ends with a testable decision.
Create an article-level tracker: source version, proposed/current status, interpretation, scope, owner and open question. Review current GDPR/DSA duties separately; record the feedback-date inconsistency.1378
Map EU services, minors’ pathways, account types, game functions, store/OS signals and AI features. Test exclusions against the service, not its marketing label.
Name an executive risk owner and accountable cross-functional lead. Stop unsupported “KIDS Act compliant,” “anonymous by design” and “certified” claims.
Scope heatmap, current-control gaps, source register, retention inventory and funded discovery brief.
Specify the proof adapter and minimal signal contract. Threat-model replay, wrong-threshold proofs, issuer trust, credential lending, correlation and outages.
Prototype youth-safe defaults, guardian permissions and eligibility behind versioned policy. Keep a safe browsing route separate from restricted actions.
Assess DPIA necessity and complete it where GDPR Article 35 requires; involve privacy, accessibility and child-safety expertise. Test the proof/entitlement boundary rather than only a happy-path demo.6712
Testable reference flow, privacy assessment, failure-state UX, evidence-minimising telemetry and written acceptance criteria.
Test more than one plausible route where available. Verify exact thresholds, production trust and provider substitution; do not mistake a demo trusted list for authorisation under the proposed scheme.
Pin app/server/profile versions; validate device and session binding, accessibility and fallback behaviour. The Commission production checklist is a starting point, not a finished deployment or certification.412
Build the migration plan around Article 6(4): six months after application to identify existing under-15 account holders, with disablement for underage or unresolved accounts. Apply Article 32(2)’s high-confidence minimum-age exception separately from Article 32(3)’s adulthood exception. Review any supervised-account transition with counsel; prepare complaints, rollback, support and deletion.1
Ship current-law safety improvements when justified. Claim readiness for new obligations only against settled scope, approved methods, tested implementation and an accountable legal review.
COM(2026) 681 final; 2026/0286(COD), ordinary legislative procedure, Article 114 TFEU. Procedure remains ongoing.12
The updated FAQ says midnight Brussels time. The Commission announcement still contains 26 November elsewhere on the same page. Treat the live submission portal as the operational check.3
No analyst forecast is used as a deadline. Definitions, methods, delegated rules and timing remain subject to the legislative process.2
The draft specifies entry into force 20 days after Official Journal publication; general application six months later. Article 5 starts at entry into force; Articles 33 and 35 at +12 months. Article 6(4)’s existing-account deadline is six months after application. Bracketed wording and internal references need review before calendaring.1
A shared programme fails when every function waits for Legal—or assumes Product owns all of it.
Eight questions prevent premature architecture and false certainty.
Map the current legal baseline, proposed definition, territorial test and exclusions. Article 34 uses distinct DSA, AI Act, national game and GDPR enforcement routes. Match the duty to its route; a company-level label or universal “6% fine” assumption is not enough.178
Article 29(2) requires the certified EU route for Article 6; 29(4) permits alternatives for specified duties only if Articles 27–28 are met. Resolve ZKP/fallback conflicts and verify certification rather than assuming blueprint participation is approval.14
Check provenance, purpose, consent where required, trust, expiry and exact threshold. The draft’s OS signal-sharing rule is not a universal waiver of downstream responsibilities.1
Define safe degradation, free and accessible complaints, verified guardian recovery and abuse protections. Unknown is neither adult nor underage; a valid signature alone does not authorise access.
Version thresholds, actions and jurisdictions. Reuse a retained signal only where it proves the new requirement; request new proof when necessary, not a richer identity profile in advance.
Build a scoped cost model. A per-check estimate is not the cost of a child-safety programme.
Estimate engineering, legal/privacy review, security testing, accessibility, integration and support separately. Add provider minimums, retries, ongoing monitoring and applicable audit or supervision costs. Compare offers using the same volumes, assurance route and service scope—not unrelated startup-wide figures.
Illustrative scope continuum; not a measured cost range.
The Commission’s manual illustrates automated checks at €0.01–€0.05, compared with €1–€5 for current approaches. It is not a supplier tariff, audited benchmark or end-to-end budget, and the page does not establish your volume, integration or support costs. Obtain scoped commercial quotes.5
Use strong youth-safe defaults broadly where appropriate. Reduce product fragmentation; assess access, expression, revenue and usability effects. Broad age verification is not automatically the least intrusive choice.
Share a control architecture but vary justified rules by jurisdiction. Budget for legal updates, localisation, QA and support. Test conflicts rather than assuming one jurisdiction’s age rule can stand in for another’s.
Redesign, remove or lawfully limit high-risk features when the economics or safety case fails. Check residual obligations and user rights; renaming a feature is not a scope strategy.
Spend first on capabilities you can demonstrate: policy evaluation, minimal-data assurance, safe defaults, appeal and deletion. Price certification and operational responsibilities explicitly. Preserve provider substitution; do not treat “EU blueprint” as proof that a vendor is authorised or your deployment is compliant.
Primary proposal text reviewed. Legal summaries, technical documentation and recommendations have different evidential status.
COM(2026) 681 final, 17 September 2026. Operative articles take priority over explanatory summaries; the draft contains placeholders and inconsistent internal cross-references.
Full proposal on EUR-Lex ↗2026/0286(COD), ordinary legislative procedure, Article 114 TFEU. Ongoing procedure is not an adoption timetable.
Legislative procedure ↗FAQ and current announcement CTA say 3 December; the announcement body also retains 26 November. The live form was not text-readable in this review.
Commission FAQ ↗Current architecture and AV Profile: ZKP, mDoc fallback, optional thresholds and incomplete implementation. Technical requirements are not the final KIDS Act.
Architecture specification ↗Retains “ZKP upcoming” wording superseded by newer technical material. Its cost comparison is an illustration, not a procurement benchmark.
Commission manual ↗Age-assurance principles: necessity, proportionality, effectiveness, rights, purpose limitation, data minimisation and accountability.
EDPB statement ↗Articles 5–6, 8, 25, 32, 35 and 83 support the privacy baseline, distinct consent rule, risk assessment and enforcement discussion.
GDPR on EUR-Lex ↗Article 28 protects minors on covered platforms and does not itself require extra data collection to identify children; check scope and Article 19. Articles 52 and 74 address relevant fines.
DSA on EUR-Lex ↗Commission guidance for implementing Article 28. Following it is not an automatic finding of compliance.
Guidelines publication ↗Provider-associated technical analysis published 10 March 2026, with an April update. Findings concern the examined versions; they do not establish the state of every later release.
Read the original analysis ↗A critique of access control, exclusion and the limits of cryptography. Treat it as a stakeholder argument, not a regulator finding or a universal claim about every ZKP implementation.
Read the EFF critique ↗Operational hardening, conditional risk assessments and release history. Neither a demo nor the published checklist constitutes deployed security validation.
Production checklist ↗The March 2026 Yivi analysis identifies problems in the versions it examined; the official project has subsequent releases and production guidance. Neither “still broken” nor “now fixed” follows without version-pinned retesting.1012
The Commission targets threshold-only disclosure and unlinkability. Civil-society critics question exclusion, circumvention and broader access-control effects. Test metadata, shared-device and issuer/verifier-correlation risks; ZKP alone does not settle the product or rights questions.461112
Current production guidance still names device-integrity services such as Play Integrity and App Attest. Evaluate supported devices, users without standard ID, accessible alternatives and false rejections. Do not claim all platform dependencies have disappeared.12
The games definition is broad, but duties must be mapped article by article. Likewise, the draft’s screenshot/download protections should not be presented as a technical guarantee against another device photographing a screen. Document enforceable controls and residual risk.1