On 19 October 2026, Norway’s government said it is finishing a bill that bans social media for children under 16. It also said the ban will reach online games and messaging services. The bill is due in parliament by the end of 2026. It hasn’t been submitted yet.
Two details in the plan are different from the other under-16 laws we’ve covered. First, the limit would end on 1 January of the year the child turns 16, not on the 16th birthday. Second, a service would be covered because of how it is built, not because of the category it sits in. Neither detail fits a gate that stores “over 16: yes or no” and decides by app type.
What we could confirm
We read Euronews, The Local Norway and ID Tech. We haven’t read a Norwegian government text, because the bill isn’t public.
- The age line. 16. A 2025 draft said 15. The government raised it in April 2026.
- The scope. The broad exemptions for games and messaging are gone. TikTok, Snapchat and Roblox are expected to be covered.
- The test. A service is harmful if, by its design, features or content, it poses a risk to children’s emotional or cognitive development or health. The listed risks are harmful content, addictive features, unlawful marketing and unwanted contact from strangers. The assessments are meant to be based on evidence and updated as technology changes.
- The exception. Harmless games and apps used to talk with schools “would not be automatically covered”. That isn’t the same as exempt.
- Who verifies. The platforms. The method isn’t named. The solutions must be privacy-friendly and follow the GDPR (the EU data protection law).
- The date rule. The limit applies until 1 January of the year the child turns 16.
- The politics. The Labour government has no majority. Other parties must back the bill. The minister says companies should comply “from day one”.
What we could not confirm
The start date. The penalties. The enforcement body. Who decides that a given service is harmful, and how a service can argue it isn’t. The exact wording of the date rule. We have it from two reports, and the bill could change it. Everything from “The date” onwards is our reading of those reports, not Norwegian law.
The date: a cohort flips at midnight
Take a child born on 20 November 2011. They turn 16 on 20 November 2027. Under the reported rule, the limit ends on 1 January 2027. So they are free of it at 15 years and 6 weeks old.
Three things follow from that.
A birth year is enough. You don’t need a full date of birth to apply the rule. You need the year. That’s good news for data minimisation. It’s bad news for any system that stores only a boolean.
The whole cohort changes state at once. On 1 January 2027, every account with a birth year of 2011 goes from restricted to free. You can’t wait for a birthday event, because there isn’t one. You need a yearly job, and you need to decide which clock it uses. Midnight in Oslo is not midnight in UTC (the global reference time).
The line in exact age moves through the year. On 2 January the oldest restricted user is just over 15. On 30 December the oldest restricted user is just under 16. If you use an age estimator, its error margin has to slide with the calendar. We wrote about the fixed version of this problem in the 16 line post. Norway’s version is harder, because the line isn’t fixed.
Here is a function that applies our reading. It returns the decision, the date the limit ends and the reason.
type Decision = { restricted: boolean; freeFrom: string; reason: string };
// Our reading of the reported rule: restricted until 1 January of the year
// the child turns 16. Unconfirmed until the bill is published.
export function norwayUnder16(
birthYear: number,
now: Date,
timeZone = "Europe/Oslo",
): Decision {
const year = Number(
new Intl.DateTimeFormat("en-CA", { timeZone, year: "numeric" }).format(now),
);
const freeYear = birthYear + 16;
return {
restricted: year < freeYear,
freeFrom: `${freeYear}-01-01`,
reason: `birth year ${birthYear}, calendar year ${year} (${timeZone})`,
};
}And the tests that matter:
import { test, expect } from "vitest";
test("born 2011: still restricted on the last day of 2026", () => {
const d = norwayUnder16(2011, new Date("2026-12-30T12:00:00Z"));
expect(d.restricted).toBe(true);
});
test("born 2011: free from 1 January 2027, Oslo time", () => {
const d = norwayUnder16(2011, new Date("2027-01-01T12:00:00Z"));
expect(d.restricted).toBe(false);
});
test("the time zone edge: 23:30 UTC on 31 December is already 2027 in Oslo", () => {
const d = norwayUnder16(2011, new Date("2026-12-31T23:30:00Z"));
expect(d.restricted).toBe(false);
});
test("born 2010 turns 16 in 2026, so free during all of 2026", () => {
const d = norwayUnder16(2010, new Date("2026-02-01T12:00:00Z"));
expect(d.restricted).toBe(false);
});The third test is the one that will bite. If your yearly job runs on a UTC cron schedule, a user in Oslo is released an hour late, or locked in an hour late, depending on the season. Which clock the law uses is one of the open questions. Make it a setting, not a constant.
What this does to your stored data
If your system stores “over 16, verified on 3 March”, you can’t apply the rule. You don’t know the birth year. You know the person was over 16 on one day, which in Norway’s terms says nothing about whether they were born in 2010 or in 2005. For anyone who passed through a document check, you may have a birth date in the check result. For anyone who passed through an estimate, you have a range and nothing more.
So there are two kinds of users. Those with a known birth year get the function above. Those with only an estimate need a policy, and the policy has to stay honest. An estimate of “about 17” in the year 2026 means the user is probably free of the limit. An estimate of “about 15” means you can’t tell, and the cost of being wrong lands on you. We’d treat the band between 14 and 17 as “unsure” and send it to a stronger check. Greece has the same problem with a different line, and we described the queue in the Greece post.
Games are judged by design
The second change matters more to many teams. Norway first expected broad exemptions for games and messaging. Now it plans to assess each service by its risk to children. The minister’s words, as The Local reports them, are that some platforms “present themselves as games but in fact are full of features”.
That sentence tells you how the test works. The label on the store page doesn’t matter. The features do.
The listed risks give you a way to work. Build an inventory of your features, and for each one write down which of the four risks it touches. This is the document you would want to hand to a regulator if a regulator asked why your service shouldn’t be covered. Or, if it should be, why your age gate is enough.
| Feature | Risk it touches | What to write down | Gate option |
|---|---|---|---|
| Open text or voice chat | Unwanted contact from strangers | Who can start a conversation. Whether a stranger can find a child by name. Whether chat is on by default | Chat off until the age is known. Contact limited to approved friends |
| Friend discovery and search | Unwanted contact from strangers | Whether profiles are searchable. What a stranger can see | Searchable only at 16 and above, or only by invite code |
| User-made worlds and content | Harmful content | How content is reviewed. How long a report takes to action | Browse-only below the line |
| Random rewards, streaks, daily login pressure | Addictive features | What triggers a reward. Whether rewards cost money | Remove or soften for restricted users |
| Trading and in-game purchases | Unlawful marketing, addictive features | Who can sell to whom. Whether prices are shown in real money | Purchases off for restricted users |
| Ads and sponsored items | Unlawful marketing | What targeting is used | No targeting for restricted users. See the targeted ads post |
| Endless feed or autoplay | Addictive features | Whether the order is ranked by engagement | Chronological or capped below the line |
Two notes. First, “gate option” is a design choice. It isn’t a requirement. Norway hasn’t told anyone which mitigations count. Second, the first row is the one you have already seen. We wrote about chat as a trigger in the chat box post, and about tiering contact by age in the age-based experiences post. Norway puts the same idea into the test, and it adds addictive features as a named risk.
If you run a game, treat the inventory as a working document with an owner and a date. The assessments are supposed to be updated as technology changes. A feature you ship next quarter can move you across the line.
If your product is a messaging app for a school or a club
“Not automatically covered” is a weak promise. It says there is no automatic exemption, and it says nothing about what earns one. So expect to have to show it.
We can’t tell you what Norway will accept. We can tell you what the listed risks suggest a harmless app looks like, and what to be able to prove:
- Membership is closed. Accounts exist because a school or club created them. A stranger can’t sign up.
- No contact from outside. There is no search by name, no public groups and no way to message someone outside the roster.
- No ads and no engagement ranking. Messages appear in time order. Nothing is there to keep a child on the app.
- An adult owns the space. A named teacher or club leader can see the group, remove a member and report a problem.
- A short record. You can show a regulator the settings, the date they were set and who changed them.
This list is our reading of four risks, not Norwegian criteria. If you fail one line, you are a messaging service with a stranger-contact risk, and the age gate question comes back.
What it might cost
This is an example, not data from any platform. Say a game has 300,000 accounts from Norway. Say 95% can be placed with a browser Check, and 5% (15,000 accounts) end up in the unsure band and need a document Verification.
On a paid plan, a Check costs €0.01 to €0.03, and a document Verification costs €0.10 to €0.30. That gives 285,000 Checks for €2,850 to €8,550, and 15,000 Verifications for €1,500 to €4,500. The one-time total is €4,350 to €13,050. The 5% is an assumption. If your unsure band is 15%, the Verification line triples. The size of that band depends mostly on the birth-year question above: the more users you hold only an estimate for, the larger it is.
Checklist for this week
- Find out which of your Norwegian users have a stored birth year, a stored birth date, or only a yes-or-no answer. Count each group.
- Add a
birthYearfield to the check result record, next to the method and the date. - Write the yearly release job with the time zone as a setting. Run the four tests above.
- Decide what happens to estimate-only users in the 14 to 17 band. Write it down.
- Build the feature inventory. One row per feature, one owner per row.
- For each row, write the lowest-cost mitigation that works below the line, and what it does to engagement. What a gate does to engagement is covered in our Roblox post.
- If you run a closed messaging app, collect the five proofs above in one place.
- Set a reminder for the bill. It is due by the end of 2026, and the date rule and the harm test are the two lines to read first.
The short version
Norway’s plan changes two things your gate probably assumes. The limit ends on a calendar date, so a birth year matters more than a birthday. And a game is covered because of its features, so you need a written list of those features and what each one does to a child. Neither rule is law yet. Both are cheap to prepare for now and expensive to retrofit after a bill passes with “from day one” attached.
Xident provides age verification and age estimation with a decision record on every check. A browser Check is the lower-cost first step, and a document Verification is for users who need a stronger answer. On paid plans a Check costs from €0.01 to €0.03, and a document Verification costs from €0.10 to €0.30. We don’t know yet which method Norway will accept, and we make no claim about it. Talk to us about the step-up path behind your gate, or see pricing.
