Offline Licenses

What is an offline license?

An offline license is a license that can be used in an offline or air-gapped computing environment, i.e. a device that has no or limited access to the public internet.

The simplest offline licenses are those which allow you to check their "authenticity", that the offline license key was indeed created by you. They have no embedded data, or at least, the data that is embedded into the key is not utilized within your code, i.e. it has no value.

More complex offline-capable licensing systems may have a useful dataset embedded inside of the key itself, which can be decoded/decrypted and utilized in your software. Embedded key datasets may include things like license expiration, grace periods and offline use limitations, customer and device information, and general license entitlement data.

How do I implement an offline license?

The easiest way to get started with an offline-capable license is to add a cryptographic scheme to a new Policy. Choosing a cryptographic scheme will instruct our systems to encrypt or sign all license keys which implement the Policy.

Many of these solutions can be packed into an easy-to-use and easy-to-distribute license file or certificate, and delivered via email, USB key or other means. This isn't required, but it does offer a better user experience when activating offline devices compared to copy and pasting (or worse: hand-typing!) long cryptographic license keys.

Signed license keys

Signed license keys are made up of an encoded dataset and a signature. These values can be parsed in your software application and crytographically verified using ECC or RSA.

Below is a breakdown of a signed license key's format:

Diagram of a signed license key

The encoded dataset is completely under your control, and can be arbitrary text, a JSON object, XML, or any other text format. But you can also use the default dataset, which is a JSON object, if you don't have any specific requirements. In this example, we'll use the user's email.

Parsing the dataset and verifying its authenticity can be performed like so:

Diagram of verifying a signed license key

The signing prefix and encoded dataset are delimited by a / character (forward slash), while the signing data and the signature are delimited by a . character (dot).

The following policy signing schemes are available:

  • RSA_2048_PKCS1_PSS_SIGN_V2
  • RSA_2048_PKCS1_SIGN_V2
  • ED25519_SIGN

For further information on signing schemes, check out the API reference.

View Documentation

Encrypted license keys

Encrypted license keys are similar to signed keys, but the format is a lot simpler. Encrypted licence keys solely consist of an embedded dataset. In this example, we'll use the user's email address as the embedded dataset.

Below is an example of decrypting an encrypted key:

Diagram of decrypting an encrypted license key

Successfully decrypted keys can be utilized within your software, or discarded after a successful decryption if the embedded dataset is not needed elsewhere. Encrypted keys that fail decryption should be considered invalid.

The following policy encryption schemes are available:


For further information on encryption schemes, check out the API reference.

View Documentation

Offline activation proofs

Similar to signed license keys, you can also generate machine-specific "proofs of activation." This will allow you to activate 100% air-gapped devices, while cryptographically verifying that the current device matches the activated machine on record, all without an internet connection or on-premise licence activation server.

The format is similar to signed license keys, but the signing prefix is proof instead of key. Similarly, activation proofs are made up of an encoded dataset and a signature.

Diagram of an offline device activation proof

Typically, at minimum, you would want to embed a fingerprint of the activated device into the proof's embedded dataset, and compare it to the offline device's fingerprint after the proof's authenticity has been verified. You would also want to compare the proof's embedded license key to the license key that was registered with the offline device, as well as ensure the product ID matches the currently running product (if you have multiple products).

The default dataset for activation proofs include information about the license, the product, and the activated machine, including fingerprint, for ease-of-integration.

No specific policy configuration is needed to utilize machine activation proofs — simply create a proof for a machine resource, regardless of license configuration.

View Documentation

License validation caching

Sometimes the simplest solution is what's called for, and for us, that would be utilizing response signatures to store (or cache) license validation data along with a cryptographic signature for verifying the cached data's authenticity. We usually call this license validation caching. Much like signed or encrypted keys, caching request data along with a signature is tamper-proof.

All successful API responses will include a signature header.

Diagram of API response signatures

For example, you may want to cache a successful license key validation response so that the user is able to go offline for a fixed duration. When the device is offline, you can query the cached data, cryptographically verify its authenticity (i.e. that it hasn't been tampered with), and then check the cached validation response as you would normally.

After a certain amount of time has passed (also called a time-to-live or TTL), you could expire the cache and revalidate the license using the API, repeating the process.

Using license validation caching has the benefit of being able to distribute shorter, plain-text license keys to customers, instead of cryptographic keys, which typically have a much longer license key format. Here's an example of the plain-text key format:


To create a plain-text policy, leave the scheme attribute blank.

View Documentation

Common embedded datasets

Common values we see embedded inside of cryptographic keys:

  • An expiration date (keep in mind that embedded data is immutable so expiration dates may not be the best choice for a renewable key)
  • The duration a license is allowed to be offline (e.g. 1 year of offline use before an online reactivation is required)
  • A fixed "grace period" for the license (e.g. the license is allowed to be used for 5 days after the expiration date)
  • The maximum application version to which the licensee is entitled
  • Known hardware or appliance identifiers (e.g. for node-locking licenses up-front)
  • Customer or licensee information (e.g. email address)
  • Other entitlement information

Code examples

Here are a few code examples our team has put together for implementing cryptographic licensing schemes in offline and air-gapped environments:

Here are some examples of utilizing response signatures to enable online-first, offline-capable, licensing models:

Perpetual LicenseTimed LicenseFloating LicenseNode‑locked LicenseFeature License
Expiration DateNoYesOptionalOptionalOptional
Activation LimitsOptionalOptional> 01Optional
Feature LimitsOptionalOptionalOptionalOptionalYes
Offline SupportYesYesYesYesYes
Learn MoreLearn MoreLearn MoreLearn MoreLearn More