Enforcing One Account Per Person Without Blocking Real Users

Every product that promises “one per customer” faces the same quiet failure: the same person quietly holds five. Multi-accounting drains referral budgets, resets usage limits, and lets banned users walk right back in.

Enforcing genuine one-account-per-person uniqueness is hard because the identifiers most teams rely on are the easiest to duplicate. The answer is to anchor identity to something a user cannot regenerate for free.

Why email and IP fail as uniqueness keys

The default instinct is to key accounts on email address or IP. Both crumble under trivial effort.

• Email is infinite. Disposable providers, plus-addressing, and aliasing services give one person unlimited “unique” addresses.
• IP is shared and rotating. Carrier-grade NAT puts thousands of real users behind one IP, while VPNs and proxies give one user thousands of IPs.
• Cookies are disposable. Incognito mode and a cache clear wipe any client-side marker instantly.

Keying uniqueness on these values means you either block innocent users who share an IP or wave through farms that rotate emails. Neither is acceptable.

Anchoring identity to the device

A durable device identity is the missing key. Hardware and browser environment produce a signature that is expensive to change at scale.

Prynt issues a persistent visitorId that stays stable across cleared cookies, incognito sessions, VPN switches, and email changes. When one device registers a second account, the visitorId links them even though the email, cookie, and IP all look brand new. That link is the foundation of real one-per-person enforcement.

• Persistent across resets, so shedding client state does not create a new identity.
• Server-side verified, so the signal cannot be spoofed by client tampering.
• Reputation-aware, so a device banned elsewhere in the network arrives already flagged.

Turning identity into enforcement

Having the link is half the job; acting on it gracefully is the other half. Blunt blocking creates false positives, so build a graduated policy.

• Query the device at signup for existing accounts tied to the same visitorId.
• Allow the first account freely to keep the common case frictionless.
• Set a sane per-device threshold that tolerates households and shared machines.
• Escalate on excess with verification, not an immediate block.
• Hard-block clear evasion, such as a banned device returning under a new email.

This keeps legitimate multi-user devices working while making farm-scale duplication expensive.

Ban evasion is the sharpest case

The most valuable use of one-per-person enforcement is stopping suspended users from returning. A ban means nothing if the user simply signs up again.

• Persist the device verdict so a banned visitorId stays banned regardless of new email or IP.
• Match on the strongest available signals rather than a single cookie.
• Watch for evasion tells like immediate VPN use, fresh disposable email, and scripted timing on the return attempt.

Because the device identity survives the exact tricks evaders use, the returning account surfaces immediately instead of weeks later. That speed matters: a ban evader caught at signup never gets the chance to resume the behavior that earned the original suspension, whereas one caught weeks later has already done fresh damage. Anchoring the ban to the device rather than the account turns a temporary inconvenience into a durable barrier.

Protecting real users from false positives

Uniqueness enforcement is only trustworthy if honest users rarely feel it. Shared and reset devices are the main risk.

• Never block on device alone; require corroborating risk signals.
• Use soft verification for ambiguous cases so genuine users have a path forward.
• Reset limits over time so a legitimately resold or reimaged device is not haunted forever.
• Monitor appeal rates as your early warning that thresholds are too tight.

Done well, the enforcement is invisible to the person signing up once and unavoidable for the person trying to sign up ten times.

Measuring uniqueness health

Track the metrics that reveal whether “one per person” is actually holding:

• Accounts per device, which should cluster near one for most of your base.
• Referral and promo cost per genuinely unique user, which should fall.
• Returned-ban rate, the share of banned users who successfully re-register.
• False-positive support volume, which should stay near zero.

One account per person is a promise most products make and few keep. Anchor identity to a device that abusers cannot cheaply regenerate, layer in graceful enforcement, and the promise finally becomes real. The reason so many teams give up on true uniqueness is that they tried to build it on email or IP and watched it fail, then concluded the goal was impossible. It was not impossible, only anchored to the wrong signal.

Start free and explore device-linked uniqueness in the playground.