Activate using another computer

A disconnected app can activate by carrying a request and a response through another computer. The customer account and license are the same as in browser-based activation; only the transport changes.

The activation response is protected for the approved device. Prepare its runtime and device access before testing the file exchange.

Prepare the runtime

The SDK selects the OS runtime. Application code should not choose provider names or construct public-key fields.

Platform	Requirements	Verification scope
Linux	Python 3, tpm2-tools, TPM 2.0 resource manager and device access	File exchange and verification have been exercised on a physical Linux device and a simulator.
Windows	Windows 10/11, Windows PowerShell 5.1, ready TPM 2.0 and Microsoft Platform Crypto Provider	Platform-key creation/reuse, signing, unwrapping and wrong-target rejection passed on the Windows runner.
macOS	macOS 11+, Secure Enclave-capable hardware and private persistent storage for device-wrapped key handles	Protected key operations passed on Apple Silicon. Both arm64/x86_64 binaries build; Intel hardware execution is separate.

Mac SDK 0.3.1 packages include the universal native helper, so normal use does not require Swift or Xcode. The key representations saved in state are device-wrapped handles, not plaintext private keys. They cannot be treated as ordinary portable keys; preserve them on the original device.

For external app distribution, sign/notarize the helper as part of the supplier’s application and verify that package.

Software RSA/ECDH tests do not prove that an OS protected store works on a real device. Without available protection, use connected activation and its signed network-grace policy. A USB-token provider is not supplied.

Enroll device trust

Protected issuance requires an eligible plan and explicitly enrolled device trust. An operator must obtain the public key using the official runtime on the actual device, verify that the protected store was used, and compare the key over a trusted channel. Enroll it in the administrator security screen under Device protection key trust.

A customer-supplied provider label is not hardware attestation. Manufacturer certificate validation is not automated. The supplier prepares the supported environment and trust enrollment; end users do not select device technologies.

1. Create a request file in the original app

Install the language sample and run activation-request request.signox. The sample calls createRequest() or the corresponding method and saves its public JSON.

The file identifies the product and device to approve; it does not grant access. Keep result retrieval secrets and installation credentials in the private state directory.

Success means request.signox exists. Repeated export reuses the request. After its seven-day lifetime, run activation-renew-request request.signox to create a renewed request.

2. Import it in the customer portal

On a connected computer, open the customer portal /activate page and select the file or paste the request code. The portal resolves the product from server data and displays the app name and logo.

Check the app identity and sign in as the customer. Vendor dashboard credentials belong to a different realm. If the customer has no owned license, register the purchased key first.

3. Select a license and receive the response

Check the license and device name, choose activation, and approve the confirmation dialog. Issuance reserves this device’s registration.

• A different existing device leads to a reasoned transfer request. The vendor reviews that exact destination.
• If device trust is required, the supplier must verify and enroll the actual key before approval.
• Expired, suspended or revoked rights are not connection failures. Resolve the license state first.

Save activation.signox. Issuance is not proof that the original device applied it.

4. Apply the response on the original device

Carry activation.signox back and run activation-apply activation.signox. The SDK verifies the signature, product, request and device, opens the response with the protected key, then checks expiry and features.

Only one request/response round trip is needed. Application developers do not exchange the legacy intermediate challenge/proof files.

Success returns VALID or IN_GRACE_PERIOD with valid=true. Check the required feature before the actual operation. If ACTIVATION_RESPONSE_INVALID occurs, confirm the file belongs to this product, request and device; do not edit the response.

Understand application confirmation and transfer

A connected app can confirm application to the server. A permanently disconnected app cannot report it automatically, so the portal may continue to show issuance.

A retained protected key can recover its registration. If the Windows key store or Mac device-wrapped handles are erased, matching device names do not prove key recovery. Create a new request and request transfer review.

Remote suspension or revocation cannot reach a permanently disconnected device immediately. File deletion and format do not prove old backups stopped working. Vendor exception approval records this uncertainty; it does not prove zero overlapping physical use.

Device identity and recovery · Verify real feature permission