Every age gate running in production today does the same thing. It works out how old someone is, compares that number to a threshold, and returns true or false. The threshold is 13, or 16, or 18, or 21. The comparison is the same either way.
On 1 January 2027 the United Kingdom starts enforcing an age rule that does not fit that shape at all.
From that date it is an offence for retailers, including online retailers, to sell tobacco products, herbal smoking products or cigarette papers to anyone born on or after 1 January 2009 (DHSC guidance). Not to anyone under 18. To anyone born on or after a specific calendar date, forever.
The Department of Health and Social Care puts the difference in one sentence, and it is the most important sentence in the whole guidance:
The new age of sale is based on a fixed date, so retailers will only need to establish whether the customer’s date of birth is before 1 January 2009. This is different from other age-restricted products, where retailers need to calculate the customer’s age from their date of birth.
Read “only need to establish” from the point of view of a shop assistant and it sounds like a simplification. Read it from the point of view of an age assurance system and it is the opposite. It replaces a question every method in the market can answer with one that several of them cannot answer at all.
That is 107 days away. A nearer date matters too, and almost nobody is talking about it.
Two dates, and the near one is 43 days out
The Tobacco and Vapes Act 2026 received Royal Assent on 29 April 2026 (GOV.UK). It commences in stages. Two of those stages land within four months of each other, and they carry different rules.
| Date | Products | The rule | Applies to online sales |
|---|---|---|---|
| 29 October 2026 | Vaping products, nicotine products (pouches, strips, pearls, including synthetic nicotine) | Under 18 is an offence | Yes, stated explicitly |
| 1 January 2027 | Tobacco, herbal smoking products, cigarette papers | Born on or after 1 January 2009 is an offence | Yes, stated explicitly |
The October date is a conventional age threshold and most teams can meet it by widening product scope. It is still work. It extends the restriction to non-nicotine vapes and to nicotine pouches in England, Wales and Northern Ireland, and it pulls nicotine products into Scotland’s existing age verification policy regime (DHSC guidance). If your catalogue has a nicotine pouch in it that was not age-gated before, it needs to be gated in six weeks.
The January date is the one that breaks things.
Why “it’s basically 18 for now” is wrong
The first reaction most engineers have is that the cohort rule and the 18 rule are the same thing in 2027, so this can wait. It is worth killing that idea early, because it is wrong on day one and it gets more wrong every year.
A person born on 1 January 2009 turns 18 on 1 January 2027. So on that single day the two rules line up almost exactly. By March they have already come apart. Someone born in March 2009 turns 18 in March 2027 and is an adult, and is banned. A plain age >= 18 check passes them.
Then the gap widens on a fixed schedule, because one line moves and the other does not.
| Date | Youngest person who may still be sold tobacco | Effective minimum age |
|---|---|---|
| 1 January 2027 | Born 31 December 2008 | 18 |
| 1 January 2030 | Born 31 December 2008 | 21 |
| 1 January 2035 | Born 31 December 2008 | 26 |
| 1 January 2040 | Born 31 December 2008 | 31 |
| 1 January 2045 | Born 31 December 2008 | 36 |
The right-hand column is the thing to sit with. This is not an 18-plus rule with an unusual implementation. It is a rule whose effective threshold rises by one every January and never stops. Any system that stores “18” as a configured number for this product category is storing a value that is correct for roughly one calendar year.
The correct predicate is not a threshold at all:
// What every age gate does today.
function canBuy(dateOfBirth: Date, minimumAge: number): boolean {
return ageInYears(dateOfBirth) >= minimumAge;
}
// What the tobacco rule needs from 1 January 2027.
const TOBACCO_COHORT_CUTOFF = Date.UTC(2009, 0, 1); // 2009-01-01
function canBuyTobacco(dateOfBirth: Date): boolean {
return dateOfBirth.getTime() < TOBACCO_COHORT_CUTOFF;
}The second function is simpler. It has no timezone-sensitive age arithmetic, no leap-year edge case, no “what is their age today” call that returns a different answer tomorrow. It is also, for most modern age assurance stacks, unanswerable, because it needs an input those stacks are deliberately built never to obtain: an actual date of birth.
That is the whole problem in two functions.
Facial age estimation can route, but it can never decide
Facial age estimation returns an estimated age with an error margin. It does not return a date of birth and it never will, because a date of birth is not a property of a face.
For a threshold rule that is fine, and it is why estimation has taken over so much of this market. You set a challenge buffer above the threshold, let everyone comfortably above it through, and send the rest to a document check. We have written before about how to read the NIST FATE numbers and about estimation-first stacks. The economics are good because the buffer filters out most of the population cheaply.
Against a cohort rule, estimation can only ever be a router. It can tell you that a customer is very probably not in the banned cohort, and that is useful. It cannot produce the evidence that they were born before a specific date, because the evidence does not exist in the signal.
Worse, the part that makes estimation cheap decays on a schedule. The buffer has to sit above the effective line, and the effective line climbs every year.
- In 2027 a buffer-based policy challenges anyone who might be under about 25. Most adult customers pass without a document.
- In 2035 the line is at 26, so the same buffer logic challenges anyone who might be under about 33.
- In 2045 the line is at 36, so it challenges anyone who might be under about 43.
At that point estimation is filtering out a minority of your customers rather than the large majority, and the cost model of the whole flow has inverted. The method that is cheapest today becomes progressively less useful for this one product category, on a timetable you can read off a calendar. That is not a reason to drop estimation. It is a reason to stop treating it as the primary decision path for tobacco and to build the document and wallet path properly now, while the volume through it is still small.
The wallet problem: age_over_18 cannot express a cohort
This is the part almost nobody has worked through, and it is the part that matters most for anyone building on mobile driving licences or EU wallet credentials.
The privacy design of modern digital identity rests on age attestations. An ISO/IEC 18013-5 mobile driving licence carries issuer-signed boolean elements named age_over_NN. The holder discloses age_over_18: true and the verifier learns that one fact and nothing else, not the birth date, not the exact age. The EU Digital Identity Wallet architecture makes age_over_18 a core attribute for exactly this reason. It is a good design and it is the right answer for threshold rules.
It cannot express “born before 1 January 2009”, and the reason is arithmetic rather than policy.
age_over_NN is true when the holder’s age is at least NN whole years. A cohort rule draws its line at a fixed calendar date. Those two lines coincide on exactly one day per year and drift apart on all the others.
Work through a single day. On 1 July 2027, the youngest person who may still legally be sold tobacco is someone born on 31 December 2008, who is 18 years and 182 days old. So:
- Request
age_over_18and you admit everyone aged 18 years and 0 days upward. That includes people born between January and July 2009, who are banned. You have just committed the offence. - Request
age_over_19and you reject everyone below 19 years exactly. That includes everyone born between 2 July 2008 and 31 December 2008, who are legal adult customers. You have just refused half a birth year of paying adults.
There is no third option inside the attribute. The safe choice is always the over-strict one, and its cost follows a sawtooth:
| Date | Smallest safe request | Legal adult customers wrongly refused |
|---|---|---|
| 1 January 2027 | age_over_19 |
a full birth year |
| 1 April 2027 | age_over_19 |
about three quarters of a birth year |
| 1 July 2027 | age_over_19 |
about half a birth year |
| 1 October 2027 | age_over_19 |
about a quarter of a birth year |
| 31 December 2027 | age_over_19 |
none |
| 1 January 2028 | age_over_20 |
a full birth year again |
The mismatch is zero on 31 December and maximal on 1 January, every single year, forever. On New Year’s Day your wallet-based tobacco check turns away an entire year’s worth of legitimate adult customers, and then gets steadily better until the day it resets.
Three further details make this harder rather than easier.
The verifier does not get to pick NN freely. The set of age_over_NN elements present in a credential is chosen by the issuer when the credential is minted. Practice varies a lot. AAMVA’s implementation guidelines push US issuers to provision a wide band, with a worked example spanning 16 to 85, so age_over_19 and age_over_20 are often genuinely there. The EU wallet architecture goes the other way and centres on age_over_18 as the attribute every wallet must carry. So whether the NN you need exists at all depends on who issued the credential in front of you, and a UK retailer does not get to choose that. Planning a flow around an attribute that some issuers provision and others do not is a different kind of problem from a missing feature, because it fails per customer rather than per integration.
Asking for a spread of NN values is not the workaround it looks like. The obvious hack is to request several age_over_NN elements and narrow the answer down until you have effectively recovered the birth year. That is exactly the behaviour the privacy design of these credentials exists to discourage, and a verifier that does it has reinvented birth date disclosure with extra steps and worse optics. It is also not something you can rely on, because it only works when the issuer happened to mint the values you want (SpruceID has a good walkthrough of what an mDL actually carries).
The remaining option is to request the birth date itself. It works, exactly, every day of the year. It also hands a full date of birth to every corner shop and vape site in the country, which is the outcome the entire selective disclosure architecture was designed to prevent. It is worth being blunt: a cohort rule, implemented naively, is a data minimisation regression dressed as a public health win.
The clean fix is a dedicated attestation. An issuer-signed boolean that means “born before 2009-01-01” discloses exactly one bit, matches the rule exactly, and never needs reissuing because the fact never changes. It does not exist in any deployed credential profile today. Someone should be specifying it now, because the first market that needs it starts enforcing in January and the second and third markets are coming.
One basket, three different questions
The rule that will catch the most online retailers is not the tobacco rule on its own. It is what happens when the tobacco rule shares a checkout with everything else.
Picture a single order from a UK convenience retailer in February 2027:
| Line item | Rule from | The predicate |
|---|---|---|
| Vape pod refill | 29 Oct 2026 | age >= 18 |
| Nicotine pouches | 29 Oct 2026 | age >= 18 |
| Rolling papers | 1 Jan 2027 | date of birth < 2009-01-01 |
| Bottle of wine | Licensing Act 2003 | age >= 18 |
Four products, two structurally different predicates, one payment. Most e-commerce age gates are a single site-wide flag or a single boolean on the customer record. That model cannot represent this basket. It has one answer and the basket needs two.
Cigarette papers are the trap inside the trap. They are not tobacco, most retailers do not think of them as tobacco, they sit next to the vapes rather than behind the counter with the cigarettes, and they are squarely inside the generational cohort rule. So are herbal smoking products, which means herbal shisha and herbal cigarettes, products often stocked by retailers who sell no tobacco at all. If your catalogue taxonomy has one category called “tobacco” and the age rule hangs off it, papers and herbal products are almost certainly on the wrong side of it right now.
The architectural fix is not complicated, it is just work, and it is work nobody scheduled. Age rules belong on the product, not on the site. Each product carries a rule reference. The basket resolves every rule its line items require, and a rule is satisfied or it is not. “Strictest wins” no longer reduces to picking the highest number, because the two predicates are not on the same scale.
There is a quieter consequence too. The display rules are set to move with the age of sale. Retailers may currently only accept a request to see a tobacco product or price list from someone aged 18 or over. Subject to parliamentary approval, that becomes someone born before 1 January 2009 in England, Wales and Northern Ireland. Showing a customer a price list becomes cohort-gated. If your product listing page hides tobacco prices behind an age interstitial, that interstitial needs the cohort predicate, not the threshold.
The defence changed shape, and the regulations are not here yet
The compliance position is uncomfortable right now, and it is worth stating plainly rather than reassuringly.
In England, Wales and Northern Ireland, regulations will set out the steps a retailer can take to verify that a customer was born before 1 January 2009. Take those steps and you have a statutory defence: prove them to a court and the court should not convict you. Those regulations have not been debated yet. DHSC says they will come before Parliament “in due course” and that the guidance will be updated when they do.
Until then, the only defence available is the general one: prove that you otherwise took all reasonable steps to avoid committing the offence. With 107 days to go and no prescribed steps published, “all reasonable steps” is the standard an online retailer has to design against, and it is a standard defined after the fact by someone else.
Scotland is further ahead, and its route is instructive. Retailers there are already legally required to operate an age verification policy, with the acceptable forms of identification set out in legislation, and from 29 October 2026 that duty extends to herbal smoking products and nicotine products. Section 63 of the Act also changes the Scottish due diligence defence so that it turns on the accused having “taken such steps as may be prescribed to establish the customer’s age” (Tobacco and Vapes Act 2026, s.63). The direction of travel across all four nations is the same: away from an open “we did our best” test and toward a prescribed list you either followed or did not.
The penalties are not the headline risk, but they are worth knowing. A fixed penalty notice of £200 in England, Wales and Scotland, £250 in Northern Ireland subject to Assembly approval. On summary conviction a fine up to level 4 on the standard scale, currently £2,500, or level 5 at £5,000 in Northern Ireland. Failing to display the new age of sale notice carries its own fixed penalty of £200 in England, Wales and Scotland and £100 in Northern Ireland. The notice also has size rules, which are still subject to parliamentary approval: A3 minimum, with characters no smaller than 21mm in England, Scotland and Northern Ireland and 12mm in Wales.
The real risk is the third one. Three relevant offences within two years in England and Wales can bring a restricted sale order or a restricted premises order, banning a person or a premises from selling those products for up to 12 months. Scotland has an equivalent banning order lasting up to two years. For a retailer whose tobacco and vape lines drive footfall, a twelve month ban is not a fine, it is the business.
The one genuinely good thing about a cohort rule
Almost everything above is a cost. This part is not, and it is the reason to build for this properly rather than bolt it on.
Every age check ever built produces an answer that expires. We made that argument at length in why your age check has no expiry date. A “no, this user is not 18” result is wrong the day after their eighteenth birthday. A “yes” result was true at the moment it was taken and says nothing certain about today. That decay is what forces re-verification cadence, and cadence is what makes age assurance expensive to run.
A cohort answer does not decay. “Born before 1 January 2009” is either true or false about a person, and it stays true or false for the rest of their life. It is the first age assurance result in the history of this industry that never goes stale in either direction.
The operational consequence is large and it points one way. For this rule, you verify a customer once, properly, with a document or a wallet credential, and you never need to verify them again for this product category. Not annually, not on a cadence, not on a policy change. The correct architecture is an expensive first check followed by a cheap returning-user lookup, permanently.
That also makes reusable credentials more valuable here than anywhere else, not less. A cohort result is the ideal thing to carry in a reusable age credential, because the usual objection, that a stored age result goes out of date, does not apply.
This is not a UK quirk
It is tempting to file this under British eccentricity and move on. The record says otherwise.
The Maldives got there first. Its generational ban took effect on 1 November 2025 and prohibits anyone born on or after 1 January 2007 from buying or being sold tobacco, with the rule applying to residents and visitors alike. New Zealand legislated a generational ban in December 2022 and repealed it under parliamentary urgency on 27 February 2024, before it commenced, so it never operated. The UK will be the first large market to actually run one.
Three jurisdictions, two different cutoff years, one of which was reversed. New Zealand had picked 1 January 2009 too, which is the same line the UK is now about to enforce. That is the shape of a policy pattern spreading rather than a one-off, and the fact that two countries independently landed on the same date makes it more likely to be copied, not less. If you build age assurance for more than one market, the safe assumption from now on is that cohort rules are a permanent category alongside threshold rules, with a different cutoff date per jurisdiction per product class, and that some of those dates will be repealed and others added.
Which means the design question is not “how do I hardcode 2009”. It is “does my rule engine support predicates that are not thresholds, with per-jurisdiction and per-product parameters, and can a compliance person change one without a deploy”.
There is a second UK thread converging on the same moment, and it helps. The draft Licensing Act 2003 (Mandatory Licensing Conditions) (Amendment) Order 2026 was approved by both Houses on 8 September 2026, allowing licensed premises in England and Wales to accept digital proof of age from a certified Digital Verification Service on the GOV.UK register, at medium confidence or above. We covered that route in digital ID for alcohol. So certified digital identity is arriving in UK retail in the same autumn as the hardest age rule anyone has written. The infrastructure that can carry a date of birth attestation is turning up at roughly the time something finally needs one. That is lucky rather than planned, and it only helps if the credentials on that register end up able to answer a cohort question.
What to do in the next 43 and 107 days
Before 29 October 2026:
- Audit the catalogue for nicotine products that were never gated. Pouches, strips, pearls, synthetic nicotine, and non-nicotine vapes in England, Wales and Northern Ireland. Gate them at 18.
- Check that the age rule is attached to products, not to the site or the session. If it is a single flag, this is the moment you find out.
- Confirm the rule covers accessories the way the law does. Vape pods and coils are in scope. Batteries, chargers and leads are not.
Before 1 January 2027:
- Add a cohort predicate to the rule engine, as a date comparison rather than a threshold. Do not encode it as
age >= 18with a note to update it annually. That note will not get actioned in January 2028. - Move cigarette papers and herbal smoking products into the tobacco rule. Check the taxonomy rather than assuming.
- Decide, in writing, what your verification method is for the cohort rule, because estimation alone cannot satisfy it. Document the decision and the reasoning. That document is the first thing you will hand trading standards.
- Fix the mixed basket case. One order, several predicates, all of them resolved before payment, with the failure telling the customer which line item blocked the order rather than refusing the whole basket with no explanation.
- If you use wallet credentials, work out today which
age_over_NNyou will request and accept that it over-refuses, or plan for birth date disclosure and write the data protection impact assessment that comes with it. There is no option that is both exact and minimal until a cohort attestation exists. - Log the predicate, not just the result. “Age check passed” is not evidence. “Cohort predicate dob < 2009-01-01 evaluated true, method mDL birth date disclosure, policy version 2027-01” is evidence.
- Update the point of sale notice if you have physical premises, and diarise the January date. A3, correct wording, and a fixed penalty if it is missing.
How Xident is built for this
We already run age verification for tobacco and vaping retailers, so this rule lands on us as well as on our customers. Three parts of our design turn out to matter more for a cohort rule than for a threshold one.
We record the predicate that was evaluated, not just a boolean. Every decision comes back as a record: outcome, method, threshold or predicate, confidence, policy version and timestamp. For a basket holding a vape and a pack of rolling papers, two different predicates were evaluated against the same customer, and the record says which was which. A stored ageVerified: true cannot tell you, six months later, whether the check that produced it was the 18 rule or the 2009 rule. Trading standards will ask exactly that.
The Check and Verification split is what makes “verify once, look up forever” affordable. A Verification is the document and identity path, with optical character recognition and a face match, and it is what can actually establish a date of birth. A Check covers browser-based age checks, liveness, returning-user Xident ID lookup and OAuth. On our Growth plan those are 0.20 EUR and 0.02 EUR, a factor of ten apart. Because a cohort answer never expires, the correct pattern is one Verification when a customer first buys tobacco, then a Check on every order after that, forever. That is the single largest cost lever available on this rule, and it only works if the two operations are separately priced rather than bundled into one blended per-check rate.
Estimation stays in the flow as a router, not as the decision. We are not going to tell you that facial age estimation solves the generational ban, because it cannot. What it can do is keep the expensive path small: send the customers who are plainly nowhere near the line straight through on the cheap path, and reserve the document or wallet step for the ones near it. That routing is worth building even though the population it filters shrinks a little every January.
The free sandbox grants 1,000 Checks and 100 document Verifications as one-time allowances rather than a monthly quota. The 100 Verifications exist so you can exercise the document path end to end, including the branch where it fails, before you pay for anything. A cohort predicate with a step-up branch is exactly the kind of code you want to have run against a real integration well before 1 January.
The short version
The UK has written an age rule that most age assurance systems cannot express, and it starts being enforced in 107 days.
It is not harder because the threshold is higher. It is harder because it is not a threshold. A fixed-date cohort rule needs a date of birth, and the last decade of work in this field has gone into building methods that deliberately never learn one: estimation that reads a face, credentials that disclose a single boolean, checks that return a band instead of a birthday. Every one of those is a good design. None of them answers the question the law now asks.
The gap is small today and it grows by one year every January. The systems that handle it well will be the ones that stopped treating age as an integer and started treating the rule as a predicate, with the date of birth reached for once, recorded as a decision rather than a document, and never asked for again.
The rule is written down. The date is fixed. The only variable left is whether the code can say it.
Xident provides age verification and age estimation infrastructure built around decision records rather than retained documents, with a cheap Check path for returning users and a separate document Verification path for establishing a date of birth. The free sandbox includes a one-time allowance of 1,000 Checks and 100 document Verifications. Talk to us about the January rule before it is December.
