In practice, the OSA sets out who is in scope, requires risk assessments and safety systems, and empowers Ofcom to enforce compliance. See the primary Act for the full structure and definitions: Online Safety Act 2023 on legislation.gov.uk. (legislation.gov.uk)

The rules can also apply to services outside the UK if their service has a “UK link.” Ofcom’s scope overview explains the UK link tests and exemptions with clear diagrams. (Ofcom—Regulated services: overview of scope (PDF))

• Origins (2019): The UK Government published the Online Harms White Paper in April 2019 under then‑Prime Minister Theresa May, proposing a duty of care and a regulator to oversee online safety. (gov.uk—White Paper)
• Government response (Dec 2020): The full response confirmed a statutory duty of care and Ofcom as regulator. (gov.uk—Full government response)
• Draft Bill (May 2021): A draft Online Safety Bill was published for pre‑legislative scrutiny by a Joint Committee. (gov.uk—Draft Online Safety Bill)
• Introduction to Parliament (2022): Culture Secretary Nadine Dorries introduced the Online Safety Bill to the Commons in March 2022. (gov.uk—Press/Parliamentary materials)
• Royal Assent (2023): The Bill became the Online Safety Act 2023 on 26 October 2023. (legislation.gov.uk)
• Acceleration (2024→): From July 2024, the government prioritised fast implementation via Ofcom’s phased codes and guidance rather than reopening the statute. Ofcom is the regulator responsible for writing codes, auditing, and enforcement. (Ofcom—Roadmap to regulation)

The government’s own explainer emphasises platform duties and phased commencement, which made delivery the pragmatic path. In May 2025 ministers also issued strategic priorities to guide Ofcom’s approach. See: the official Online Safety Act explainer (gov.uk) and Ofcom’s online safety hub/roadmap (Ofcom).

• User‑to‑user services: services where content a user generates, uploads or shares can be encountered by other users. This can include public posts and features like group chats/DMs where content is shared beyond a single user. See the definition in Part 2, s.3. (legislation—s.3)
• Search services: services that search multiple websites/databases and present results. Part 2, s.4. (legislation—s.4)
• UK link: a service is in scope if any of the following apply: it has a significant number of UK users; it targets the UK; or it is accessible in the UK and there is a material risk of significant harm to UK users. Part 2, s.5; see Ofcom’s plain‑English overview for examples. (legislation—s.5, Ofcom—Regulated services overview (PDF))

Note: one‑to‑one live voice calls are exempt, but video calls and messaging content are not. Group chats and DMs can be in scope where content one user sends can be encountered by another. (See Ofcom’s overview linked above.)

For a plain‑English overview, see the government explainer (which also notes private messaging can be in scope where content is shared): (gov.uk—OSA explainer).

• Standard email and SMS/MMS.
• One‑to‑one live aural (voice) calls (including VoIP voice calls).
• Internal business/enterprise tools (closed workforce services).
• Limited‑functionality exemptions (e.g., services without user‑to‑user features).
• Recognised news publisher content itself is outside scope; user comments around it can be in scope.

Details live in Schedule 1 and Schedule 2 of the Act; Ofcom’s scope overview summarises what’s in/out and explains transitional rules. (legislation—Schedule 1, legislation—Schedule 2, Ofcom—Regulated services overview (PDF))

It doesn’t impose a general “ID for everyone.” The law is risk‑based and method‑agnostic; self‑declaration doesn’t count, but several privacy‑preserving methods do. (Ofcom: Protecting children online - codes)

It doesn’t ban end‑to‑end encryption (E2EE). Ofcom could, in theory, issue Technology Notices requiring accredited detection technology only where technically feasible; both government and Ofcom have framed this as a high bar and consulted on minimum accuracy standards. (gov.uk—OSA explainer, Ofcom—Illegal harms statement hub)

It doesn’t create blanket bans on legal speech for adults. Instead, services must apply their own terms consistently and offer tools/appeals. (gov.uk—OSA explainer)

Assess risks (illegal content; and for kids, content likely to harm) and keep assessments up to date. (Part 3 duties; Ofcom guidance and templates in its online safety hub.) (Ofcom—hub)

Design and operate systems that reduce those risks (moderation, reporting, user controls, safer defaults for children). (Ofcom—codes)

