Pairing

Identity

Use the identity and enrollment flow documented for your installed client. Account authentication, device enrollment, and tunnel keys have different roles. Check how your release creates and stores key material; do not assume every platform uses the same secure-storage mechanism. Never paste private keys into the website or a support request.

First-device pairing

Confirm that the client supports your platform and the connection you want to use. Follow its account, permission, and enrollment steps, and review the data it sends to coordination services. Registration or a successful heartbeat alone does not establish a peer tunnel or authorize an inference workload.

Adding a trusted device

Use your release's supported invitation or pairing flow. Confirm the expected device and any identity or fingerprint shown before accepting it. Do not share pairing secrets or accept an unfamiliar peer. Client releases can differ in how they enroll devices and establish trust.

Check the connection after enrollment. A supported tunnel backend, required operating system permissions, reachable peer, and successful handshake are separate requirements. A Running adapter with Connecting status has not yet established the peer handshake. An UnsupportedPlatform result requires a supported client/backend, not repeated sign-in attempts. Verify the selected workload route before sending data.

Recovery

If a device is lost, follow your client's documented revocation and recovery process and review the remaining enrolled devices. Key backup, restore, and replacement-device support depend on the release and deployment. Do not assume that signing into a new device restores an old tunnel identity. Use the Support Center if you cannot confirm the supported recovery path; keep credentials out of the report.