Recovery and device loss

Viewport separates pairing from decrypt enrollment.

Pairing lets a daemon connect to the relay for an organization. Decrypt enrollment gives that daemon the private user epoch material needed to open encrypted context vaults and trusted-edge encrypted plans.

Normal setup

For a professional team, the expected setup is:

1. Pair at least one daemon.
2. Publish a user epoch from that daemon.
3. Enroll any second device, such as another laptop or a VPS.
4. Optionally create a recovery-key backup.

After that, both daemons are decrypt-ready for that user in that workspace. The platform stores public epoch data, encrypted grants, and signed receipts. It does not store the private epoch material.

If you lose one device

If you still have another enrolled trusted edge, recovery is simple:

1. Revoke the lost device in Settings -> Machines.
2. The platform queues a user epoch rotation.
3. An enrolled trusted edge processes the rotation and publishes the next public epoch.
4. Future context and trusted-edge plan grants target the new active epoch.

The lost device may still have whatever it already decrypted before revocation. That is soft revocation. It should not receive future grants after the rotation.

If you add a VPS

A VPS is treated like any other trusted edge, but your browser should not call the VPS daemon directly.

The supported path is:

1. The VPS daemon keeps an outbound relay connection open.
2. You enroll the VPS with vpd context device-enroll-request, vpd context device-enroll-approve, and vpd context device-enroll-accept.
3. When hosted web needs plaintext, you unlock that trusted edge with vpd unlock <id>.
4. The browser sends a scoped command over the encrypted relay channel to the daemon that activated the unlock.

The unlock is short-lived and bound to the runtime target that activated it. A different paired daemon cannot reuse that capability.

If you lose every enrolled device

If every enrolled trusted edge is gone, you need a recovery key backup.

When enabled, vpd context recovery-backup encrypts the active user epoch locally with a recovery key and uploads only the encrypted backup envelope. The platform stores ciphertext and KDF metadata. It does not receive the recovery key or private epoch material.

If you skipped recovery backup and lost every enrolled device, Viewport cannot decrypt the old epoch for you. Support cannot bypass that without breaking the trust model.

If the recovery key is stolen

Treat a stolen recovery key like a stolen enrolled device.

From a still-trusted device:

1. Revoke any suspicious devices.
2. Run vpd context recovery-backup to rotate the backup.
3. Process the queued rotations with vpd context sync-all.

Recovery backup create and fetch endpoints are rate-limited separately from normal runtime APIs. Recovery backup creation and access are written to the workspace audit log with IDs and runtime-target metadata only. Audit rows do not include ciphertext payloads, KDF params, recovery keys, or private epoch material.

What this does not protect against

This model does not erase content that a revoked device already decrypted. It blocks future grants and future content after rotation.

It also does not protect against malware running as the same OS user as the daemon. The daemon has to hold private epoch material locally to decrypt on your behalf. Use OS disk encryption, short-lived machines, and device revocation for operational risk.

Commands

vpd context device-enroll-request
vpd context device-enroll-approve --enrollment <id>
vpd context device-enroll-accept --enrollment <id>
vpd context device-enrollments

vpd context recovery-backup
vpd context recovery-restore --recovery-key <key>

vpd unlock <unlock-session-id>
vpd context sync-all

Related

• Team Context encryption
• Sharing and revocation
• Trust and privacy