Flexxible Assist device identity

When you start a Flexxible Assist session, the viewer may show this warning in the bottom-right corner:

The device identity has changed This device’s identity key is different from the one previously registered. This is normal after a reinstallation or reimage. If you did not expect it, confirm the device before continuing.

The warning does not block anything. The session is established normally, end-to-end encryption remains active, and the operator can close it as soon as they have read it. In most cases there is a simple explanation, such as a reinstallation or a non-persistent virtual desktop. This page explains what Flexxible Assist checks, why this warning exists, and how to interpret it.

​

What Flexxible Assist checks

Each device with Flexxible Assist generates its own identity key the first time the agent starts. The key is created on the device itself, stored there, and never leaves it. Flexxible neither issues it nor knows it.

• On Windows it is stored in C:\ProgramData\Flexxible\Assist, protected with machine-level DPAPI.
• On macOS it is stored in /Library/Application Support/com.flexxible.assist.
• On Linux it is stored in /var/lib/flexxible-assist.

The first time a workspace connects to the service, Flexxible Assist registers its identity key. From then on, every connection from the same workspace must prove that it still holds that key. When starting a session, the viewer performs two checks:

1. It verifies that the device has signed the session key exchange with its identity key. If the signature is not valid, the viewer rejects the session with the message The device identity could not be verified.
2. It compares the key with the one it had registered. If it is different, it shows this warning and lets the session continue.

​

When it appears

The warning appears when the device’s identity key has changed since it was last registered. Once the new key is registered, the warning is repeated in every session with that device for the 24 hours following the change. After that time it stops appearing until the key changes again. A device’s first connection does not show any warning. At that point there is no previous key to compare against.

​

Common reasons the warning may appear

The key lives on the device’s disk. Any operation that replaces or erases that disk generates a new key on the next startup, and with it the warning. These are the most frequent cases, and none of them indicates a problem:

• Reinstallation of Flexxible Assist. Uninstalling removes the directory where the key is stored. When you install again, the agent generates another one.
• Device reimage. Redeploying the corporate image, reinstalling the operating system, or resetting the device to factory settings.
• Restore from a backup or snapshot. If the backup predates the moment the current key was registered, the device reverts to the old key or to none.
• Non-persistent virtual desktops. Each startup begins from the base image, so the agent generates a new key every time. In these fleets the warning is normal and will appear in almost every session.
• Hardware replacement. Changing the disk or the motherboard. On Windows, the key is also bound to the machine through DPAPI: if the machine changes, the file can no longer be read and the agent creates a new key.

​

Reasons worth reviewing

If the warning appears and does not match any of the situations above, it is worth spending a minute on it:

• Two devices with the same workspace identifier. This happens, for example, with a cloned machine that was not generalized. Each one has its own identity key, and every time a different one connects the warning reappears. While one of the two is connected, the service rejects the connection from the other, so you will also notice the device going online and offline.
• The warning repeats for days on a device that nobody has reinstalled. This usually indicates that the agent cannot save its key to disk, for example due to a permissions problem in the directory, and therefore generates a new one on every startup.
• Nobody can explain the change. An identity change that does not match the device’s history may be an impersonation attempt. It is unlikely, but it is exactly the case this warning exists for.

​

What to do when you see the warning

1. Check whether there is a known cause: reinstallation, reimage, restore, or non-persistent virtual desktop. If there is, close the warning and continue normally.
2. If there is not, confirm that the device is the expected one. Ask the user in front of it or check the device name, last boot, and inventory in Flexxible Portal.
3. If in doubt, end the session and open a ticket with Flexxible support, indicating the workspace and the identity fingerprint shown in the warning.

​

The identity fingerprint

Below the text, the warning shows the identity fingerprint: the first characters of the SHA-256 digest of the device’s public key. The fingerprint identifies the key, not the device, and changes every time the key changes. It is not confidential information. Its purpose is to serve as a reference. If you open a ticket, include the fingerprint exactly as it appears in the warning: Flexxible support can check it against the service log and confirm when the change occurred and from which key.

​

Frequently asked questions

Can the warning be disabled? No. It is part of Flexxible Assist’s identity verification and has no configuration option. In return, it does not block the session and closes with one click. Is the session less secure when it appears? No. End-to-end encryption is negotiated the same way, and the viewer has verified that the device signs with the key it presents. What the warning indicates is that this key is not the same as last time. Why does it not appear on the first connection? Because there is no previous key to compare against. A “first connection” warning adds nothing for the operator and would get everyone used to closing warnings without reading them. Why does it appear in every session and not only in the first one after the change? Because the operator who opens the first session after a reimage is not always the same one who opens the second. For 24 hours, any operator who connects sees the warning; after that it stops appearing. What happens if two devices with the same identity connect at the same time? The service accepts the first one and rejects the second while the first remains connected. Only when the first disconnects can the other one get in, and at that point its key replaces the registered one.