No. The app never asks for a name, an email or a number, and there is no account to create. What leaves your phone is a key its own hardware made, and a signature from the company that built the device. With it go the store country of your download and a pseudonym for that store account, and the pseudonym is a different value at every service you bind to. We can tell that a real phone is on the other end. We cannot tell whose it is, and nothing we hold connects it to the account you opened.

The bindings go with it. The keys live in that phone’s secure hardware and cannot be copied out, not even by the manufacturer, so there is no transfer and no backup. On a new phone you bind again from scratch, and each service meets a device it has never seen. Nothing happens the moment the phone is gone: to a service, a lost phone looks like a phone on holiday until its window runs out, and then it stops counting as live.

Yes, by design. Delete Debind and every key on the phone dies with it; bind again and each service meets a device it has never seen. What it costs you is every other binding at the same moment. The fresh start is all or nothing, and there is no route to one at a single service while the rest stay. One thing doesn’t reset: if the phone was reported as a bot, that mark is held by the maker of the phone rather than by the app, and the deletion does not reach it.

A first mark can be lifted once, on the phone itself, with no email to write and no case to argue. The price is that you have to delete Debind first, which gives up every binding on that phone. Only then does the phone offer to lift the mark. After that the device works again and every service meets you as a new one. The service that reported you was told your old handle was marked, so that one decides for itself whether you get back in. A second mark is permanent. What expires after 90 days is our record of the block, not the block itself: a standing list of handles that were once bots is exactly what this system exists not to have. The one free pass is not leniency towards bots but margin for a service that reports too quickly.

One line, and only when you report someone. Each service holds its own value for that phone, so what arrives at another one is their handle, marked. The message ends there. Not that it was you who said so, not what the account did, not that the phone is bound to you at all. It works the same in reverse: when you hear that a device was reported, the message does not say by whom. We know who filed it, because the call is authenticated with their key. That is the one thing we never pass on.

Then you get all of it except one thing: word of a device somebody else caught. Everything else works with a single customer in the network, and that customer is you. A removal you hand out stays handed out, through a fresh sign-up and through the user disconnecting and reconnecting the phone. A device you report as a bot is marked in the phone maker’s own two bits, not only in our row for it, so a reinstall does not clear it, and that mark needs no network at all. What the network adds is the phone you haven’t caught yet, which is worth more to the tenth customer than to the first. Better you know that before signing than after.

Phones that can make a key inside secure hardware and have their maker vouch for it, which is the standard on current devices. The mechanism is the same on either side of the market, and what differs is wording rather than workings. The key has a different name, the two bits sit in a different data centre, and the binding, the handle and the way a removal sticks behave identically. If your users run older or unusual devices, tell us the mix and we will tell you what it covers instead of guessing in public.

Install a small free app, scan your code, confirm at the phone’s own lock screen. The app delivers the token itself, so there is nothing to read, copy or type, and if the signup runs on the same phone, it puts them back on your page when it’s done. No account, no verification email, no document to photograph.

Per device, per year. Nobody reads a document and nobody staffs a review queue, so you are not paying for anyone’s working hours, and that is where the gap to an identity check comes from. Rather than publish a table that fits nobody, we quote against your real volume. Tell us roughly how many accounts you’re protecting.

Only if you ship an app. The platform attestation APIs are free, but every one of them starts from a build signed under your own developer account. A web service has nothing to attest, and shipping an app so that one signup step works is a project rather than an integration. Debind is that app, and one install covers every service in the network. The other half cannot be built in-house at any price, because it is the phone somebody else caught. There is also a distinction that is easy to miss: a key merely stored in secure hardware proves possession of a phone, while a key attested at creation proves it was made by real hardware in an unmodified app. Neither rules out a rack of rented real phones, which is a price rather than a wall, and the last answer here says so.

Hours, not seconds, and we will not sell you a deadline. A report is held until the phone next speaks to us, because the device bits can only be written while the app is running. We cannot reach a phone of our choosing, by design. A phone answers for one binding per wake-up and is woken about every two hours, less between one and six in the morning, so a phone carrying six bindings works through them in roughly half a day. Setting the mark stops new tokens outright. A marked device binds nowhere, including at services it has never met. A phone that is switched off, in low power mode or swiped out of the app switcher is marked when it comes back, and not before.

Yes, once. That single exception is the one thing our strongest claim does not cover. A device that carries a mark hands us all its token codes in a single call, so every service hears in one go instead of over half a day, and in that moment our server sees which bindings share a phone. Two things bound it: the call is refused unless the mark is set, so a clean device can never volunteer the grouping, and the group is used to lock the bindings and then dropped rather than stored. We built it knowing the price, because the alternative was worse. Once the block screen shows up, an operator stops opening the app, and the services that would then never hear are the ones the report was meant to reach.

Every binding that already stands keeps working. Your database holds the handle, and verify is a read you can cache. What stops is new bindings, and a token lives two minutes, so there is nothing to queue and retry. Let the signup through unbound and ask for the binding at the next login. The same rule holds when the device vendor is unreachable: reading the device bits has a four-second budget, and a timeout comes back as unknown. Unknown is neither clean nor marked, so nothing is blocked, nothing is written, and a pending report waits for the next check-in. We fail open on purpose. An outage must not lock out your users, and it cannot clear a mark either.

Every binding on that phone ends. We end them, the store does not. The app can still sign at that moment, so it reports every binding as wiped before it throws away the key handles for good. It tells the user this cannot be undone, and does not ask first. Your service sees the binding end with a reason, wiped, where a deleted app would leave only a long silence. The label is best-effort. A phone that is offline at that moment wipes anyway. It is worth knowing before you sign if your users move countries often: they bind again from the new one, and nothing carries over.

Some already do, and the part that hurts them isn’t the labour. A script can set up a phone; it can’t manufacture one. What binding changes is what a caught bot costs. Elsewhere the answer is a banned account and a fresh signup, which is free. Here the report lands on the device: the binding it came from is dead, and the phone is marked. A second report retires that phone from the network for good. One lift per device, ever, so no factory reset brings it back and there is nothing to resell into the next rack.

Note what this doesn’t depend on. It isn’t a rule about how many accounts sit on a phone; one account behaving like a bot spends the hardware just as thoroughly as fifty. That is what makes it a brake on automation rather than on volume. And it is paid on a clock the farm doesn’t set: however often the behaviour gives itself away, that is how often a phone has to be bought.

The network is what winds that clock. A phone bound at several members is exposed to all of their detection at the same time, and a report from any one of them marks it for every other, including the ones it never slipped up at. So a farm has to beat the sharpest bot detection in the network rather than the weakest, and each service that joins is one more way for the same hardware to be spent. Detection that used to cost a competitor nothing to build now shortens the life of devices attacking everyone else. Piling bindings onto one device only raises the stakes, since a single report then takes every one of them, including those at services that never noticed anything. Each of those bindings is also confirmed less often, because one wake-up produces one signature, and a service watching for a recent signature sees the gap. What we don’t claim is proof of personhood. We prove devices, one person can own several, and you should put that in your numbers from the start.