Use “highly effective” age assurance where needed (several methods are acceptable; self‑declaration is not). (Ofcom—codes)

Be transparent (clear terms, complaints/appeals) and cooperate with Ofcom audits and information requests. (Part 7 powers; see Ofcom roadmap.) (Ofcom—roadmap)

Face penalties if they won’t fix issues: Ofcom can fine up to £18m or 10% of qualifying worldwide revenue (whichever is greater) and, in severe cases, seek court‑ordered business disruption measures (e.g., payment/ads withdrawal or ISP access restrictions). (Ofcom—Enforcement guidance (PDF), gov.uk—OSA explainer)

17 March 2025: Illegal‑content duties enforceable; risk assessments due. (gov.uk—OSA explainer, Ofcom—roadmap)

25 July 2025: Child‑safety codes and age‑assurance expectations in force for services likely to be accessed by children (after a 3‑month risk‑assessment window to 24 July 2025). (Ofcom—Protecting children online)

Through 2026: Further codes (e.g., for categorised services) and transparency reporting phases roll out. (Ofcom—roadmap)

Some services face additional transparency and user‑empowerment duties based on thresholds set by secondary legislation in 2025. Broadly:

• Category 1: very large user‑to‑user services (size + functionality thresholds).
• Category 2A: large search services.
• Category 2B: sizable user‑to‑user services below Cat 1 but with risky features (e.g., DMs).

Thresholds were set by the Online Safety Act 2023 (Category 1, Category 2A and Category 2B Threshold Conditions) Regulations 2025. (UK SI 2025/226—Threshold Conditions (PDF))

Sets system-level duties for services with a UK link; it is not a tool for policing individual posts.

Core focus: illegal content and children’s safety; adults get more control tools, not new bans on legal speech.

Enforced by Ofcom, with fines up to £18m or 10% of qualifying worldwide revenue and, in serious cases, court-ordered business disruption measures.

See Ofcom’s enforcement approach and the government explainer: Ofcom—Enforcement guidance (PDF) or the gov.uk OSA explainer.

Under the OSA, services used by or likely to be accessed by children must assess risks and put systems in place that are proportionate and effective. Ofcom’s phased roadmap pushed illegal‑harms duties first, then children’s codes in mid‑2025, which is why many platforms shipped gated access at the same time. See the government explainer and Ofcom’s roadmap for dates and scope: gov.uk OSA explainer, Ofcom roadmap.

Key dates to anchor what you’re seeing: 17 March 2025 (illegal‑content duties enforceable) and 25 July 2025 (children’s codes and age‑assurance expectations in force). See Ofcom’s children’s codes hub for what services had to implement: Ofcom—Protecting children online.

Ofcom lists several methods that can be “highly effective,” including facial age estimation (delete images immediately), open banking (bank confirms you’re over 18), mobile‑network checks, digital IDs/PASS, and credit‑card checks that bind to the user. Self‑declaration isn’t acceptable. See Ofcom’s children’s codes and guidance: Ofcom—Protecting children online.

Reddit’s approach can be quick and privacy‑respecting when deletion is enforced by the verifier (see TechCrunch on the UK rollout: Reddit rolls out age verification). Steam’s UK policy is simple but weaker against misuse (e.g., parent cards) and exclusionary for people without credit cards (Steam Help: “Your UK Steam account is considered age verified…”). Media coverage and developer trade press noted the drawbacks (e.g., You now need a credit card to access mature content on Steam in the UK). Ofcom’s criteria treat card checks as acceptable only when they meaningfully bind to the user (Ofcom—children’s codes).

Think of it as a trade‑off: a one‑time, auditable “age OK” token versus ongoing exposure of all your browsing to an unknown network. If you use a VPN, pick a reputable provider and understand the risks; the law expects services to consider circumvention but doesn’t mandate universal ID or breaking encryption . See gov.uk OSA explainer.

Reports in mid‑ to late‑2025 show some users discussing workarounds, but the safer path is usually to choose a privacy‑preserving on‑platform method and ensure deletion is real (see Ofcom’s children’s codes, linked above).

Reasonable alternatives include: ID+liveness via webcam, bank‑sourced age attribute (open banking), a mobile‑network check, PASS (digital proof of age), or email‑based estimation where appropriate. If a face estimation fails due to lighting or camera quality, a good flow offers a quick retry or switches to a stronger fallback (see Ofcom—children’s codes).

