Originally published on the Keylight blog.
Once an app has paying customers, one key inevitably shows up in a forum or a group chat, working for everyone who pastes it. The instinct is to clamp down hard. But aggressive anti-sharing measures hurt honest customers far more reliably than they hurt sharers. This post is about preventing key sharing in a way that does not make your real customers collateral damage.
Accept what you cannot prevent
Start with an honest premise: you cannot make key sharing impossible. A determined person with one machine can always run one legitimate-looking copy. Any scheme that claims otherwise is either lying or about to break something for paying customers.
So the goal is not "zero sharing." The goal is to make a license key behave like what it is meant to be β a license for one person and their handful of devices β rather than a master key to your product. That is an achievable, well-defined target. "Stop all piracy" is not.
The mechanism: device activation limits
The tool that actually works is the device activation limit. Each key is valid for a bounded number of devices. When the app runs on a machine for the first time, it activates: it registers that device with the licensing server, which checks the count against the limit and admits or refuses it.
Devices are recognised by a fingerprint β a stable identifier derived from the machine's hardware and install characteristics, hashed before it leaves the device so the server stores an opaque token, not a description of anyone's computer. The fingerprint's only job is equality: same device, or new device?
This is what stops the forum-posted key. The key still works β but only on the first N machines that activate it. The hundred-and-first install is refused. Sharing is capped at the limit you set, instead of being unlimited. The mechanics are covered in full in the app activation system guide.
Why hard blocks backfire
Here is where most anti-sharing schemes go wrong: they treat every ambiguous signal as guilt and respond with a hard block.
A customer reinstalls macOS and their fingerprint shifts slightly β hard block, "this license is invalid." A customer replaces a drive β hard block. A customer is the first person to legitimately install on their new laptop, but the key is at its limit because the old one was never removed β hard block.
Every one of those is a paying customer hitting a wall you built for pirates. They do not experience it as anti-piracy; they experience it as your app being broken and hostile. You will lose more goodwill from these false positives than you ever lose revenue to the actual sharers, because there are far more honest customers than dishonest ones.
The fix is two principles.
Be generous. A limit of one device is hostile β most people have a laptop and a desktop. Three to five for a personal license stops a key being shared across an organisation while being invisible to any real customer. The limit should constrain sharing, not normal multi-machine use.
Degrade gracefully. When something is ambiguous, do not hard-block. If a periodic re-check cannot reach the server, keep running on the last valid license β do not lock the customer out over your own outage. Reserve the hard "no" for the unambiguous case: a genuinely new device, genuinely past a generous limit.
Deactivation is the other half
A device limit without deactivation is a trap that springs on honest customers. People replace computers constantly. If activations only ever accumulate, every loyal customer eventually hits the limit on hardware they no longer own.
The answer is self-service deactivation: a customer portal listing the customer's activated devices, each with a remove button. Removing a device frees a slot instantly. The customer rearranges their own machines without a support ticket, and the limit stays meaningful because it is never the thing blocking a legitimate move.
In the app, hitting the limit should surface as a clear, actionable message β not a dead end:
await licensing.activate(key: enteredKey)
if case .invalid = licensing.state {
// activationError explains the limit was reached;
// point the customer at the portal to free a device.
showActivationError(licensing.activationError)
}
The balance
Preventing license key sharing is a balance, not a war. A generous device limit plus painless self-service deactivation caps sharing at a reasonable number while being effectively invisible to every honest customer. A stingy one-device limit with hard blocks and no deactivation barely inconveniences a determined sharer and reliably angers the people paying you.
Aim for the first. If you have an anti-sharing edge case worth a deeper post, send us your feedback.
FAQ
How do I stop customers sharing license keys?
Bind each key to a limited number of devices with an activation limit. The licensing system records each device and refuses activations past the limit, so one key cannot supply an unlimited number of installs.
How do I avoid punishing legitimate customers with anti-sharing measures?
Set a generous device limit, make deactivation self-service so customers can move between machines, and degrade gracefully rather than hard-blocking on an ambiguous signal.
Can license key sharing ever be fully prevented?
No. One person with one device can always run one copy. The realistic goal is to make a key behave like a personal license, not a site license β which activation limits achieve.
