Errors from a password manager fall into a small number of families, and they are easy to confuse because several of them use similar wording. This guide separates them by stage: reaching the service, proving who you are, unlocking locally, exchanging data, and finishing a sync. Each stage has its own causes, and identifying the stage is most of the work.
Record the exact error text before doing anything. Wording that looks interchangeable in a small dialog is often decisive in a support ticket. If the failure happens while adding a new device rather than during ordinary use, read the section on device authorisation first; our nordpass login overview describes the normal sequence for comparison.
Stage one: the client cannot reach the service
DNS failures, timeouts, and refused connections all mean the request never completed. They are usually environmental: no connectivity, a captive portal on public Wi-Fi that intercepts traffic, a filtered network that blocks the endpoint, a proxy that requires configuration, or a device with no working network stack at all.
Distinguish them by testing an unrelated site on the same connection. If nothing loads, the network is the problem. If everything else loads and the client does not, the client may be configured for a proxy, or something on the device is filtering its requests. Note that a proxy setting left over from a previous network will fail on every network that does not use it.
Stage two: the identity check fails
Rejected credentials, expired sessions, and pending second factors are account-side rather than connection-side. An expired session often follows a long period away or a password change made on another device, and signing in again normally resolves it without touching any setting.
If a second factor never arrives, the registered method may be an authenticator whose codes have drifted, an SMS number that no longer receives messages, or a hardware key that is no longer paired. Verify the registered method through the official account portal rather than by creating a new one, since replacing the method may lock you out of the very page you need.
Stage three: the vault will not unlock locally
If the master password is accepted but the vault stays closed, the problem is not connectivity. Common causes are a pending approval on another device, a security hold after repeated failed attempts, a device clock that has drifted far enough to upset token validation, or an app update that left local state inconsistent.
A wrong system clock is an underrated cause because it produces errors that look like credential failures. Check that your device date, time, and time zone are set automatically.
If the vault will not open but you are certain of the master password, stop retrying. Excessive attempts can extend a security hold, and every additional attempt reduces the value of the ones you have left.
Stage four: the device is not authorised
Adding a device normally requires an existing authorised session to approve the new one. If the previous session has expired or was revoked, the new device cannot complete authorisation and will report a connection error that looks identical to a network problem.
The same error appears when a device has been signed out remotely or removed from the account's active list, which is the intended result of revoking a lost device. Authorising it again requires another trusted device or the official recovery flow.
Plans also limit how many devices can be active at once. Exceeding the limit produces an error that reads like a technical failure but is actually a subscription condition. Check the account's device list and the plan's allowance before assuming something is broken.
Stage five: sync completes but the result is wrong
Some failures are silent rather than loud. A sync finishes without an error while a newer edit on one device does not appear on another, which usually means one device was offline for the period in which the change happened and has not yet reconnected.
Two devices making conflicting edits to the same item can also produce a version you did not expect. Bring one device online, let it settle, and check the result on the second before assuming data was lost. Reinstalling an app to "fix" a sync discrepancy can make things worse by discarding the local state that would have shown what happened.
Never disable the security check that is reporting the error
Certificate warnings, expired TLS errors, and hostname mismatches are the client telling you that the connection may not be the one you think. The tempting fix is to continue anyway or to switch off validation. That converts a visible warning into a silent compromise, and for a product holding every credential you own it is the one shortcut worth refusing.
If a certificate warning appears on a network you trust, it usually means interception by a corporate proxy. Ask the administrator to install the correct root certificate on the device, which is the supported way to make managed inspection work.
Assemble an escalation record
A report that reaches the right team immediately should contain the exact error wording, the timestamp with a time zone, the app and platform versions, which stage failed, which of your devices are affected, whether other accounts work on the same connection, and the last successful operation. Add a screenshot cropped tightly around the message when policy permits it.
Redact everything sensitive first: email addresses, site names, partial passwords, account identifiers, and any notification containing personal data. A cropped error message carries all of the useful signal and none of the risk.
We are an independent fan website, so we cannot inspect your account, reset anything, or lift a hold. Only the vendor's official support can act on the account itself, and a report written this way is the fastest route to a real answer. Until then, protect what you can: if you suspect an unauthorised session, change the master password, which invalidates the stored copy on every device.