Better flows bind the check to the account holder via estimation, ID+liveness, bank proof, or MNO checks, and remember the result as an “age OK” token (Ofcom’s “highly effective” criteria emphasise robustness and reliability). Steam’s help page confirms the card‑on‑file design: Steam Help.

If you don’t have a credit card, use open banking, MNO, PASS, or ID+liveness. If your camera is poor, switch to a stronger fallback. If a platform offers only one route, that’s a design choice you can challenge (see Ofcom—children’s codes).

Specifically: in‑app reporting and complaints, teen‑safe defaults (limited recommendations; tighter contact eligibility), faster removal of illegal content (e.g., child sexual abuse material, terrorism, fraud, revenge porn), and optional filters adults can turn on to reduce exposure to abuse or other legal‑but‑unwanted content. These reflect services’ duties to assess risk, design safer systems, and be transparent (see Ofcom—online safety hub and gov.uk OSA explainer).

• Photo‑ID + liveness: scan a government ID and prove you’re a real person, not a recording.
• Facial age estimation: a selfie is analysed to estimate age; it does not identify you.
• Mobile‑network (MNO) checks: your carrier confirms an adult account.
• Credit‑card checks: can help, but must bind to the user, not just “a card exists.”
• Digital ID wallets / PASS: reusable age credentials.
• Open banking: your bank confirms you’re over 18 without sharing full identity.
• Email‑based age estimation: signals from long‑lived addresses and other data; low friction but needs coverage.

Self‑declaration (“I’m over 18”) does not meet the standard. See also the gov.uk OSA explainer for a plain‑English overview.

Where confidence is low (e.g., near 18; poor lighting; atypical features), services should offer stronger fallbacks such as ID+liveness or bank‑sourced age. That’s how platforms meet Ofcom’s robustness and fairness aims without hoarding images (see Ofcom’s children’s codes).

Accuracy varies by age band and conditions. Independent assessments and regulator materials indicate high accuracy for clear under‑/over‑18 distinctions, with lower confidence near thresholds—hence the need for buffers and fallbacks. (See Ofcom’s design expectations in the codes above.)

Good practice (reflected in Ofcom’s intent) is to publish error behaviour around threshold ages, be conservative near 18, test for and remediate bias, and always provide a non‑face alternative (ID, PASS, open banking) so people aren’t excluded if estimation struggles. See Ofcom’s design expectations in the children’s codes.

• ID + liveness: strongest binding; higher friction; needs solid anti‑fraud.
• Open banking: strong and privacy‑preserving; binds to the person controlling the bank app.
• Facial estimation: fast, privacy‑preserving if images are deleted; probabilistic, so you need fallbacks.
• Email estimation: very low friction; depends on email history/coverage; needs fallbacks.
• MNO checks: quick adult flag from a carrier; coverage varies; typically one layer in a stack.
• Credit‑card checks: acceptable only when they meaningfully bind to the user; “card on file” alone is weak against parent‑card misuse. See Ofcom’s caveats in the children’s codes.

A typical layered flow: begin with facial estimation or email‑based estimation; if confidence is low, offer ID+liveness, open banking, MNO or PASS. On success, issue a short‑lived “age OK” token and delete any images immediately. This meets Ofcom’s robustness/reliability/fairness objectives while keeping friction low (see children’s codes and the gov.uk explainer).

• Do they keep my face? No—certified flows should explain that images are used transiently to compute an age and then deleted (check the provider’s notice).

• What if I’m mis‑aged? You should be able to retry (better lighting/camera) or switch to a fallback (ID, PASS, bank) without being locked out unfairly (Ofcom’s children’s codes).

• Can I avoid biometrics entirely? Yes—choose a non‑face method (open banking, ID+live, PASS, MNO). Services should present options (see Ofcom’s accepted methods in the children’s codes).

• Is this fair for everyone? Ofcom expects services to test for bias and either remediate or provide alternatives where performance differs across demographics. That’s part of the “fairness” lens in the codes linked above.

• ACCS: The UK’s Age Check Certification Scheme audits age‑assurance providers and solutions against recognised standards (including privacy, security and performance). Look for an ACCS certificate for assurance over claims like “images are deleted immediately.” (ACCS—Age Check Certification Scheme)

