The server holds the decryption capability
Credential payloads are encrypted at rest, but the app server has the key material needed to decrypt them during an approved reveal. That means the system is protected, but not zero-knowledge.
Why No Zero-Knowledge?
This vault is designed for operational control, not pure zero-knowledge secrecy.
Forgot Password encrypts stored credential data, but it does not use a zero-knowledge design. The service can decrypt secrets during the reveal flow, which is a deliberate tradeoff in favor of team workflows, audited reveals, and recoverable operations.
Your login password is a verifier, not the vault key
A user re-enters their account password to pass a step-up check, but that password is not the sole secret required to unlock stored credentials. The product is not built around client-side-only decryption.
Team sharing is easier in this model
Agencies need multiple authorized teammates to access the same client records. A server-managed encryption model makes those shared workflows much simpler than a strict zero-knowledge design.
In a true zero-knowledge vault, the service operator cannot decrypt customer secrets because decryption happens client-side with keys derived from a secret the server never possesses in usable form.
That model is powerful, but it also creates harder tradeoffs around team sharing, account recovery, admin workflows, and device migration.
Forgot Password is built to support deliberate reveals, organization permissions, audit trails, and smoother handoffs between authorized teammates. To do that, the service can decrypt stored payloads on the server after access checks and step-up verification succeed.
This is a real security boundary, but it is not the same promise as saying the operator could never decrypt the data under any circumstance.
The database alone is not enough to read stored secrets, which is important. But the running application plus its server-side key material can decrypt those secrets during the reveal path.
So the trust model is: protect the infrastructure, protect the server key, protect user accounts, and log sensitive actions carefully.
In a strict zero-knowledge system, if a user forgets the only master password and has no recovery key, no trusted device, and no pre-arranged recovery path, the encrypted secrets are usually gone for good.
Recovery only exists when the product intentionally adds some other path such as recovery keys, delegated access, device-based recovery, or escrow. Those features improve recovery, but they move the system away from pure zero-knowledge.
Forgot Password is choosing a more operational model: encrypted storage, controlled reveals, audited activity, and shared workspace access for teams that manage client accounts together.
The goal is to reduce dangerous day-to-day password handling without pretending the product makes a zero-knowledge promise it does not actually keep.
Plain-language summary
Encrypted does not automatically mean zero-knowledge, and recovery always comes with tradeoffs.
If you want the broader security model, read the main Why page. If you want the direct answer, this product does not claim zero-knowledge because the server participates in decryption during approved reveal flows.