Scanning an ID for age verification is legal almost everywhere. What you do with the data afterwards is where venues get into trouble — and where the class actions come from. A plain guide to the rules that actually apply to your door.

Every operator who considers electronic age verification eventually asks the same question, usually in a slightly worried tone: am I actually allowed to do this?

Yes. In almost every jurisdiction, scanning a government-issued licence to verify age and detect counterfeits is straightforwardly legal, and several states explicitly encourage it by writing scan records into their liquor statutes.

The legal risk is not in the scan. It is in everything that happens after — what you keep, how long you keep it, where it is stored, and what else you use it for. That is where the fines and the class actions live, and it is almost entirely a question of which software you chose.

Not legal advice. Privacy law in this area is moving quickly and varies by state. Use this to ask your counsel better questions, not to replace them.

What is actually in the data you just captured

When the PDF417 barcode on the back of a US or Canadian licence decodes, it does not return “over 21.” It returns a structured text record containing, depending on the issuing state: full legal name, date of birth, full residential address, licence number, issue and expiry dates, sex, height, eye colour, and sometimes more.

That is worth sitting with. Your door has just captured the home address of everyone who walked in.

For age verification you needed exactly one field, and only the answer derived from it. Everything else is data you now have custody of — and in privacy law, custody is liability. The single most effective compliance decision available to a venue is simply not to retain the fields it has no use for.

Legitimate uses, and the ones that create exposure

Broadly, regulators are comfortable with scanning that serves the purpose it was collected for, and hostile to everything else.

Generally accepted: verifying age for alcohol, tobacco or entry; detecting forged or altered documents; maintaining your own ban list of individuals you have refused or ejected; keeping a timestamped compliance log; counting occupancy.

Where venues get into trouble: selling or sharing patron data with data brokers or marketing networks — prohibited under essentially every state privacy framework; adding scanned patrons to marketing lists and texting or emailing them without separate, explicit opt-in consent; retaining full addresses and licence numbers indefinitely because the software defaulted to it and nobody changed the setting.

The pattern behind all three is purpose limitation: you collected this to check an age, so use it to check an age. The moment ID data becomes a marketing asset, you have changed its legal character and taken on obligations — notice, consent, deletion rights — that most venues are not set up to meet.

CCPA, BIPA and retention: the three that matter

CCPA / CPRA — California

California’s framework governs how you collect, store and disclose personal information about California residents, and it grants those residents rights over it — including the right to know what you hold and to request deletion.

For a venue, the practical implications are notice and deletion. If you are retaining patron data, people are entitled to be told at the point of collection, which in practice means signage at the door, and you need a route by which someone can ask you to delete what you hold. Whether you fall inside CCPA’s thresholds depends on your revenue and how much data you handle — check, rather than assume you are too small.

The cleanest position, and the one worth aiming at: if you do not retain the personal fields at all, most of this becomes moot. You cannot be asked to delete what you never kept.

BIPA — Illinois, and the distinction that decides everything

Illinois’s Biometric Information Privacy Act is the reason this topic makes lawyers nervous. It carries a private right of action and statutory damages per violation, which is what has produced the very large settlements you may have read about. Multiply a per-person figure by every patron who came through your door over a couple of years and the arithmetic gets frightening quickly.

The critical distinction:

Reading a barcode is not biometric. Parsing PDF417 extracts text — a name, a date, an address. Text is not a biometric identifier, so ordinary barcode-based age verification does not, on its own, trigger BIPA’s consent requirements.

Face matching is biometric. The moment your system analyses a patron’s facial geometry — a camera comparing the live face against the photo on the card, or against a database of previously banned faces — you are collecting biometric identifiers, and BIPA applies in full. That means written notice, a published retention and destruction schedule, and a signed written release before the first scan. Not a sign on the wall. Not implied consent from entering.

This matters because face matching is exactly the feature that gets sold hardest, and it genuinely does solve a real problem — the borrowed-but-genuine ID that no barcode check can catch. It is not a feature to avoid. It is a feature to deploy deliberately, with consent flows in place, rather than because a vendor enabled it by default.

If you operate in Illinois, or in any of the states that have followed its lead, know which mode your scanner is in before you turn it on.

Retention limits

Several states cap how long ID scan records may be held, and some specify what may be kept at all — a few restrict retained fields to little more than the fact of the check and its result. These rules differ enough that a number quoted for one state is actively misleading for another, so look up your own rather than trusting any figure you read online, including here.

Two things are true nearly everywhere:

Longer is not safer. Operators tend to assume more record is more defence. Past your board’s evidentiary window, additional retention adds breach exposure and, in states with retention caps, becomes the violation itself.
Purging should be automatic. A policy that depends on someone remembering to clear records quarterly is a policy that will be found not to have run. Set the window in software and let it enforce itself.

The cloud question

A lot of scanning products — particularly the ones built around a hardware unit and a subscription back end — upload full parsed records to the vendor’s servers by default. Names, addresses, licence numbers, all of it, for every patron.

Consider what that means. Your venue has become a contributing node to a large, centralised, extremely attractive database of identity documents. If that database is breached or misconfigured, your patrons’ data leaked, and the notification obligations, the attorney-general interest and the damage to your reputation land on you. Your contract with the vendor may allocate some of the cost. It will not persuade a regulator that the exposure was not yours, and it will not persuade your customers.

The question to put to any vendor, in writing:

What leaves the device, exactly — field by field?
What is stored on your servers, and for how long?
Can retention be configured, and can personal fields be discarded at parse time?
What happens to our data if we cancel?
Have you been breached, and what is your notification commitment if you are?

Vague answers are answers. “Enterprise-grade security” is not a response to “what fields do you store.”

The architecture that removes the problem

The reason to prefer on-device processing is not that it sounds modern. It is that it eliminates the category of risk rather than managing it.

If the barcode is parsed in the phone’s memory, the age is derived there, and the personal fields are discarded rather than transmitted, then there is no central database of patron identities to breach, no retention schedule to enforce across a vendor’s infrastructure, and nothing to hand over or delete because nothing was kept.

What you keep is the part you actually need for your compliance defence: that a check occurred, when, on which device, by which staff member, and what the result was. That record is small, it is not especially sensitive, and it is exactly what a liquor board asks to see — while the address of the twenty-three-year-old who came in at half eleven is nobody’s business, including yours.

The exception is your own ban list. If you have refused or ejected someone and need your doors to recognise them, that is deliberate retention for a legitimate safety purpose — and it should be a conscious act by a manager, applying to a handful of people, not the default state of everyone who walks in.

A short compliance checklist

Know which mode you are in. Barcode only, or face matching? The legal obligations are completely different, and the answer should not surprise you.
Retain the minimum. Ideally the fact and result of the check, not the person’s details.
Set a retention window, in software. Long enough for your board’s evidentiary needs, and not a day longer.
Put up notice at the door if you retain anything. It is cheap and it is the first thing a regulator looks for.
Never let ID data become marketing data without separate, explicit, recorded consent.
Interrogate your vendor’s data flows before you sign, not after a breach.
Ask your own counsel about the states you actually operate in.

Where we stand

We are building the phone version, and the design goal is the one described above: identity data read on-device and never sent anywhere, with what syncs being the fact that a check happened and its result rather than the person. No face matching in the first release, specifically so that the BIPA question does not arise for the venues using it.

The privacy policy will state the final architecture in plain language before launch, and if that goal changes you will hear about it before you are asked to pay. If this is the part you care about, the early access list below is where to tell us so.

Is Scanning Driver's Licences Legal? A Venue Guide to CCPA, BIPA and Retention