A factory-floor terminal, a secure workstation with no internet, a laptop that's offline more often than not: apps like these can't call a license server on every launch. The answer is a signed offline token that your app verifies entirely on its own. Here's how that looks in C#, using the real verification method from PermitCore's .NET SDK.

The token format

An offline token is a plain string with three dot-separated parts:

pc_offline_v1.<base64url(payload_json)>.<base64url(signature)>

The prefix identifies the format, so anything malformed is rejected immediately. The payload is a small JSON object (license ID, device ID, expiry, and a key ID kid naming the signing key), and the signature is ECDSA P-256 with SHA-256 over the raw bytes of the base64url-encoded payload. The issuer holds the private signing key; your application only ever needs the trusted public key.

The verification code

This is a static method with zero dependencies, so it's easy to audit, or even copy into your own project:

public static OfflineTokenResult VerifyOfflineToken(string token, string publicKeyBase64)
{
    var parts = token?.Split('.') ?? [];
    if (parts.Length != 3 || parts[0] != "pc_offline_v1")
        return new OfflineTokenResult { IsValid = false, Message = "Malformed token." };

    try
    {
        var payloadBytes = Encoding.UTF8.GetBytes(parts[1]);
        var sig          = FromBase64Url(parts[2]);

        using var ecdsa = ECDsa.Create();
        ecdsa.ImportSubjectPublicKeyInfo(Convert.FromBase64String(publicKeyBase64), out _);
        if (!ecdsa.VerifyData(payloadBytes, sig, HashAlgorithmName.SHA256))
            return new OfflineTokenResult { IsValid = false, Message = "Invalid signature." };

        var json    = Encoding.UTF8.GetString(FromBase64Url(parts[1]));
        var payload = JsonSerializer.Deserialize<OfflineTokenPayload>(json);

        if (payload.ExpiresAt < DateTime.UtcNow)
            return new OfflineTokenResult { IsValid = false, Message = "Token expired.", Payload = payload };

        return new OfflineTokenResult { IsValid = true, Message = "Valid.", Payload = payload };
    }
    catch { return new OfflineTokenResult { IsValid = false, Message = "Invalid or corrupt token." }; }
}

The order matters: the signature is checked before the expiry date is trusted. Never make a security decision based on data you haven't verified yet. The method matches what the server does when it signs a token, so there's no drift between what gets issued and what gets accepted.

The full offline flow

Most apps use two higher-level calls built on that primitive:

// trustedTenantPublicKey comes from your application configuration.
using var client = new PermitCoreClient(new PermitCoreOptions {
    BaseUrl = apiUrl, TrustedPublicKeys = new[] { trustedTenantPublicKey },
    CacheDirectory = appCacheDirectory, DeviceId = deviceId
});

// First run: verify and retain the signed token.
var result = client.ActivateOffline(token, deviceId, productId);

// Every later launch, with no network call at all
var cached = client.ValidateOffline(deviceId, productId);
if (!cached.IsValid) { /* show activation screen */ }

ActivateOffline also checks that the token's device ID matches the machine calling it, so a correctly signed token issued for one device is rejected when copied onto another. ValidateOffline reads the original signed token and re-verifies its signature, expiry, device and (optionally) product against your configured trust keys.

What the signature gives you

Because the contents are signed, nobody can edit the cached JSON on disk to push out the expiry date or swap the device ID: any change breaks the signature. How long a token stays valid between online checks is configured per license with Offline Grace Days, and for store subscriptions offline access is also bounded by the paid-through date plus a configurable payment grace (14 days by default). A successful online check refreshes the signed cache after renewal.

The full guide, including the related video tutorial, is on the PermitCore blog, and the offline setup docs walk through configuring trusted keys.

How do you handle licensing for apps that spend most of their life offline? 🙂

A customer gets a new laptop. Their node-locked license is bound to the old one. Without a self-service way to move it, this becomes a support ticket every single time — and it happens constantly, since hardware turnover is routine. Here's the real mechanism that avoids that.

The actual flow: deactivate, then reactivate

A license's activation limit isn't a one-time allocation — it's a live count of currently-active devices. Freeing a seat is just removing one of those device records. PermitCore's Customer Portal exposes exactly this as a self-service action:

POST /portal/{tenantSlug}/deactivate
{ "licenseKey": "PERMIT-XXXX-XXXX-XXXX-XXXX", "activationId": "..." }

This removes the specific device's activation record and decrements the license's active-device count by one — freeing exactly one seat. The customer then runs your app on their new machine and calls activate() as normal; since a seat is now free, it succeeds and consumes it. No admin involvement, no support ticket, no manual seat-count edit.

Why this needs real authentication, not just a click

Removing someone else's active device is a real action — done maliciously, it could kick a legitimate user off their own machine. Depending on how strict a tenant wants their portal, this can require nothing beyond possessing the key itself (fine for most consumer software), a one-time email code sent before the deactivation is allowed, or a full customer account login. All three tiers use the same underlying deactivate mechanism — they differ only in what has to happen before it's allowed to run.

What if the old machine is gone and can't be reached?

This is the case a purely device-initiated "sign out" button can't handle — a stolen or dead laptop obviously can't call an API to deactivate itself. That's exactly why deactivation is a server-side action triggered by the customer (via the portal, using the license key or their account — not the old device), not something the old device has to cooperate with.

What this looks like without self-service

This flow moves the same customer's activation between devices while the service is available. Moving a license to a different buyer is a separate ownership process. Resale or assignment needs a separately reviewed policy and account process; see our ownership and end-of-life guide.

