# 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](/en/samples/node/) 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](/en/guides/hwid/) · [Verify real feature permission](/en/guides/integration-checks/)