No password reset, by design

The claim: we cannot reset your master password

NT² Vault does not have a hidden procedure for resetting your master password. We do not keep a second key for support, a recoverable copy of your password, or a server-side secret that can be exchanged for access to your vault.

That is not a limitation we hope to remove later. It follows directly from the architecture.

Your master password is used on your device to derive cryptographic key material. The sensitive contents of the vault are encrypted locally. The password is not sent to NT², and the server does not receive the local material needed to reproduce the same unlock result. If the cloud never had those ingredients, a support agent cannot reconstruct them after an email, an identity check, or an escalation to an administrator.

This is what “cannot” should mean in a zero-knowledge product. It should not mean “our policy says employees must not.” It should mean the system was not given the capability in the first place.

The distinction matters. A company can revise a policy, misconfigure a permission, lose an administrator credential, or be compelled to use a capability it possesses. It cannot disclose a master password it never received or press a decrypt button that was never built.

The usual SaaS recovery path is also an attack path

In an ordinary online service, password reset is a familiar convenience. You click “Forgot password?”, receive an email or text message, prove control of an account, and choose a new password. The service updates its authentication database and lets you back in.

That model is reasonable when the password only controls admission to a server account and the server already holds the underlying data in readable form. The provider is the authority. It can decide that a successful recovery ceremony is equivalent to the old credential.

An encrypted vault has a different problem. Changing an account login is not the same as recovering the key that opens existing ciphertext. If a provider can turn an email challenge into a new key that decrypts old vault contents, then some provider-controlled path bridges account recovery and data decryption.

That bridge is useful when the legitimate owner is locked out. It is equally interesting to everyone trying to impersonate the owner.

Help desks are designed to resolve ambiguity. Attackers manufacture ambiguity. They arrive with a plausible story: a lost phone, urgent travel, a changed surname, an inaccessible email address, an executive who cannot wait. They gather details from breaches and social media, exploit rushed processes, and try several agents until one accepts the story. The reset workflow becomes a social-engineering API operated by people.

Email recovery has its own dependency chain. If an inbox is compromised, forwarded, abandoned, or recovered through another weak process, every account that treats that inbox as a root credential inherits the problem. SMS introduces number-porting and carrier support into the chain. A support console adds privileged accounts, audit systems, internal procedures, and another valuable target.

None of this means recovery is bad. It means provider-controlled recovery is a security capability with a breach surface. Calling it “customer support” does not change the trust boundary.

For a vault containing identity documents, credentials, financial records, or seed phrases, we do not think an email account and a persuasive conversation should become a universal decryption key.

The design: verification and recovery stay local

When you unlock NT² Vault, the important decision happens on your device.

The vault keeps a local password verifier: a small encrypted check value associated with that vault. Your device derives a key from the master password you enter and attempts to validate that check. If the password is wrong, or the verifier is damaged, validation fails closed. The vault remains locked.

The verifier is not a password hint. It is not a copy that support can look up. It is not uploaded to a server so an operator can compare guesses on your behalf. Its purpose is narrow: let the local vault distinguish the correct derived key from an incorrect one without decrypting your records and hoping that something looks readable.

This arrangement has an important consequence. NT² cannot edit a cloud database row to make a new password “correct.” The old encrypted data is protected by key material rooted in what you hold locally. A reset that merely changes a web account credential would not transform the existing ciphertext.

So recovery has to be planned around user-held material instead of provider authority. NT² supports several tools because “recovery” covers more than one failure:

• A portable .nt2backup is an encrypted snapshot of your vault contents. It helps with migration, device loss, and disaster recovery. You can keep copies in locations you choose and restore without making NT² cloud the sole source of truth. A backup preserves data, but it is not automatically a substitute for a forgotten master password.
• A recovery kit is encrypted access material that you save separately. On a new or reset device, it can help reconstruct a user-controlled path to the vault when combined with the required knowledge or factors. NT² does not retain a duplicate behind the scenes.
• User-held recovery shares can divide the power needed for recovery across things you control. In plain language, no single file, device, or company database is treated as the spare master key. Recovery succeeds only when the user brings together the required pieces.

