2FASync
A rejected authenticator code has several possible causes
Start with the clock and the original site's configuration. Preserve working authenticators and keep secrets out of diagnostic screenshots or support requests.
First check the current time window
If a six-digit code worked moments ago and fails now, wait for the next countdown window and copy its new value. Confirm that your device's date, time, and timezone settings are correct and that network-provided clock synchronization is functioning where available. TOTP depends on the time counter. A clock that is noticeably inaccurate can produce consistent-looking codes that the original website rejects.
Use only the authentic website's intended verification screen. If it repeatedly asks for two or three different codes without explaining why, check the site's exact address before entering more. A phishing page may be collecting real-time values. Some original websites rate-limit repeated OTP attempts, so rapid guessing can complicate rather than solve a simple configuration issue.
Compare the seed, algorithm, digits and period
A bare Base32 key defaults to six digits, HMAC-SHA-1, and 30 seconds in 2FASync. If the original site issued an otpauth TOTP URI with different supported parameters, use that complete setup information. Check account labels carefully: people who manage several tenants or infrastructure accounts may have two entries with nearly identical names but different secrets. The displayed digits alone cannot tell you which website enrollment produced the seed.
If a URI is rejected as invalid, inspect the original source rather than blindly modifying it. Unsupported or duplicated query fields, malformed Base32, a mismatched issuer, wrong code length, or HOTP type can all trigger deliberate parser errors. Do not paste the entire URI into a search engine or public ticket; it may contain the credential.
Resolve a QR camera or image error safely
If the camera does not open, verify that the browser is allowed to access the camera for the intended tab and that another application is not holding the device. Better lighting and steady framing may help when a QR is out of focus. For image import, check that the file is a supported local image rather than a web URL, an SVG, or an unrelated screenshot. Do not upload a live authenticator QR to an unknown converter simply to test whether its image is readable.
When Google Authenticator reports a multi-page export, scan every page from the same batch and check the importer shows completion. A missing fragment or two batches mixed together is a reason to restart the export, not to guess at the missing data. Review invalid and unsupported entries individually before committing anything to an encrypted Vault.
Read the difference between locked, unavailable and conflicted
A locked member Vault may need the matching passphrase or recovery key. A session that is signed into Google but not bound to an authorized browser may require a separate device registration or reauthentication. An unavailable key derivation profile may reflect a pending release acceptance gate rather than a wrong user secret. Never reset or overwrite a Vault simply because its first loading attempt failed.
A synchronization conflict means that multiple encrypted revisions require attention, perhaps after offline edits. Keep both records long enough to compare them and confirm which original website entry is current. A pending encrypted request does not equal a confirmed server commit, and a retry should preserve the original request identity rather than creating accidental duplicate item copies.
Record useful, non-secret diagnostics
Useful information includes the affected feature, approximate time, browser family and version, generic error code, whether the tab resumed after sleep, and whether the issue arose during guest code generation, migration, sync, backup, or restore. For a Google transfer, record how many QR fragments the interface expected and received without including QR pixel data. For a code mismatch, note the expected number of digits and algorithm category, not the full seed.
Never share a current OTP, Base32 setup key, complete otpauth URI, migration payload, Vault passphrase, recovery key, plaintext export, or readable screenshot of a credential. If you suspect a seed was disclosed while troubleshooting, rotate it at the original website. Use the appropriate original service recovery path when no working authenticator copy remains.
Why does a code change before I can type it?
The TOTP time window may have ended. Wait for the next code and use it promptly on the authentic website.
Why can I sign in with Google but not unlock the Vault?
Google login is identity authorization. Vault decryption also requires separate approved local unlock material.
What should I send when reporting an import failure?
Only a redacted error class, importer step, expected/received QR fragment count, and non-sensitive environment information. Never send a live QR, seed, code, or recovery key.