The alternative — every transfer needs a support email and a manual admin seat reset — doesn't scale past a handful of customers, and it's the single most common support request a node-locked product with any real customer base will see. Building the self-service path once removes an entire category of recurring support load.

A MAC address looks like an obvious choice for a device fingerprint — every network interface has one, it's easy to read, and it feels unique. It's also a genuinely poor foundation for node-locked licensing, for reasons that have nothing to do with theory and everything to do with what real machines actually do.

The four real problems

It's trivially spoofable. Changing a MAC address is a single command on every major OS — ip link set on Linux, a registry edit or free utility on Windows, ifconfig on macOS. A license lock a customer can defeat in ten seconds isn't protecting much.

A machine usually has more than one. Wi-Fi adapter, Ethernet port, a virtual adapter from a VPN client, a Bluetooth interface — which one is "the" device identifier? Pick the wrong one (or the one that happens to be active at activation time) and the same physical machine can present a different fingerprint on a different day, depending on which network it's connected to.

Modern OSes randomize it by default. Both iOS/macOS and Android now randomize the MAC address per network by default for privacy — a deliberate, permanent feature, not a bug. A hardware ID that changes every time the device joins a new Wi-Fi network is not a hardware ID.

VMs and containers don't have stable physical hardware to report. A virtual NIC's MAC is assigned by the hypervisor and is typically the first thing that changes when a VM is cloned, migrated, or recreated — exactly the deployment pattern where you most need a fingerprint that survives infrastructure changes, and exactly where a MAC-based one fails hardest.

What PermitCore's SDKs actually use instead

Not a single identifier — a combination, hashed together so no individual component is exposed or trivially replayable. This is the real method from the .NET SDK, unmodified:

public static string GetHardwareId()
{
    var components = new List<string>
    {
        Environment.MachineName,
        Environment.OSVersion.Platform.ToString(),
        Environment.ProcessorCount.ToString(),
        GetOrCreateSeedFile(),   // a GUID written once, persisted locally
    };
    // + the Windows registry MachineGuid, on Windows

    var combined = string.Join("|", components.Where(c => !string.IsNullOrEmpty(c)));
    var hash = SHA256.HashData(Encoding.UTF8.GetBytes(combined));
    return Convert.ToHexString(hash).ToLowerInvariant();
}

Notice what's not in that list: no MAC address, no network-dependent value at all. Machine name and processor count are cheap, stable signals; the seed file (a GUID generated once and written to a local, per-user application-data path) is what actually anchors the fingerprint to this specific install rather than this specific network state — even if the machine changes networks, gets a new NIC, or runs entirely offline, the seed file and the other components stay the same. On Windows, the registry's MachineGuid (set once at OS install, not tied to any network interface) adds another stable signal. The whole combination is SHA-256 hashed, so the server only ever sees an opaque fingerprint, never the raw machine details.

No hardware ID is unbeatable

To be honest about the limits: a sufficiently motivated user with full control of their own machine can still spoof a seed file or fake environment values — no client-side fingerprint is unbeatable against someone willing to reverse-engineer your app. The realistic goal isn't "impossible to defeat," it's "significantly more effort than switching a MAC address in Settings," which shifts the population of people who'll actually bother from "everyone" to "a small minority" — combined with server-side activation-limit enforcement and abuse detection, which is where the real protection layer actually lives. See How to Prevent License Key Sharing for that side of the picture.

What do you use as a device fingerprint in your own desktop app, and has it ever bitten you after a hardware or OS change? 🙂

Layer 1: a brief network blip

The most common case by far is a flaky connection, not a real outage — a customer's Wi-Fi drops for ten seconds while your app happens to call validate(). This shouldn't be a special case an app has to handle explicitly. With offline grace configured on the license and a usable signed result already cached, PermitCore's SDKs can use that cache on a connection failure until its signed deadline:

catch (Exception ex) when (ex is HttpRequestException or TaskCanceledException)
{
    // Server unreachable — fall back to the last cached result
    return TryLoadFromCache(licenseKey) ?? new LicenseResult
    {
        IsValid   = false,
        Message   = "Cannot reach license server.",
        IsOffline = true
    };
}

This is the real code from PermitCore's .NET SDK — a bad network moment does not automatically mean a locked-out customer.

Layer 2: extended, expected disconnection

Some apps need to run offline by design — an air-gapped terminal, a laptop that's disconnected more often than not. That's a different problem from a transient blip and needs a different mechanism: a deliberately signed offline token (ECDSA P-256), issued once while online, cached, and verified entirely on-device with no server call for as long as the token's grace period allows. See our offline grace mode and offline validation posts for exactly how this works and what it honestly can't protect against (a hostile local clock, mainly).

Layer 3: what if the vendor itself goes away?

This is the question that actually matters for a purchasing decision, and it's the one vendors talk about least. If a licensing vendor shuts down entirely, what happens to software you've already shipped to customers? Already-issued offline tokens can be verified with a trusted public key shipped in the app until their signed expiry. Token generation currently accepts 1–365 days; a perpetual license does not make its token permanent. Enterprise signing-key export and self-hosting support a separately operated continuity solution, with its own protected keys, backups and tested deployment. Plan for reinstalls and replacement devices too. See our ownership and shutdown planning guide for a final-build and end-of-life checklist.

What to actually check before you commit to a vendor

Ask specifically: does a routine network blip fail closed or gracefully degrade? Is there a real mechanism for extended offline use, not just a marketing claim? And critically — is there any continuity plan if the vendor itself stops operating, or does every customer's license silently stop working the day the company does? The honest answer for most licensing services is "we haven't thought that far," which is worth knowing before you build a business on top of one.

Originally published at https://permitcore.dev/blog/what-happens-if-a-license-server-goes-down