Trusted-Device Approval for Password Managers

Why enrollment deserves its own control

A synchronized password manager has to decide when a new browser or phone may receive encrypted vault data. If possession of an email address and master password is the only requirement, an attacker who captures both can attempt enrollment from a remote machine.

Trusted-device approval changes that path. The unfamiliar client first creates a pending request with its identity, name, IP address, and available network-location context. A device already associated with the account can inspect and accept or reject the request before enrollment completes.

Authier’s three policy choices

Allow immediately

The new client can complete enrollment without another device approving it. This is the least restrictive option and can be useful when one-device access or simple recovery matters more than the extra check.

Require any approved device

A connected device must approve the pending request. This is convenient when you own several trusted clients because any one of them can help enroll the new browser.

Require the master device

The account’s designated master device controls the approval decision. This creates a clearer security anchor, while increasing the importance of protecting and recovering that device.

Authier exposes these as choices because no single recovery model is right for everyone. The marketing site should not imply that device approval is active when an account has selected immediate enrollment.

What approval can stop

• A remote enrollment attempt using a captured account email and master password.
• A silent new-device login when the configured policy requires explicit review.
• Continued access from a device that you later sign out or remove.
• Automatic TOTP synchronization to a device where you have switched that setting off.

What approval cannot stop

• Malware or a malicious extension reading data from an already-unlocked client.
• A user approving a convincing fraudulent request without checking its context.
• Physical access to an unlocked device or compromise of its operating system.
• Implementation flaws in the client, backend, cryptography, or recovery flow.
• Phishing that captures credentials used directly at the target service.

Device approval is defense in depth, not a security guarantee. It should sit beside local device security, a strong master password, encrypted vault storage, careful recovery, and phishing-resistant authentication where available.

Recovery is part of the threat model

Strict approval becomes dangerous if losing one device permanently locks out the owner. Authier includes a recovery-based master-device reset flow with an email confirmation and configurable cooldown. The delay gives an existing owner time to notice and reject a fraudulent recovery attempt, but email security becomes part of the recovery chain.

Recovery controls must balance two failures: unauthorized access and permanent lockout. A longer cooldown gives more detection time; a shorter one restores access sooner. Protect the email account, retain independent recovery methods, and test the process before an emergency.

How to review an approval request

1. Initiate enrollment yourself and keep both devices visible.
2. Compare the displayed device name, time, IP address, and approximate location.
3. Reject any request you cannot explain, even when one detail looks familiar.
4. After approval, verify the new client and remove old devices you no longer control.
5. Review whether TOTP synchronization and lock timeout are appropriate for that device.

Evidence you can inspect

Authier’s request, approval, recovery, and device-management paths are public in the source repository. The current implementation records approval state, device history, sync state, IP context, and recovery timing. Authier has not published an independent third-party audit, so public code should be treated as inspectable evidence, not proof that the design is flawless.