What should you verify before moving an encrypted workspace to a new device?

Separate identity, credential availability and decryption

A successful login identifies the application account. Seeing a passkey in a credential provider indicates that a credential may be available. Opening the existing encrypted research demonstrates something different: that this environment obtained the required decryption material and successfully used it for that workspace.

Thesis Lab keeps account authentication separate from vault unlock. Google sign-in or resetting an account password does not recreate a lost research key. The current passkey design depends on WebAuthn PRF support in both the browser and credential provider, confirmed through a real extension result and local decryption.

Keep the working environment available

Before changing devices, identify a method that currently opens the vault. Do not erase the old browser profile, remove the working credential or discard an existing recovery key merely because the new device can sign in. If you use an optional recovery method, keep it private and separate from messages, screenshots and research prompts.

For an existing recovery-key vault, the current beta may require the original key once when connecting its first passkey. A remembered non-exportable device key is not an exportable backup. Support cannot reconstruct missing decryption material. These are reasons to verify continuity while a working path still exists, rather than after it has been destroyed.

Verify with a non-sensitive continuity record

For a hypothetical continuity check, use an intentionally non-sensitive saved record whose wording you can recognize. On the new environment, follow the normal sign-in and unlock flow, then check that the existing record opens as expected. Re-lock and repeat the ordinary unlock once before treating the new method as established.

This is a proposed user checklist, not a report that a device migration was tested for this article. Do not create or replace keys through an improvised script. If a prompt is unsupported, canceled or unclear, retain the original method and use the documented supported flow rather than repeatedly modifying the vault setup.

Use a simple decision flow: if account sign-in fails, resolve the normal authentication problem; if sign-in succeeds but vault unlock fails, keep the old unlock method and investigate compatibility; if unlock succeeds but the expected record is absent or differs, stop and investigate continuity before replacing anything. Only a successful repeat unlock of the expected record supports the narrow conclusion that this new environment opened that record.

Check the application host, not just the brand

WebAuthn credentials are scoped to a relying-party identifier, and the standard requires origin validation. In Thesis Lab, the current beta login and vault remain on the existing application hostname. Reading this public content hub does not migrate the vault, authorize a new host or create a new unlock credential.

A future hostname transition requires a deliberate continuity design while users can still unlock. A synchronized passkey also remains subject to its credential provider’s security and recovery behavior. A visible credential or the same logo on two hosts is not sufficient evidence that both can open the same encrypted workspace.

Method, sources, and limits

The checklist was checked against the released beta privacy and setup documentation and the WebAuthn standard on 26 October 2026. It offers continuity checks, not a guarantee against device loss, compromised browser code or account interference. No credential, recovery method, account or production vault was created or changed for this guide.