Incident response

Runbooks for compromised deployments or devices, leaked Recovery Kits, database exposure, tampering, failed rotation, and safe evidence handling.

The host application’s incident owner controls deployment, authentication, storage, and user communication. Ownfold cannot remotely disable an application or recover keys. Preserve evidence without collecting secrets, and state uncertainty plainly.

First response

1. Stop the suspected exposure while preserving current encrypted data and coordination metadata.
2. Identify the affected origin, deployment versions, time window, accounts, devices, key versions, and whether vaults may have been unlocked.
3. Do not ask users to upload Recovery Kits or passwords. Do not copy encrypted request bodies, browser storage, DOM snapshots, or plaintext into tickets and chat.
4. Restore a trusted deployment and authentication boundary before asking users to unlock, revoke, recover, or rotate.
5. Use typed error codes and metadata-only records to scope the incident. Document what is known, inferred, and unknown separately.

Malicious script or dependency

Assume root keys and plaintext from every vault unlocked during the affected window may be exposed. Locking after compromise cannot recall captured material. Remove the malicious code, rotate signing and deployment credentials, invalidate relevant application sessions, and then guide users through device review, root-key rotation, and Recovery Kit replacement from a trusted build. Rotation protects future writes; it cannot make previously captured plaintext secret again.

Lost or compromised device

Revoke the device from another authorized device, then rotate the root key if an attacker may have used the local device envelope. Revocation blocks future authenticated coordination but cannot erase cached ciphertext, keys, or plaintext from an offline device. If no authorized device remains, use a Recovery Kit on a trusted browser, register the replacement, revoke the old device, and rotate.

Recovery material exposure

• Kit file exposed, secret not known: treat the password as subject to offline guessing. Replace the kit and rotate if password strength or exposure duration creates material risk.
• Secret exposed, kit file not exposed: replace the secret and kit because the two may later meet.
• Kit and secret exposed: assume the root key is compromised. From a trusted device, rotate the root key, issue and verify a new Recovery Kit, and review devices.

Recovery Kit replacement without root-key rotation does not evict someone who already opened the old kit and retained the root key.

Database or backup exposure

Encrypted records and key envelopes should remain confidential without client keys, but identity, counts, timing, sizes, device metadata, and key versions are exposed. Check whether application logs, sessions, build artifacts, or client material were also compromised before deciding keys were safe. Preserve encrypted blobs exactly. Credential rotation and user notification obligations belong to the host application’s jurisdiction and policy.

Tampering or interrupted rotation

Authentication failures, unsupported versions, revision conflicts, and corrupted envelopes are not proof of an attack; storage bugs and partial rollouts can produce similar evidence. Stop destructive rewrites, retain the original bytes, restore the compatible application version if safe, and resume through Ownfold’s checkpointed rotation path. Never “repair” an authenticated field manually.

Follow Versioning and upgrades for rollback constraints and Lost access and device failure for user-facing outcomes.

Browser storage failure

For INDEXEDDB_UPGRADE_BLOCKED, ask the user to close other tabs for the same application before reloading. For INDEXEDDB_QUOTA_EXCEEDED, preserve the existing site data, free unrelated browser storage, and retry. Do not advise clearing application storage until the user has independently verified an accessible Recovery Kit and secret.

LOCAL_VAULT_STATE_CORRUPTED does not automatically delete the damaged record. Capture only the error code and application version—never export browser key state into support tooling. Restore with the Recovery Kit in a trusted browser profile, then revoke the damaged device record if it can no longer be opened.

Crypto worker failure

Treat CRYPTO_WORKER_UNAVAILABLE, CRYPTO_WORKER_TIMEOUT, CRYPTO_WORKER_POST_FAILED, and CRYPTO_WORKER_PROTOCOL_INVALID as local execution failures. Lock the affected client, preserve IndexedDB and server ciphertext, dispose the failed engine, create a fresh worker, and require the user to unlock again. Investigate CSP reports, worker-asset deployment, browser support, memory pressure, and message-cloning errors. Never fall back silently to server-side or main-thread decryption, and never log the failed message body.