The exact tool depends on the kind of vault and the failure you are preparing for. The operational lesson is simpler than the cryptography: keep a current encrypted backup, preserve the recovery material your setup provides, store it separately from the everyday device, and do not place every factor in the same bag.

These tools change who can recover the vault. They do not make loss impossible.

If a person loses the only device, every backup, the recovery kit, the necessary user-held pieces, and the master password, NT² cannot manufacture a missing secret. Conversely, if the person keeps the required recovery material safely, they have a path that does not depend on persuading our support team or keeping a subscription active.

That is user-controlled recovery: the system helps you prepare, verify, export, and restore, while refusing to make the provider the final key holder.

The trade-off: support cannot “just unlock it”

There is a real cost to this design.

A support agent can explain which recovery artifact is needed. They can help identify whether someone has a backup or a recovery kit. They can document file-handling steps, clarify error messages, and help distinguish a damaged file from the wrong password. They can improve the product when those instructions are confusing.

They cannot unlock the vault.

That answer will feel unsatisfying when someone is looking at years of important records and remembers almost—but not quite—the right password. It creates an education burden before anything goes wrong: users need to understand that account support and cryptographic recovery are different jobs. They need prompts to export recovery material, warnings when it is stale, and language that does not hide consequences behind a cheerful padlock illustration.

The product also has to resist a common temptation: promising “zero-knowledge” on the security page while quietly preserving an exceptional recovery route for difficult support cases. An exception capable of decrypting one legitimate customer’s vault is still a decryption capability. Attackers do not care that it was intended for emergencies.

We would rather state the limitation early and build usable, user-held recovery paths around it. That moves responsibility toward the user, but it also moves authority there.

The trade is not convenience versus security in the abstract. It is choosing who bears the final power to recover encrypted data. NT² chooses the person holding the vault and its recovery materials, not the company operating the service.

What we refuse to build

Two shortcuts would make the support script easier. We reject both.

No email OTP that unlocks vault contents

Email can be useful for receipts, notices, and ordinary communication. It is not the cryptographic root of an NT² vault.

We will not send a one-time code that converts control of an inbox into access to encrypted vault contents. That would make the security of the vault depend on the email provider, its recovery process, the user’s active sessions, forwarding rules, and every device where that inbox is open. It would also create exactly the provider-controlled bridge between identity recovery and decryption that this design removes.

An email may tell you what happened. It must not become the secret that makes ciphertext readable.

No support console that decrypts user data

We will not give support staff a button to reveal vault items, attachments, or recovery secrets.

Building such a console would require NT² to possess or obtain a decryption capability. Restricting the button to senior staff, recording every use, or requiring two approvals would improve governance around that capability; it would not remove the capability. The console would remain a target for attackers, insiders, mistakes, and legal demands.

Support tools should expose service health and non-sensitive operational facts, not plaintext vault contents. When diagnosis concerns encrypted data, the useful evidence must come from the user’s device without uploading their secrets.

These refusals are not claims that email and support teams are inherently unsafe. They are boundaries. A communication channel should remain a communication channel. A help desk should remain a help desk. Neither should silently become a master key.

Recovery without a provider-owned back door

No-password-reset design is easy to summarize and harder to live with: NT² cannot reset your master password because it never held the material that would make such a reset possible.

That constraint narrows the blast radius of a compromised inbox, a deceived support agent, or a breached administration system. It also means recovery preparation cannot be postponed until after every user-held path is gone.

The goal is not to leave people alone with a warning. The goal is to provide understandable tools that keep recovery authority in their hands: encrypted backups for the contents, recovery kits and user-held pieces for access, and clear guidance about storing them separately.

This boundary is one expression of what Null Trust² means. Portable backup is the escape hatch you hold—not a provider reset. And the local ingredients behind unlock are why the KDF salt stays on device.

If that trade-off matches how you want a private vault to work, read the linked design notes, make a recovery plan you can actually maintain, and open NT² Vault when you are ready.