Age Gating Services

Age-Gating Implementation for Online Services

Overview

Age-gating is the practice of restricting or adapting access to an online service based on the user's age. It serves as the enforcement mechanism that translates age verification results into access control decisions. Age-gating can take the form of a hard gate (complete denial of access below a specified age), a soft gate (modified experience with reduced features or enhanced protections for younger users), or an adaptive gate (progressively adjusting the service experience based on age brackets). Effective age-gating must balance child protection, user experience, accessibility, and compliance with GDPR Art. 8, COPPA, the UK Online Safety Act 2023, the EU Digital Services Act Art. 28, and the UK AADC Standard 3.

Types of Age Gates

Hard Gate — Complete Access Denial

Description: Users below a specified age are entirely prevented from accessing the service.

When to Use:

• Age-restricted products and services regulated by law (gambling: 18+, alcohol sales: 18+/21+, adult content: 18+)
• Services where the risk to children cannot be adequately mitigated through design measures
• Where the business model is fundamentally incompatible with child safety (e.g., real-money trading, cryptocurrency exchanges)

Implementation Requirements:

• Display a clear message explaining why access is denied: "This service is only for people aged 18 and older"
• Do not collect or retain the personal data of users who are denied access (beyond what is needed for the gate)
• Provide information about alternative age-appropriate services where possible
• Do not use the denied user's data for any purpose including analytics

Regulatory Basis:

• UK Gambling Act 2005: Age verification mandatory for remote gambling operators
• UK Online Safety Act 2023 Section 11: Providers must prevent children from encountering primary priority harmful content
• EU DSA Art. 28(1): Online platforms accessible to minors must implement age-appropriate measures

Soft Gate — Modified Experience

Description: Users identified as below a certain age are permitted access to the service but with modified features, enhanced privacy protections, or restricted content.

When to Use:

• Services with mixed audiences (adults and children)
• Services where children benefit from access but require additional protections
• Educational platforms, social media platforms, and content-sharing services

Implementation:

• Define age tiers with specific feature sets for each tier
• Apply the UK AADC "high privacy by default" standard for child users
• Disable features that pose elevated risks to children (direct messaging with strangers, public profiles, behavioural advertising)
• Enable features appropriate to the age group (moderated forums, educational content, age-appropriate recommendations)

Example (BrightPath Learning):

Adaptive Gate — Progressive Access

Description: The service dynamically adjusts the user experience based on the estimated or verified age of the user, applying progressively fewer restrictions as the user ages.

When to Use:

• Services designed for long-term user relationships where the user will age through multiple tiers
• Platforms that want to provide a seamless experience without sharp access changes

Implementation:

• Define age-linked feature unlocking schedule
• Notify the user (and parent, if applicable) when new features become available due to ageing
• Require re-verification of age at key threshold transitions (e.g., when a user reaches 13, 16, or 18)
• Document the rationale for each feature unlock in terms of the child's best interests

Neutral Age Prompt Design

A neutral age prompt collects the user's age without signalling the "correct" answer or the age threshold being applied. This is critical to preventing trivial circumvention.

Design Principles

1. Do not reveal the threshold: The prompt must not indicate what age is required. Avoid: "You must be 13 or older to use this service. Enter your date of birth." Instead: "Enter your date of birth."

2. Use a date-of-birth field, not an age field: Date of birth is harder to game than a simple "How old are you?" field, which children can answer with any number above the threshold.

3. Use a scrollable date picker with a neutral default: The date picker should not default to a date that suggests the "correct" answer. Default to no selection or to the current date (which would result in age 0, prompting a genuine entry).

4. Do not provide immediate feedback: If the user enters a date that makes them below the threshold, do not immediately display "You are too young." This teaches the child to re-enter with a false date. Instead, complete the registration flow and then inform the parent.

5. Implement cooling-off periods: If a user is denied access due to age, set a cookie or device fingerprint that prevents immediate re-attempt with a different date. A 24-hour cooling-off period is a common minimum.

6. Do not ask leading questions: Avoid "Are you 13 or older?" which tells the child exactly what to say. Use "What year were you born?" or "Enter your date of birth."

ICO Guidance on Neutral Prompts

The ICO's Age Assurance guidance (published alongside the AADC) states: "If you use age self-declaration you should not design it in a way that encourages, or makes it easy for, a child to input a false age. Your age gate should not present the age required, or make it obvious what a child should enter to circumvent the gate."

COPPA FTC Guidance

The FTC has stated in enforcement actions (e.g., Musical.ly/TikTok 2019) that age gates must be designed so that "the age screen does not encourage the child to enter a false age." The FTC views a non-neutral age gate as evidence of actual knowledge that the service is collecting data from children.

Circumvention Prevention