• DIATF: The UK Digital Identity and Attributes Trust Framework recognises certified identity/attribute providers and includes requirements relevant to age attributes. Providers operating under DIATF publish which schemes and roles they’re certified for. (GOV.UK—Digital identity and attributes trust framework)

• PASS: The Proof of Age Standards Scheme certifies physical and digital proofs of age accepted across the UK (e.g., Yoti PASS card; Post Office PASS). PASS‑certified credentials can be used as a non‑biometric route. (PASS—Proof of Age Standards Scheme)

Example: providers such as Yoti detail independent audits and certifications for their facial age estimation and ID verification flows, including deletion and accuracy statements; services should link to those attestations in‑product. (See your selected provider’s certification pages and audit summaries.)

A strong flow offers a low‑friction method first (e.g., facial estimation) and fallbacks (ID+liveness, open banking, MNO, PASS). Images are deleted immediately after estimation, and only an “age OK” token is stored. The service explains methods and appeals in plain English. This aligns with Ofcom’s “highly effective” criteria around robustness, reliability and fairness (see Ofcom’s children’s codes).

A common anti‑pattern is “credit‑card only” gating. It’s easy to ship but weak against parent‑card misuse and exclusionary for users without credit cards. Ofcom treats card checks as acceptable only when they bind to the user, not just “a card exists” (children’s codes). Another anti‑pattern is claiming “no third party” while avoiding equivalent in‑house methods (e.g., ephemeral IDV) that achieve the same privacy outcome.

Coverage in 2025 highlighted these trade‑offs. For example, “You now need a credit card to access mature content on Steam in the UK” summarised friction and exclusion risks, while Ofcom’s bulletins emphasised offering alternatives and deleting data promptly (see Ofcom’s online safety hub and industry bulletins).

• Reddit (UK): verifier‑backed selfie age estimation with ID fallback; deletion claims; quick unlock of gated content. See coverage of the rollout: TechCrunch.

• Steam (UK): “valid credit card on file” = age‑verified; simple but weakly bound and exclusionary. Help page spells it out: Steam Help. Community threads and press reflect the practical pain points (e.g., debit‑card users; shared devices).

• Bluesky (UK): age‑assurance via an integrator (KWS/Epic) mixing face/ID/payment‑card options; used as a reference by some midsize services (see sourced notes in our research).

These patterns map back to Ofcom’s method menu and fairness expectations. Services that bind to the user, delete data, and offer choices tend to generate less backlash.

On a shared PC or console, binding to the instrument (card on account) can misrepresent the user. Better designs bind the check to the account holder using estimation or IDV, then remember the result (token). Where family accounts are involved, services should default to teen‑safe settings until an account holder verifies. This aligns with Ofcom’s focus on outcomes rather than a single tool (children’s codes).

Good implementations provide non‑card, non‑face options: open banking (bank confirms “over 18”), MNO checks (carrier adult flag), PASS (digital proof of age), or ID+liveness via webcam. If estimation fails due to camera/lighting, a quick retry or fallback should be available. See Ofcom’s accepted methods and fairness expectations (children’s codes).

A mis‑ageing event shouldn’t strand an adult user. Provide a rapid retry path (e.g., better lighting) or a switch to IDV/open banking/MNO/PASS. Keep an appeal route with human review for edge cases. These steps satisfy Ofcom’s reliability/fairness lens without diluting the protection goal (children’s codes).

Plain‑English notices should explain which methods are offered, whether images are deleted, what fallbacks exist, and how appeals work. Transparency reports should include high‑level metrics on verification success/failure and complaint outcomes. The OSA’s transparency expectations and Ofcom’s audit powers support this (see the government’s OSA explainer and Ofcom’s roadmap to regulation).

In practice: good providers state deletion clearly and explain retention for audit tokens. If a service claims deletion, they should be able to show it. You can exercise your rights with the provider (data access/erasure) and, if needed, complain to the ICO. See the UK GDPR overview (ICO) and Ofcom’s online safety hub for how these regimes interact. ICO materials updated in 2025 emphasise immediate deletion for age‑assurance images and minimal data handling.

