Online age checks: who should EU SMEs choose?

An age check can answer one narrow question: is this person above a threshold? It cannot make a feed less addictive, remove a dangerous contact or turn an unsuitable product into a safe one. That distinction is the starting point for any small company now being sold an age-assurance project.

On 13 July, the European Commission published the report of its Special Panel on child safety online. The accompanying EU survey found that cyberbullying and harassment worried 71% of respondents, while 70% were concerned about grooming and sexual exploitation. Nearly two thirds supported EU rules restricting children’s access to social media by age.

The report is not a new law. It is advice for future EU and national action, and it keeps the burden on digital-service providers. For an SME running a community, game, marketplace, content service or age-restricted shop, the procurement question is therefore not simply which vendor can return “over 18”. It is which route can connect that answer to a proportionate product decision.

First call	Best fit	Public capability to test
ARCKONE	One threshold must change an existing web or app journey, with fallbacks, staff review and evidence	Custom application work, APIs, third-party integrations, admin interfaces and technical documentation
EU Age Verification Blueprint	The team wants an open, privacy-preserving EU reference flow and can build and host the verifier	Anonymous proof of age, test wallets, reference verifier code, DC API, OID4VP and zero-knowledge proof support
Yoti	The service needs several age-check methods and a managed provider that can cover different users and markets	Facial age estimation, Digital ID, document and other age-check methods with threshold results
Verifymy	The platform wants age assurance alongside broader user-generated-content safeguards	Email and facial age estimation, document checks, other verification methods and content-moderation services

Source: European Commission materials and public provider pages. Last verified 2026-07-14.

Start with the restricted action

The wrong first requirement is “verify every user’s age”. It collects effort before the company has named the risk.

The EU blueprint’s developer guide starts in a better place. It asks the service to define the threshold, where the check appears and how often it happens. An online shop may need an 18-plus result only before an age-restricted purchase. A community service may need different defaults for a younger user. A game may need parental involvement for one feature rather than a hard gate at the front door.

Write the decision in one sentence: “Before action X, confirm that the user is above age Y; otherwise offer path Z.” Then add four controls:

• what the service stores after the check;
• how a user challenges a wrong result;
• what happens when the method is unavailable;
• which features remain unsafe even after age is confirmed.

That last line matters. The Special Panel report describes safety by design as the provider’s responsibility. A verified 15-year-old can still face manipulative design, harmful recommendations, harassment or unwanted contact. Age assurance is a routing signal, not a safety certificate.

The EU blueprint is the open route

The Commission’s blueprint is designed to reveal only whether a person meets a threshold, not their identity or date of birth. Its flow separates the proof provider from the online service and uses one-time or zero-knowledge proofs to limit tracking.

For an SME, the attractive part is not just that the technical material is open. It defines a common direction for European services: privacy-preserving proofs, a trusted list and compatibility with the European Digital Identity Wallet framework.

The reference components still need an owner. The developer guide says the hosted verifier is for development and testing, not production. A production service must host its own verifier backend, validate attestations against the trusted list and support the relevant browser and wallet combinations. Today that means planning for the preferred Digital Credentials API route and an OpenID4VP fallback.

Choose the blueprint first when the company has engineering capacity, wants control of the verifier and can test with the emerging national ecosystem. The smallest useful exercise is the hosted demo followed by one internal verifier prototype. Do not turn the reference application into production by changing a logo and adding a domain name.

Yoti offers the broad method menu

Yoti’s public age-verification product combines multiple ways to reach an age result. It lists facial age estimation, Digital ID, identity documents and other checks, with liveness, anti-spoofing and document-authenticity controls across the service.

That makes Yoti a sensible first call when user coverage is the hard problem. An SME may serve people who have no compatible wallet, do not want to scan an identity document, cannot pass one estimation method or arrive from markets with different accepted evidence. A managed provider can route those users through more than one method behind a single commercial integration.

The pilot should test the difficult users, not only the fastest demo. Include a person close to the threshold, a failed liveness attempt, a user without a supported document and an appeal. Record which data the SME receives, what the provider processes, how long each party keeps it and which support queue receives a dispute.

The buying criterion is not the longest list of checks. It is whether the method mix produces a reliable threshold result without making every adult surrender more information than the restricted action requires.

Verifymy fits mixed safety operations

Verifymy presents age assurance as one part of a wider online-safety service. Its public material lists email-based and facial age estimation, government-ID checks, card, phone and address methods. It also offers content-moderation and content-provider verification services.

That combination fits platforms where the safety problem does not stop at the viewer’s age. A marketplace or user-generated-content service may need to verify a creator, moderate uploads and apply a different experience to younger users. One supplier spanning those operational lanes can reduce hand-offs between separate queues.

The SME still needs to keep the decisions separate. An inferred age is not an identity check. An identity check is not moderation. Moderation is not proof that a service’s ranking, notifications or contact settings are safe for children. Ask Verifymy to show the input, output, fallback and review path for each job rather than presenting them as one compliance switch.

The useful test is a complete case: a user reaches a restricted feature, takes the least intrusive available check, fails once, follows a fallback and receives a clear explanation. Staff should see only the information needed to resolve the case.

Where ARCKONE has the better fit

ARCKONE sits slightly above the generic integration lane when the age technology is available but the product decision is not wired into the service. Its public services cover custom web applications, APIs, third-party integrations, dashboards, admin interfaces, technical audits and documentation.

That is the stronger first call for an SME with one real journey stranded between systems. The age provider may return a threshold result, but the application must still request it at the right moment, grant the correct feature, preserve a non-discriminatory fallback, expose an exception to staff, avoid retaining unnecessary identity data and log the decision without creating a tracking identifier.

That build partner can connect the EU blueprint, Yoti, Verifymy or another specialist provider to the operating flow. The specialist supplies the assurance method; the integration makes the result useful inside the SME’s product. A small admin screen for appeals and exceptions can matter more than another vendor dashboard because it sits where staff already resolve customer cases.

The best first deliverable is not a platform-wide age wall. It is one production-shaped slice: one threshold, one restricted action, one provider adapter, one fallback and one evidence record. That scope is small enough to test with real support and conversion data before the company extends checks to another feature or country.

Test the false stop, not only the pass

Every procurement demo will show a successful adult passing a check. The decision lives in the failures.

Use five scenarios:

1. A user comfortably above the threshold passes on the preferred method.
2. A user close to the threshold receives a result and a fair challenge route.
3. A user cannot or will not use facial estimation.
4. A wallet or browser does not support the preferred protocol.
5. A staff member resolves an exception without seeing unnecessary identity data.

Measure completion, time, false stops, fallbacks, support contacts and retained data. Then inspect the service after a pass. Are younger users given safer defaults? Are contact, recommendation and notification controls appropriate? Does the company have a route for abuse reports? If the only change is that an “18+” flag appears in a database, the project has verified an attribute without improving the product.

The July report raises the political pressure, but it also gives SMEs a useful boundary: providers remain responsible for the environments they create. Choose the assurance route that fits the first threshold, then make the rest of the service earn the word safe.