Article 28 Of The Digital Services Act

Article 28 of the Digital Services Act requires online platforms accessible to minors to use appropriate and proportionate measures to protect children’s privacy, safety, and security. It does not prescribe one mandatory technical method, but it creates an enforcement standard that platforms must meet when age-restricted services are involved.

Expanded Definition

Article 28 of the Digital Services Act is a platform governance obligation, not a technical control standard. It requires online platforms accessible to minors to apply appropriate and proportionate measures that reduce privacy, safety, and security risks without assuming one universal implementation model. In practice, that means the compliance question is not simply whether a platform uses age gates, but whether its safeguards are suitable to the service design, data flows, and foreseeable harm profile. Definitions vary across vendors and policy commentary on what counts as “appropriate” and “proportionate,” so organisations should treat the article as a risk-based obligation that must be evidenced through design choices, testing, and documentation. It is often discussed alongside child safety, data minimisation, and secure-by-design expectations in broader digital governance. For adjacent security control language, the NIST SP 800-53 Rev. 5 control catalog helps translate policy intent into measurable safeguards, especially around access control, data protection, and system integrity. The most common misapplication is treating Article 28 as a simple age-verification checkbox, which occurs when teams deploy a gate without assessing whether the underlying service still exposes minors to unnecessary collection, profiling, or unsafe interactions.

For broader governance context, NIST’s control language in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful when teams need to map policy obligations into operational safeguards.

Examples and Use Cases

Implementing Article 28 rigorously often introduces product friction, requiring organisations to weigh child protection goals against user experience, data minimisation, and engineering complexity.

• A social platform limits default discoverability for accounts likely to be used by minors and documents why those defaults are proportionate to the service’s risk profile.
• A gaming service restricts direct messaging, location sharing, or friend suggestions for younger users after assessing where harassment or grooming risks are highest.
• An app marketplace or content platform redesigns consent flows so minors are not nudged into unnecessary data collection before access to core features.
• A trust and safety team uses lessons from the Emerald Whale breach to understand how weak access and oversight can magnify downstream exposure when platform controls are poorly enforced.
• Security teams apply the logic from CI/CD pipeline exploitation case study to ensure age-related safeguards are not bypassed through rushed release workflows or misconfigured feature flags.

Operationally, teams often pair these measures with control baselines from NIST SP 800-53 Rev 5 Security and Privacy Controls to show that protective intent is translated into auditable implementation.

Why It Matters in NHI Security

Article 28 matters to NHI security because platforms that serve minors often depend on complex service accounts, automation, recommendation systems, and API integrations to enforce policy. If those NHI pathways are overprivileged or poorly governed, child-safety controls can fail silently, exposing minors to data collection, contact risks, or inappropriate personalization. NHIMG research shows that 97% of NHIs carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes policy enforcement only as strong as the identities behind it. When Article 28 is implemented without visibility into those identities, a platform may appear compliant in the UI while its backend still permits unsafe access patterns. The same governance gap can arise when secrets are embedded in build systems or configuration, as seen in the Millions of Misconfigured Git Servers Leaking Secrets research. For the underlying identity risk posture, NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. Organisations typically encounter the compliance and security gap only after a harmful interaction, incident report, or regulator inquiry, at which point Article 28 becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What do IAM teams get wrong about trusted digital services?
• How should organisations govern reusable digital identity across multiple services?
• How should teams govern agentic AI when the model can act across multiple tools and services?
• How should financial services teams use IAM to support digital growth?