Security

Keys that cannot be forged. Checks that never punish a paying customer.

Every license is a signed token your software checks on the customer's own machine. Here is exactly what it proves, what never leaves the device, what we hold on our side, and where the honest limits are.

The full rules, step by step, are public in the token format, so anyone can check them and write a verifier in any language.

On the device

Six layers in every license check.

Each one closes a specific way people try to get around licensing. None of them needs a connection.

Signed, so it cannot be faked

Every key is backed by an Ed25519 signature. The private signing key never leaves our servers; your software holds only the public half. Without that private key, nobody can build a working key generator.

Bound to one machine

An activation is tied to a fingerprint of the customer's computer. Copy the license file to another machine and it no longer matches, so one purchase cannot be passed around.

Pinned to the product

Each token names the product it was issued for. A key bought for one plugin will not unlock another, even from the same seller.

A sealed clock

Setting the computer's clock back does not stretch a trial or an expired lease. The latest time seen is sealed so it cannot be edited, and a rollback is treated as an expiring license, not a crash.

A lease that has to be renewed

The signed token lasts 30 days by default and renews quietly whenever the customer is online. A revoked license, or a cracked copy that cannot reach us, simply stops renewing.

One string, one meaning

Each part of the token must be in its one canonical form, and every field is checked for type and range after the signature passes. Odd spellings and malformed values are rejected, not guessed at.

Privacy by design

The hardware ID never leaves the computer.

To bind a license to a machine, your software reads the operating system's own machine ID, mixes it with a secret constant that is unique to your product, and hashes the result. Only that salted hash is ever sent.

  • Nothing to track across products

    Because each product uses its own salt, the same computer produces a different fingerprint for every product. The hash on its own does not reveal the machine ID, and it cannot be matched from one product to the next.

  • Keys are treated as credentials

    The API only speaks HTTPS, and the SDKs refuse to send a key over an unencrypted connection.

Revocation

Refund the order. The license follows.

A refund, cancellation or chargeback marks the license revoked on our side straight away. What happens next depends on how your product checks.

  • Online products: the next request

    Web apps, SaaS and APIs ask the server on every use, so there is no offline branch to patch and the refused answer comes back immediately.

  • Offline products: the next check-in

    A plugin that is online learns about it at its next renewal and stops. A machine that never reconnects stops when its lease and grace run out, 44 days at the most on the default settings, or sooner if you set a shorter offline window.

  • Device limits hold on the server

    Seat caps, and a budget of how many different machines a key can activate in a rolling window, are enforced on our side, where a patched copy cannot change them.

On our side

How we look after the parts you cannot see.

Signing keys encrypted at rest

Your private signing key is stored encrypted with AES-256-GCM, under a key derived for that one purpose and bound to its own record, so one stored secret can never be swapped in for another.

Least-privilege database access

The API runs under a restricted database role that can only touch the tables, and only the actions, it actually needs.

Key rotation without bricking

Every token names the key that signed it, so a signing key can be rotated after your next release reaches customers, without breaking a single installed copy.

Signed update notices

The "new version available" messages inside your software are signed with your key and verified before they show, so nobody can point your customers at a fake download.

Abuse limits

Public endpoints are rate limited per address, with a tighter limit on free demos, and request sizes are capped.

Status in the open

The API's health, including its database, is public on the status page, and you can point your own monitoring at it.

Fail open on doubt

A network blip never locks out a customer.

Locking out someone who paid costs more than a crack: it costs a refund and a review. So every check separates "the server said no" from "the server could not be reached".

  • A clear verdict acts

    Revoked, expired or blocked means stop, right away.

  • Anything uncertain waits

    No connection, a timeout or a server error keeps the stored license working and tries again later. An offline product carries on until its lease and grace run out.

The honest ceiling

Anyone with enough time can patch a program that runs on their own computer. Every offline scheme on the market, ours included, is eventually beaten that way. The cryptography is not where cracks happen; the one yes-or-no check in your code is.

  • Leases and server-side caps limit what a cracked copy can do and for how long.
  • Online mode leaves nothing on the device to patch. Use it wherever your product can.
  • Hardening spreads and varies the checks so one patch is not enough.

We measure protection in attacker hours and days to first crack, never "uncrackable". Hardening as a service, or the hardening guide to do it yourself.

No lock-in

An open format you can verify yourself.

The token format and every verification rule are documented. Clients written in Swift, C#, Kotlin, Rust, Go, Python and PHP check the same signed token, and the JUCE kit and TypeScript SDK do it for you.

Start here

Protect your next release.

Start on the Free plan, or tell us about your product and we will build it in and harden it for you.