Home / Blog / License delivery
License delivery

How do you activate a license when the customer's machine never touches the internet?

Air-gapped labs, locked-down corporate desktops, and field laptops still need to run your software. Here is how offline activation works without turning your licensing into a loophole.

An engineer in a windowless industrial control room holding a small USB flash drive next to a closed ruggedized laptop, fluorescent lighting, gray metal cabinets, safety vest, no visible text

Why online-only validation quietly excludes real customers

The customers who cannot let your app phone home are often the ones with the largest budgets: hospital equipment rooms, manufacturing floors, defense contractors, research labs, ships, and field crews with no reliable signal. If your app validates on launch and fails closed when the request times out, these buyers cannot even evaluate the product. The failure is silent. They do not file a bug report; they just never buy, and you never learn why.

Fully offline machines are only one end of a spectrum. There are also desktops behind strict egress proxies that block any domain not on a list, laptops used on flights, and virtual machines cloned from a golden image that share every identifier. Decide early which tier you support: never online, occasionally online, or online but restricted. Each tier needs a slightly different design, and pretending everyone is always connected is the one option that does not work.

Keep reading: Why Digital Products Need Licensing, Generating License Keys That Work, Validating Keys Without Frustrating Users. See how KeyDispense helps you digital product license key issuing and validation api.

The request and response pattern that makes offline activation work

The mechanism is simple once you see it. The app generates an activation request containing the license key and a machine identifier, encoded as a short text blob or small file. The customer carries that blob to a connected device by USB drive, email, or copy and paste, and submits it to your portal. Your server checks the key, records the activation against that identifier, and returns a signed activation file. The app verifies the signature using a public key embedded in the binary. No network is required at runtime. Related: Activation Limits and Casual Sharing

A few details make or break this flow. Use asymmetric signing so the app never holds a secret that could forge activations. Include a validity window inside the signed payload rather than relying on a separate check. Keep both blobs short enough to be retyped by hand, because some facilities forbid removable media entirely, and add a checksum so a typo produces a clear error instead of a baffling signature failure. Finally, version the format so a file issued today still validates in a build shipped years from now.

Deciding what an offline license is allowed to do

Because you cannot revoke an offline activation in real time, treat every offline license as time-boxed. A perpetual offline file with no expiry means a refund cannot be enforced and a leaked file works forever. The usual compromise is an annual activation file, or a longer validity paired with a renewal reminder inside the app. For subscription products, embed the paid-through date plus a grace window in the signed payload, and bake feature flags into the same payload rather than fetching them. Related: Why Digital Products Need Licensing

Deactivation needs a path too. Have the app produce a signed deactivation receipt that the customer submits back to free the seat, so a hardware replacement does not consume a fresh activation. Log offline activations in their own category so support can spot anomalies, such as one key with dozens of offline activations in a week. The goal is that the offline route is never easier to abuse than the online one. Related: How much device fingerprinting is reasonable for license enforcement in desktop apps?

Supporting offline customers without drowning your team

Route the exchange through a self-service portal rather than a support inbox. Give the app a menu item or a command-line flag that generates the request and imports the response, and document the whole flow with plain steps. Then test it yourself on a virtual machine with networking disabled. The first run almost always reveals that the app also tries to reach an analytics endpoint or an update check and hangs, which is a bug you want to find before a customer does.

Larger customers will want their IT team to activate hundreds of machines in one pass. Offer batch import of request files and batch export of response files, and let them download a manifest of what was activated. Keep the request and response formats documented and stable. An offline customer who upgrades two years later should be able to reuse the same procedure without contacting you, and that stability is what earns renewals from this segment. Related: Protecting Your Product Without Punishing Customers

Key takeaways
  • Offline customers rarely complain; they simply never buy, so decide up front which offline tier you support.
  • Use an asymmetrically signed activation file bound to a machine identifier, with the app holding only the public key.
  • Give every offline license a validity window because you cannot revoke it in real time.
  • Build a self-service request and response portal and test the entire flow on a VM with networking disabled.
Julien Jimenez
Written by

Julien Jimenez

Julien Jimenez is an independent software builder based in Paris. He designs, ships, and operates focused SaaS products for small businesses and independent professionals. Read the full author page.

Issue and validate license keys with one API

Digital product license key issuing and validation API. KeyDispense is built to help you put this into practice.

Get an API key

More from the KeyDispense blog

Get the KeyDispense playbook

Practical guides on license delivery, straight to your inbox as we publish them. No spam, unsubscribe any time.

By subscribing you agree to our privacy policy.