How License Keys Work for Desktop Apps

The “XXXXX-XXXXX-XXXXX” string you paste into a registration window looks simple, and the idea behind it is simple. But what makes a license key actually secure has changed completely over the last two decades. This post explains how license keys work for desktop apps today, and why the old way no longer holds up.

The old way: checksum keys

For a long time, a license key was a string that was valid if its characters satisfied some arithmetic rule. The app contained the rule. When a customer typed in a key, the app ran the check locally: do these digits sum to the right value, do these segments relate in the expected way? If yes, unlock.

This was cheap and worked offline, but it had a fatal flaw. The validity lived in a pattern, and patterns can be reverse-engineered. Once one person worked out the rule — or simply found one key that passed — that key, or a generator for it, ended up on the internet. The app had no way to tell a paying customer’s key from a pirate’s, because both satisfied the same rule.

Checksum keys are not a security mechanism anymore. They are a speed bump.

The modern way: signed keys

A modern license key does not encode validity in a pattern. It carries a cryptographic signature — proof that a server you control minted this specific key for this specific entitlement.

It works with a key pair. The server holds a secret private key and uses it to sign. The app ships with the matching public key and uses it to verify. The mathematics of the algorithm — Ed25519 is the standard choice — guarantees two things: only the holder of the private key can produce a signature the public key accepts, and the public key reveals nothing that helps forge one.

So you can embed the public key in every copy of your app, ship it to the whole world, and an attacker still cannot mint a working key. The validity no longer lives in a guessable pattern; it lives in a signature only your server can produce.

What is actually inside the key

A signed key is not just a random-looking string — it is a small structured document, an entitlement, with a signature attached. It typically carries who the license belongs to, which product and plan it covers, when it was issued, when it expires (if ever), and how many devices it may activate:

{
  "id": "lk_01hx9z4bqncktjvx6a2r3p8wy",
  "productId": "prod_myapp_pro",
  "plan": "pro",
  "activationLimit": 3,
  "issuedAt": "2026-05-15T09:12:00Z",
  "expiresAt": null,
  "revoked": false,
  "sig": "base64url(ed25519_signature)"
}

The signature covers every field above it. If anyone edits a single character — bumping activationLimit from 3 to 99, or flipping revoked to false after a refund — the signature no longer matches, and the app rejects the key. The customer holds the document, but they cannot change what it says.

How the app checks it

When your app has a key, validation is a local computation: parse the document, run the signature check with the embedded public key, then read the plain fields — is it expired, is it revoked, is it within its device limit. No server call. The app can do this on a plane.

That is the headline benefit of signed keys for desktop apps specifically. A web app can validate against its server on every request for free, because it is always online. A desktop app is not always online, and a license check that needs the network will fail for legitimate customers. Signed keys remove that dependency. For the full treatment of local verification, see software license keys explained.

Revocation is the one thing local verification cannot do alone — a key the app has never been told about cannot know it was refunded. So signed-key systems add a periodic online re-check: every few days, when the app has a connection, it reconfirms the key server-side and picks up any revocation. Everyday validation stays offline; only the occasional re-check needs the network.

What this means if you are building it

If you are adding licensing to a desktop app, the takeaway is: do not ship checksum keys. They will not protect your revenue. You want signed keys — which means a private key to manage, a signing service, an entitlement format, verification code in your app, and the periodic re-check logic.

That is a real amount of infrastructure, which is why licensing layers exist to provide it. However you build it, the model is the same: a signed document the customer cannot forge or edit, verified locally by your app. If there is an angle on license keys you would like covered in more depth, send us your feedback.