WHAT TO STORE LOCALLY IN YOUR CLIENT

OVERVIEW

This article applies primarily to distributed client applications that are installed and run in the customer environment, especially desktop applications and similar software with local state.

In such scenarios, there are two different categories of data to consider:

• license-related state that should be stored locally to support resilient licensing behavior
• secrets that must be protected appropriately

The following sections explain what should be saved locally, why it matters, and how sensitive data should be handled.

For practical implementation examples, see our official NuGet package and our GitHub examples.

LOCAL LICENSE STATE

If your application supports offline-capable licensing, it should store the result of the last successful license heartbeat locally.

Save the Last Successful Heartbeat Result

The most important piece of locally stored licensing data is the content returned by the last successful heartbeat. This information represents the most recent valid license state known to the client.

Saving this content gives your application flexibility in offline or temporarily disconnected scenarios, because the last known valid state can still be used when the SLASCONE API is temporarily unavailable.

Save the Digital Signature

In addition to the heartbeat content itself, the corresponding digital signature should also be stored locally.

This is important because locally stored license data must be protected against tampering. Before the cached data is used, the client should validate the digital signature to ensure that the content is authentic and has not been modified.

FREERIDE AND FAILED HEARTBEATS

In most real-world scenarios, software access should not be restricted immediately when a heartbeat fails. Instead, the end user should typically be informed that the application needs to reconnect, while still being allowed to continue working for a limited period of time.

This is where the freeride period becomes relevant.

Example:

• the license requires one successful heartbeat per day
• the configured freeride period is 7 days

If a heartbeat fails, the client can continue using the last successfully stored heartbeat result for up to 7 days. During that period, the user should be notified that the application needs to go online again. If a heartbeat succeeds during that time, the freeride period resets. If no successful heartbeat occurs within those 7 days, the license becomes invalid.

This means that freeride depends on previously stored valid license state. Without the locally stored heartbeat content and its signature, the client has no trustworthy state to fall back to.

SECRETS

Secrets such as a ProvisioningKey or an EncryptionKey must be handled differently from normal license state. They should not be exposed or stored carelessly.

What Not to Do

Secrets should never be hardcoded in plain text directly in source code or configuration files that are distributed to customers without any protection.

Environment Variables

Environment variables can be an acceptable option for server-based applications or centrally managed deployments where you control the runtime environment and there is only one installation to manage.

For distributed client software installed on customer premises, environment variables are usually less suitable because they still require a secure and manageable deployment model on the target system.

Online Secret Management

For centrally managed environments, online secret-management solutions such as Azure Key Vault, Google Cloud Key Management Service, or AWS Key Management Service can be a strong option.

However, whether this is practical depends on the application architecture and deployment model. For software distributed to customer environments, such solutions may not always be feasible or desirable. In those cases, secret handling must still be designed carefully so that sensitive values are not exposed unnecessarily.

SUMMARY

• Store the last successful heartbeat result locally.
• Store the corresponding digital signature and validate it before using cached data.
• Use the stored license state to support freeride scenarios after failed heartbeats.
• Protect secrets such as provisioning or encryption keys appropriately.
• Choose the secret-management approach based on your deployment model.