On 11 August 2026 the IETF published RFC 10027, “Best Current Practice for Security of Cross-Device Flows” (RFC Editor). It is a security document about protocol flows that start on one device and finish on another. The very first example in its introduction is a user scanning a QR code from their smart TV with their phone.
Almost nobody in age assurance has read it. That is a problem. The living room is where a lot of age checks are about to happen, and the pattern the industry has already settled on for them is the one this document was written about.
Around 90% of US TV households now have at least one internet-connected TV device, across roughly 500 million devices, with three to four per household on average (MNTN). Those are marketing-research numbers rather than audited ones, so treat them as an order of magnitude rather than a measurement. The order of magnitude is the point: this is not a niche surface.
And there is no exemption for it. Ofcom’s guidance on highly effective age assurance is deliberately technology-neutral, which cuts both ways. It does not tell you which method to use, and it does not tell you that a television is too hard. The criteria are the same four, technical accuracy, robustness, reliability and fairness, with accessibility and interoperability on top. A TV app inside scope is inside scope. The same is true of the DSA in the EU. Nobody drafted a carve-out for the couch.
Three things a television cannot do
Take the methods that actually work in 2026 and try to run them on a TV.
Facial age estimation needs a camera pointed at a face. Most smart TVs do not have one. The ones that do have it aimed across a room at whoever is sitting there. That is a very different capture problem from a phone held at arm’s length: distance, bad lighting, off-axis angle, and several people in frame. Consoles are slightly better placed because a camera peripheral exists, but few people own one and the capture geometry is the same.
Document verification needs a capture device and a keyboard. Reading a passport’s machine-readable zone means holding a document in front of a decent camera. NFC chip reading means tapping a document against a reader. A TV has neither. And a TV remote is a directional pad; nobody is entering a document number on an on-screen keyboard, one letter at a time, to watch something.
Wallet presentation needs a wallet. The W3C Digital Credentials API lives in browsers, and the credential lives on a phone. A Tizen or Roku app is not a browser with that API, and the TV is not where the user’s mobile driving licence is stored.
So the check cannot happen on the device that needs the answer. It has to happen somewhere else and the result has to be carried back. Every vendor working on this arrives at the same conclusion within about an hour, and then reaches for the same primitive.
The primitive everybody reaches for
The OAuth 2.0 Device Authorization Grant, RFC 8628. The TV displays a short code and a URL. The user opens that URL on their phone, types the code, completes whatever the service asks for, and the TV polls until it gets a token. Most large streaming services already use it for sign-in, so the app scaffolding exists and the users already understand the gesture.
The codes are short because a human types them on the second device. RFC 8628 is explicit about the trade: shorter is better for usability, so the entropy is lower than you would accept anywhere else in OAuth. Its worked example is an eight-character base-20 code at roughly 34.5 bits, which combined with a five-attempt rate limit gives about a 2^-32 chance of a successful random guess (RFC 8628). That maths is fine. Brute force is not the attack.
The attack is that the code travels over a channel that neither device can authenticate. The TV cannot prove to the phone that it is the thing that generated the code. The phone cannot prove to the TV that the person holding it is the person sitting on the sofa. RFC 10027 puts the consequence plainly: the responsibility for authenticating the channel between the two devices falls on the end user, and end users have, in the document’s phrase, “expertise elsewhere”. They are not security experts and they do not understand the protocols they are interacting with. They are poorly equipped to do the job the protocol has handed them.
Attackers noticed. Device code phishing grew sharply through 2026: Push Security first measured a roughly fifteen-fold rise and has revised that figure upward since, with Microsoft reporting new campaigns appearing daily and Barracuda counting millions of attempts in a four-week window (Push Security). These are vendor telemetry figures from companies that sell defences against the thing they are counting, so the absolute numbers deserve scepticism, and the multiple has moved enough during the year that no single number is worth quoting as fact. The shape is not in doubt. The attack works because it uses the real login page on the real domain, which means URL reputation, proxies and “check the address bar” all fail by design.
The mechanic is simple. The attacker starts a device flow against a legitimate service, receives a genuine code, and sends it to a victim with a plausible reason to enter it. The victim enters a real code on a real page and authorises a session they did not start.
What RFC 10027 actually requires
The document is a Best Current Practice, BCP 247. That is a category of its own rather than a weaker kind of standard: a finished RFC that carries the IETF’s consensus on how to operate something, as opposed to how to encode it on the wire. Its section 2 is five sentences long and worth reading literally:
- Implementers MUST perform a risk assessment before implementing cross-device flows, weighing the risks against the benefits for users.
- Implementers SHOULD avoid cross-device flows if the risks cannot be sufficiently mitigated.
- Implementers SHOULD follow the document’s protocol selection guidance.
- Implementers MUST select appropriate mitigations to address the risks identified.
- Implementers SHOULD include proximity as one of the selected mitigations, if possible.
That second one is unusual, and it is the one to sit with. A standards body looked at a widely deployed pattern and said the correct answer is sometimes not to ship it.
On the last point, the document is specific about what counts as proximity and what each option costs you. Physical connectivity is the strongest signal and the worst user experience. Wireless proximity through NFC, Bluetooth Low Energy or ultra-wideband is the recommended route. Within that, the document names FIDO and WebAuthn cross-device flows as the recommended approach, because they use BLE purely as a proximity check rather than as a data channel. For presenting credentials specifically, it points at the W3C Digital Credentials API.
Shared-network checks are weaker than they look, and the document gives the exact reason a TV deployment will hit: the television is on Wi-Fi and the phone is on a mobile network. Two devices two feet apart, no shared network, check fails. Geolocation has the mirror problem near borders and with VPNs, and an attacker can read a victim’s location through a browser API and then spoof the same coordinates on their own machine using ordinary debugging tools.
After proximity, section 6 lists thirteen more practical mitigations, each with an honest limitation attached. Short-lived codes, one-time codes, unique codes with a deny list, content filtering, detection and remediation. Then trusted devices, trusted networks, limited scopes, short-lived tokens, rate limits, sender-constrained tokens, user education, and user experience changes. Defence in depth, no single fix.
Take all of that, apply it to a streaming sign-in, and you get a meaningfully safer flow.
Now apply it to an age check, and about half of it stops working.
Age assurance breaks the threat model
Every mitigation in RFC 10027 is built on one assumption: the user is a victim. Someone is trying to trick them into approving something they did not initiate, and they would not approve it if they understood what was happening. Warn them better, filter the message before it arrives, prove the two devices are close together, and the attack collapses.
Age assurance inverts that assumption completely.
The person defeating an age gate is the account holder. They are not being deceived. They know exactly what the code is for and they want it redeemed. And they do not need to phish a stranger, because the second device they need is usually about four metres away, attached to a parent, an older sibling, or a friend who is eighteen.
That single change re-prices every row on the list, and knocks several of them out entirely:
| RFC 10027 mitigation | Login (unwilling victim) | Age check (willing accomplice) |
|---|---|---|
| Establish proximity | Strong. Breaks remote scaled attacks. | Weak against the main case. The adult is in the same room. Still keep it: it breaks the remote case, where a code is posted to a forum for any adult to redeem. |
| Short-lived codes | Good. Shrinks the window. | Almost no effect. The handoff takes twenty seconds. |
| One-time and unique codes | Good. Stops one code hitting many victims. | Some effect. Stops one adult’s redemption being replayed, which matters more than it sounds. |
| Content filtering | Good. Blocks the delivery channel. | None. The code is read off a screen across a coffee table. |
| Trusted devices | Good. Attacker cannot initiate the flow. | Poor. The TV is a genuine trusted device. That is the problem. |
| User education | Modest, and the RFC says insufficient alone. | None. Nobody is confused. |
| Detect and remediate | Good. Revoke the session. | Partial, and only if you count redemptions per authorising credential rather than per account. |
| Short-lived tokens | Good. Caps the damage. | Useful, if the age result expires with the token rather than outliving it. |
| Rate limits | Good against scaled attacks. | Genuinely useful here. One adult phone redeeming codes for many accounts is a strong signal. |
Read that column and the conclusion is uncomfortable. The security literature on cross-device flows is about keeping an attacker out of a user’s account. Age assurance needs to keep a user out of their own content. Those are not the same engineering problem, and borrowing the controls wholesale gives you a flow that is hardened against the attack you do not have.
This is the binding problem again, but structurally worse. On a phone, a proxy verification is something that happens despite your design. In a cross-device flow it is the design. You have built a supported, documented, first-class path for one person to answer an age question on behalf of a session belonging to someone else, and then you have put it in the room where the whole family sits.
Carry the result, do not perform the check
The fix is a change of what the handoff is for.
If the phone runs a fresh age check whose only purpose is to unlock this TV session right now, then any adult with a phone can unlock any session, and no amount of protocol hardening changes that. The check is answering the wrong question. It answers “is an adult present”, which is trivially satisfiable and nearly worthless. It does not answer “is the person this account belongs to an adult”, which is the question the regulation actually asks.
So the handoff should not perform a check. It should carry a result that was already bound to an account holder at some earlier point, on a device capable of binding it.
Concretely, the flow inverts. The phone does not become a verification terminal for the TV. The phone proves that the account holder, whose age was established when they signed up on a device with a camera, is the one authorising this session. That is a much smaller claim and a much harder one to delegate, because the adult in the room cannot satisfy it. They are not the account holder. Their credential does not match.
This is the practical argument for reusable credentials that nobody makes. They are usually sold on conversion and friction. The real point here is that a credential bound to a person can cross a device boundary safely, and a live check performed in the moment cannot, because the moment is exactly what the accomplice supplies.
Five things follow from that.
Profiles, not devices. A television is a household appliance. Treating one verified adult as evidence that the device is an adult device is the same mistake as treating a passed check as a verified session. The unit of age assurance is a profile, and a profile switch on the remote must switch the age state with it. Most TV apps today store entitlement at the device level because that is how sign-in works. Age is not sign-in.
Use proximity anyway, for the case it does cover. It will not stop the kid handing the remote to a parent. It will stop a code being pasted into a forum for any passing adult to redeem, and it will stop the cross-device consent phishing attacks the RFC is actually about. FIDO hybrid transport, which the RFC recommends, gives you a BLE proximity check without BLE carrying any of the data. Where the credential is a wallet credential, the Digital Credentials API cross-device flow is the right shape, and we have written separately about wallet-based age verification.
Rate limit the redeemer, not just the code. This is the one control that transfers cleanly and it is the one almost nobody implements. Count redemptions per authorising credential. One phone that has authorised age for eleven different accounts across six households in a month is not a user, it is a service. That signal does not exist in your logs today unless you deliberately record which credential redeemed which session, and you should.
Make the TV result expire faster than a phone result. The evidence is weaker, so the life of the result should be shorter, which is the same principle we argued in age check expiry. A result established by a cross-device handoff on a shared household device is the weakest form of evidence in your system. Treating it as equivalent to a bound, on-device, liveness-backed check is a record-keeping error that a regulator can read straight off your schema.
Write the channel into the decision record. A regulator asks how a given user was verified. “Facial age estimation, passed” is not an answer if the estimation happened on a different device, at a different time, at the request of a television. Your decision record needs five fields: the method, the device class that ran it, the device class that consumed it, which proximity signal was satisfied, and which credential authorised the transfer. We have argued before that the evidence is the product as much as the check is. Cross-device flows are where that gets tested, because they are the one place where the honest answer is “somewhere else, by someone we should be able to name”.
A shorter checklist
If you ship an app on a television, a console, a set-top box or a streaming stick, and any part of it is age-gated:
- Do the risk assessment RFC 10027 says you MUST do, and write down the willing-accomplice case explicitly, because the standard threat model will not surface it for you.
- Check whether your handoff performs a check or carries a bound result. If it performs one, you have built a delegation feature.
- Move age state from the device to the profile, and make profile switching change it.
- Add a proximity signal, knowing what it does and does not cover, and prefer BLE-backed FIDO or the Digital Credentials API over a typed code.
- Instrument redemptions per authorising credential and alert on the distribution, not just the volume.
- Give cross-device results a shorter validity than on-device ones.
- Record the channel in the decision record, not just the outcome.
- Take the RFC’s second sentence seriously. If you cannot mitigate the risks, the recommended answer is to not offer age-gated content on that surface, and that is a legitimate product decision rather than a failure.
How Xident fits
Our position here is the one the argument above implies, and it is worth being precise about what is built and what is not.
Xident’s model separates two operation types deliberately. A Verification is the expensive path: document capture, OCR, face match, NFC where the document supports it. A Check is the cheap path, and it covers the returning-user Xident ID lookup, browser-level age checks, liveness and OAuth handoffs. That split exists for cost reasons, but it maps exactly onto the cross-device problem. The document check happens once, on a device that can actually do it, and binds a result to a person. Every subsequent surface, including a television, resolves a Check against that existing bound result rather than running a new verification for a session.
That is what makes a living-room handoff defensible: the TV is not asking “is an adult here”, it is resolving whether this profile’s holder already carries a verified age classification. The reusable token is bound to the subject rather than being a copyable flag, which is the property that makes the accomplice case harder rather than easier. And because a Check costs roughly an order of magnitude less than a Verification, resolving an existing credential on every device in a household is not the thing that breaks your unit economics. Re-verifying on each one would be.
What we do not have is a magic answer to the accomplice sitting on the sofa. Nobody does. A determined fourteen-year-old with a cooperative adult in the same room can defeat any cross-device age check that exists today, including ours, and any vendor telling you otherwise is selling something. What you can do is make it cost a real adult’s real bound credential every time. Make each redemption visible in your logs. Make the resulting state expire quickly, and make the evidence trail honest about which device answered the question. That moves the failure from silent and unbounded to observable and rate-limited, which is the actual difference between a control and a gesture.
The part worth repeating
The age assurance industry has spent three years arguing about accuracy. False acceptance rates, mean absolute error, NIST evaluations, effectiveness thresholds. All of it measured on the assumption that the check happens on the device the user is holding.
In the living room it does not, and the accuracy of the estimator is irrelevant, because the estimator will be pointed at a face that genuinely is over eighteen. The failure is not in the measurement. It is in the two feet of unauthenticated space between the phone and the television, and it is the same two feet the IETF has just published a Best Current Practice about.
That document has been available since 11 August. It takes an afternoon to read.
If you are working out what your TV or console surface should actually do, we are happy to go through it with you.
