Limitations

Encryption on your devices removes a lot of risk, but not all of it. These are the limits Crunu's own threat model states, and what you can do about each. A shorter overview is on the limitations page.

A tampered web app

This is the main remaining risk, as for any vault that runs in a browser. A server under someone else's control could serve a modified web app, and that page would see your password and Secret Key when you sign in.

What helps: the local file crunu.html, whose code comes from your disk rather than the server; the signed release manifest, which the local file checks the site against; the Content Security Policy and integrity checksums on every page. Admins are advised to work only from the local file.

What was seen can't be taken back

Revoking access, removing a member or rotating keys protects new versions only. Values someone already saw, copied or received on a device stay with them. Programs that are already running keep their variables until they restart.

What helps: reissue those values at their providers. The member removal wizard lists them as a reissue checklist, and the exposure report shows what each person or machine received.

The server sees metadata

Names of organizations, projects, environments and machines, email addresses, the audit log, and the sizes and times of versions are visible to the server. See What the server sees.

What helps: don't put secrets into names.

The server can refuse service

A server can stop answering or lose records. Nothing in the design prevents that.

What helps: backups, offline copies, and moving the server elsewhere with one archive. Machines keep working with what they have until their lease ends, up to 24 hours by default.

A new device can be shown an old organization state

A compromised server, working together with a removed member, could show a new device with no stored state an older organization key pin and an older revocation list, hiding later key changes. That device would then trust signatures of the removed member. The server can't forge anything new on its own, and replacing your account keys or having stored state on the device narrows the window. Without an outside source of freshness, such as a transparency log, this can't be closed completely.

What helps: compare the key generation, revocation list number and pin date in Organization settings with another of your devices.

Malware on a device with decrypted keys

Crunu doesn't protect against malicious code on a device where keys are decrypted: a keylogger, a browser extension, or root on a machine.

What helps: keep devices clean, lock the vault when you step away, and grant machines the minimum.

A machine sees everything granted to it

A machine with the agent is a legitimate recipient. Root on that machine sees everything granted to it.

What helps: grant each machine only the environments and files it needs, keep leases short, and watch the alerts about new addresses. Revocation reaches an online machine within minutes. See Machines and leases.

Nobody can reset your password

The server knows neither half of your account key, so it can't reset a password. Without the password, the Secret Key and a recovery code, nobody can open the account. If every owner and admin of an organization loses access, nobody is left to manage it.

What helps: at least two owners per organization, a recovery code for everyone, Emergency Kits stored away from devices. See Recovery code.

A recovery code skips the second factor

A recovery code opens the account after a waiting period without asking for a second factor. The waiting period is enforced by the server, so a compromised server could release the keys at once.

What helps: store the recovery code separately from your devices and from your Emergency Kit. Delete it and create a new one if anyone may have seen it.

Network rules are a server rule, not encryption

A compromised server won't follow network rules. Every device behind the same NAT shares one address, so everyone behind it counts as inside. Once contents were served, the rule can't take them back.

What helps: treat network rules as one more layer, next to small grants and CI bindings. See Network rules.

Hidden values are a client policy

Values are hidden in the interface to prevent accidental exposure, for example on a shared screen. Anyone who can decrypt a value can still show and copy it.

Email addresses aren't verified without email

If a self-hosted server has no email configured, addresses aren't confirmed when someone creates an account from an invitation. Admins then rely on comparing key fingerprints when confirming members.

SERVER_KEY matters for self-hosted servers

Losing SERVER_KEY signs everyone out and breaks share links, though environment data isn't lost. A leaked SERVER_KEY together with a database copy weakens authenticator-app sign-in. See Rotate the server key.

Restoring a backup rolls everything back

A restore loses every change made after the backup, and agents and browsers have to reset their memory of the server afterwards.

The server address is permanent

Sign-in signatures, share links, passkeys and agents are tied to the server address, so choose it once.

Platform constraints

On the free Cloudflare Workers plan, heavy requests can hit the CPU limit, and a team needs Workers Paid. On Cloud Run and App Runner, some alerts arrive late because cleanup runs only with traffic.

Things Crunu doesn't do by design

• Dynamic secrets, such as issuing temporary database passwords on the fly. That would need a key on the server, which contradicts a blind server.
• Changing values at providers. Rotation in Crunu changes encryption keys. Values at AWS, Stripe and others are reissued by hand, using the reissue checklist.