Tip: look for independent certification and audits. For example, the Age Check Certification Scheme (ACCS) audits age‑assurance providers (ACCS), the Digital Identity and Attributes Trust Framework (DIATF) recognises certified identity/attribute providers (GOV.UK—DIATF), and the PASS scheme certifies proofs of age (PASS). Providers such as Yoti publish certifications and audit summaries covering deletion and accuracy.

Routes: (1) platform complaint/appeal, (2) Ofcom complaint about online safety issues (especially systemic ones), (3) ICO complaint if the issue is data protection (e.g., retention). We recommend Ofcom adopt a simpler user‑first intake that aggregates patterns so people don’t have to write long dossiers—but for now, use the current Ofcom complaints page and keep your evidence. For transparency duties that apply to larger/categorised services, Ofcom has final guidance on what reports must include (see Transparency reporting—final guidance (PDF)).

Ofcom’s codes list multiple “highly effective” methods so you shouldn’t be forced into one route. If a service offers only one choice, challenge it using the platform complaint route and cite Ofcom’s children’s codes.

A fair system explains the fallback ladder and offers a fast appeal with human review for edge cases (e.g., atypical faces, disability impacts). These expectations align with Ofcom’s fairness and reliability aims in the children’s codes.

Minimums worth doing: publish a simple safety policy (what’s allowed; reporting route), run a short risk assessment (what harms could appear; how you respond), and pick low‑friction age‑assurance options if you ever need them (email estimation, PASS). Keep short logs of decisions. Ofcom’s roadmap and hub explain proportionality.

Context: the UK’s “cookie law” obligations came via PECR (Privacy and Electronic Communications Regulations) implementing the EU ePrivacy Directive (early 2010s) alongside consent guidance; over time many sites implemented maximally annoying prompts rather than reducing tracking.

Timing: the EU’s GDPR applied from May 25, 2018, and the UK retained it as “UK GDPR” after Brexit. GDPR pushed controllers to redesign data flows, document decisions (DPIAs), and justify retention—shifting effort from user clicks to service systems.

That’s why Ofcom’s codes are method‑agnostic but outcome‑focused (robustness, reliability, fairness), and why the law empowers auditing rather than “make every adult show ID” edicts (see gov.uk OSA explainer and Ofcom’s children’s codes).

The direction is similar: less banner friction, more systemic obligations. The UK’s OSA is part of that shift—child safety and illegal harms up front, transparency and audits on the back end. See comparisons that outline differences and overlaps: Slaughter and May—EU DSA vs UK OSA, Bristows—OSA vs DSA, and Ofcom’s roadmap to regulation.

That framing helps: you shouldn’t have to do all the work to be safe online. The obligations sit primarily with the services.

That’s why children’s duties focus on safer defaults, reduced unsolicited contact, and friction around adult/harmful content. The intent is a graded experience rather than an on/off switch (see Ofcom—children’s codes).

Not necessarily. The Act doesn’t force blanket DM blocks for anyone. Duties are risk‑based and should be proportionate.

• What’s covered: user‑to‑user services are in scope, and private messaging can be in scope when content one person sends can be encountered by another. But the law targets system risks, not auto‑gating every conversation by default.
• Over‑compliance: one‑size‑fits‑all DM blocks or “prove you’re 18 to message anyone” can be a blunt shortcut. If both accounts are clearly adult, long‑standing, and show low‑risk patterns, heavy gates usually aren’t needed.
• Proportionate options (legal‑team friendly): limit unsolicited contact, add friction for unknown/teen accounts, rate‑limit spammy behaviour, provide strong blocking/reporting, and keep safer defaults for young users. Let normal DMs proceed where risk is low (e.g., verified‑adult pairs; established mutuals).
• Good faith: the law is specific about what qualifies. A legal team that engages with the guidance can find workable routes that protect teens without breaking everyday use.

If your DMs were blocked across the board, that may be a design choice rather than a legal requirement. Use the platform complaints route and point to proportionate alternatives.

There is a flipside. Buying from reputable providers changes incentives: workers are paid, terms are clearer, and businesses have more to lose if they mishandle data. If you choose to access adult content:

• Prefer well‑known providers with clear privacy policies and support for deletion/portability.
• Use the most privacy‑preserving age‑assurance route offered (e.g., estimation with deletion rather than ID requirements).
• Keep accounts minimal, throwaway (separate email; no unnecessary personal details).
• Avoid “free” sites with a history of scraping or poor moderation: the data and safety risks are higher.

