> ## Documentation Index > Fetch the complete documentation index at: https://docs.acusight.io/llms.txt > Use this file to discover all available pages before exploring further. # Device keys & provisioning tokens > The two credentials in a device's life — the setup token that enrolls it and the device key it authenticates with — and how to rotate or revoke them. Every device in your fleet holds exactly two kinds of credential over its life, and neither is a user login: 1. A **provisioning token** (`apt_…`) gets a device *onto* the platform. It's what the setup command carries. 2. A **device key** (`adk_…`) is the device's permanent identity. The agent presents it on every request after enrollment. Keeping these separate is deliberate: a leaked setup command can't impersonate an enrolled device, and a compromised device key can't enroll new devices — or act as any user. ## Provisioning tokens When you click **Add Device**, the dashboard generates a setup command backed by a provisioning token. Those setup commands are **single-use and expire after 24 hours** — if one goes stale, generate a fresh one rather than hunting down the old command. For automation — enrolling many devices from your own tooling — the API also lets you create named provisioning tokens with a longer lifetime: * **Named and tracked** — each token has a name, a use count, and a last-used timestamp, so you can see what's enrolling devices. * **Expiring** — tokens expire (30 days by default) and can be created as **single-use**, which revokes them automatically after the first successful enrollment. * **Revocable** — revoke a token at any time to stop it enrolling anything new. Devices already enrolled with it are unaffected; they hold their own device keys. See `POST /api/provisioning-tokens` in the [API reference](/api-reference/api-introduction). ## Device keys Enrollment ends with the platform issuing the device its key: * **Shown once.** The raw key is returned to the device at provisioning and never again — the platform stores only a hash (SHA-256), so keys can't be read back out of the database. * **Device-scoped.** The agent sends the key as an `X-Device-Key` header, and it only works on device endpoints — check-in, uploads, model downloads. It is not a general-purpose API key. * **Org-scoped.** Like everything else, a device key is bound to your organization. ## Rotating a key There's no separate rotation ceremony — **re-running the setup command on a device rotates its key**. Re-provisioning deletes the device's old keys and issues a fresh one, so a device you suspect is compromised can be re-keyed with one command (generate a new setup command first; the old one will have expired). ## Revoking access * **Revoke a provisioning token** to stop new enrollments through it. * **Delete the device** to cut off an enrolled device: its keys are removed (so its next request fails), and its management endpoint is cleaned up with it. * **Removing a user** ([Orgs, users & multi-tenancy](/guides/administer/orgs-multitenancy)) never touches device keys — people and devices are revoked independently. ## Clone protection At enrollment the platform records a hardware fingerprint for the device. If something later tries to provision with the same device identity but different hardware — a copied disk image, a duplicated config — the platform rejects it as a suspected clone rather than silently re-keying. The same applies across organizations: hardware already enrolled in another org can't be re-enrolled into yours. ## Next steps The enrollment flow these credentials power. The wider security model — identities, isolation, and transport.