There is a sense of 'moralising', and it walks a fuzzy line between access and harm‑reduction. The law aims to gate 18+ areas; your choices can reduce exposure to sketchy actors while supporting creators and safer practices who do act responsibly.

The adult “legal but harmful” takedown duty was dropped during the Bill’s passage.

Adults get tools to avoid content, not new Act‑level bans on legal speech. Real chilling risks mostly come from platform choices (over‑zealous filters, vague rules). The OSA requires clearer terms, appeals, and transparency to keep that in check (see the government’s OSA explainer).

In short: platforms remain responsible for enforcing their own terms consistently. Users should get appeals and explanations when content is actioned. Regulators look at the quality of those systems rather than dictating adult speech bans.

Freedom without safety isn’t meaningful for many people. The OSA pushes platforms to enforce their own rules consistently and provide better reporting and user controls (filters, blocks), so adult speech can thrive without making targets unsafe. That includes tools for blocking unsolicited contact and limiting recommendations around sensitive content (children’s codes).

E2EE isn’t banned. A power exists to require “accredited technology” to detect illegal material, but only if technically feasible and with safeguards.

Ministers have said they won’t use that power until a workable, privacy‑preserving approach exists. For now, the practical focus is on platform systems (risk assessments, safer defaults, reporting) rather than breaking encryption.

Best we could tell, this hypothetical 'safe but sometimes open'-E2EE-workaround doesn't seem like something that would make sense to exist. Nobody seems to be suggesting a 'skeleton key' or back-door solution (for many very good reasons), but it seems unlikely to be deployed even if it did magically become available (through 'AI' or 'Quantum' perhaps).

What this means in practice:

• Your encrypted apps (e.g., Signal, WhatsApp) continue to offer end‑to‑end encryption.
• There is an unresolved debate about whether scanning inside encrypted apps can ever be done safely; several providers say they would not weaken E2EE to do so.
• If technology emerges that meets strict tests, the regulator could consider it; until then, attention is on non‑encryption measures.

Note: this area is contested and evolving. The law sets the option; the current stance is “not until feasible,” and many companies strongly oppose any weakening of E2EE.

That can still affect borderline content (e.g., edgy satire, shock thumbnails) if a platform’s policy is strict, but the lever is the platform’s policy and systems, not a new Act‑level ban on adult legal speech. Appeals and transparency expectations should improve the conversation around mistakes (see Ofcom—hub).

• Age assurance: evidence suggests facial age estimation can reliably separate under‑18s from adults when used with sensible buffers and rapid deletion; near age thresholds it needs fallbacks (ID+liveness, bank, PASS), or maybe just a light touch. Certification improves this level of trust, and popular service-providers (like Epic's KVS) should work with the government to openly improve on their assurances.

Ofcom frames “highly effective” as an outcome standard (robust, reliable, fair) rather than a single tool, which is why layered flows perform best. (See Ofcom children’s codes and guidance.)

• System duties: clearer reporting/appeals and safer teen defaults reduce friction for targets and raise the bar for repeat harms; effectiveness varies by platform maturity and follow‑through (audits, transparency).

What we don’t yet have is a single “X% safer” number across all harms. Regulators and providers will publish data over time (removal speeds, complaint outcomes, recidivism). Treat early numbers as directional rather than definitive.

Sources: Ofcom online safety hub and children’s codes; provider certification notes (ACCS/DIATF/PASS) on deletion and accuracy.

• Clearly illegal harms: e.g., Abuse material, terrorism content, fraud. Platforms must assess risks of this content, and design systems to detect and remove these more effectively (codes and guidance specify measures and processes), reacting with timeliness and responsibility.
• Likely‑to‑harm content for children: e.g., pornographic content; encouragement of self‑harm or eating disorders; abusive contact. Duties include safer defaults, gated access, and tools that reduce exposure and unwanted contact.

Effectiveness depends on proportionate implementation: age gates that actually keep most under‑18s out of adult areas; recommendations that don’t push younger users toward harmful spirals; and appeals that quickly fix mistakes. Ofcom’s outcome tests (robustness, reliability, fairness) are the yardstick for judging if a chosen method works in practice.

Sources: Ofcom illegal‑harms statements and children’s codes; overview of illegal harms; regulator roadmaps cited in this report.

Coverage through mid‑2025 and beyond focused on Reddit’s selfie‑based rollout and Steam’s credit‑card approach, which sparked strong reactions across gaming and creator spaces. See, for instance, the BBC on Reddit’s UK rollout (BBC News) and developer press on Steam’s card‑on‑file design (Game Developer).

• What people see: age checks at login or when opening adult areas.
• What they don’t see: risk assessments, safer defaults for teens, audits and reporting.
• Why it spreads: media and creators focus on visible changes that affect everyday use.
• Examples shaping the narrative: Reddit’s selfie+ID fallback; Steam’s card‑on‑file design.

Polling in 2025 suggests broad support for protecting kids alongside scepticism about effectiveness. For example, a July 2025 YouGov poll reported high support for age verification but doubts about outcomes, and an August 2025 Ipsos study found many Britons back checks while questioning how well they work. Linking to such polls helps explain why public sentiment can be pro‑safety yet critical of clunky designs. (YouGov poll results, Ipsos—Adults and age checks).

• Real friction: blunt designs (e.g., card‑only gates) annoy people and exclude some users.
• Amplification: organised groups can turn design anger into “the law is the problem.”
• Fast spread: gaming spaces are built for mobilisation (raids, brigades, review‑bombs).
• Public mood: support for protecting kids sits alongside doubts about real‑world results (YouGov; Ipsos).

• Lead with privacy: delete images; avoid ID when not necessary.
• Offer routes: face, ID+live, bank, PASS—let users pick.
• Explain in‑product: simple language; no mystery steps.
• Fix mistakes quickly: retries and appeals that actually work.

• Uncertainty + big penalties → “easy to prove” designs.
• Single, blunt gates are simple to audit but frustrate users and exclude some people.
• Better path: layered, privacy‑preserving methods that still pass audits.
• Regulator stance: Ofcom’s framework allows layered methods—use that space.

See Ofcom’s phased roadmap and the government’s OSA explainer.

Ofcom provides periodic bulletins and statements tracking progress—use these as primary sources when citing trends and outcomes (see Ofcom’s online safety industry bulletins).

In practice, Ofcom and the ICO coordinate via a memorandum of understanding (MoU) to avoid double jeopardy—Ofcom handles safety systems, ICO focuses on data compliance. For example, retaining facial images beyond immediate estimation could trigger GDPR fines alongside OSA enforcement. See the ICO-Ofcom MoU (PDF) and UK GDPR guidance on processing special category data like biometrics.

Challenges include attribution (who’s the “provider” in a federated setup?) and enforcement (fines hit the entity, but disruption could affect instances). Ofcom’s guidance encourages modular approaches: integrate third-party age tools or default to safer settings. See Ofcom’s scope overview for “multi-provider” services and the Regulated services: overview of scope (PDF).

Ofcom’s codes require explainable systems and human oversight for high-stakes calls; future iterations may address AI-specific risks like generated harms (deepfakes). Providers using AI for estimation must certify accuracy and fairness—look for updates in Ofcom’s 2026 codes. See emerging guidance in Ofcom’s open letter on Generative AI (hypothetical based on trends; check current hub).

Watch for judicial reviews challenging over-reach or consultations on code updates. International parallels (e.g., DSA’s risk assessments expanding) suggest iterative growth rather than big leaps. See the government’s strategic priorities statement (May 2025) and Ofcom’s response.

Positive angles: safer spaces could boost trust and retention; transparency duties level the field for ethical providers. Economic analyses (e.g., impact assessments) estimate net benefits from reduced harms outweigh costs—see the OSA regulatory impact assessment (2023, updated 2025). Track creator feedback via unions like the Creators’ Rights Alliance.

Ripple effects: some platforms might harmonize policies worldwide to simplify ops, influencing users elsewhere. See Ofcom’s international enforcement approach and comparisons with DSA’s very large platforms regime.

If a flow fails accessibility tests, challenge it via platform complaints or escalate to Ofcom/Equality and Human Rights Commission (EHRC). Guidance emphasizes inclusive design; see Ofcom’s fairness expectations in children’s codes and EHRC’s online accessibility resources.

Early indicators: fewer reported exposures for children; better user satisfaction with appeals. Full evaluations are slated for 2027+—see Ofcom’s evaluation framework consultation and government post-implementation reviews.