2FASync
The website and authenticator calculate matching time windows
Your authenticator usually does not download a fresh six-digit code. It repeats a calculation the account provider can independently verify.
Enrollment establishes a shared secret
When you activate time-based two-factor authentication at an original website, that service creates or supplies a secret and a configuration. The authenticator reads the setup key or scans the setup QR. The QR might look like a harmless visual marker, but it can encode the long-lived secret, account label, issuer, and algorithm settings. An attacker who retains this material can calculate future values, even after the QR leaves your screen.
Always confirm you are adding a factor on the intended account. If you store the same seed in two authenticator tools, both may generate the same code; that is not proof that the service has enrolled two independent factors. Removing a local entry also does not necessarily revoke the original service's TOTP enrollment. Use the original website's security settings to rotate or disable a compromised seed.
A time counter drives the short displayed code
For a standard TOTP, the authenticator computes a counter from the current Unix time and the configured time-step length, processes the counter together with the secret through HMAC, and truncates the result to the requested number of digits. The original service uses its copy of the secret, the same parameters, and an acceptable time window to decide whether the number matches. The local calculation does not have to call the original website or a central 2FASync OTP API.
A short countdown is a usability aid rather than a guarantee that a submitted code will remain accepted for exactly that many seconds. Network delay, client clock drift, server verification windows, and rate limiting can affect the result. A site may choose to accept a narrow neighboring window, but 2FASync cannot promise what another site's verifier permits.
Offline generation and online verification are separate
Once the secret is available locally, an authenticator can generate the next code during temporary internet loss. You still need a route to the original website when you actually sign in, and that website must check the number. Member encrypted sync is another operation entirely: it transfers encrypted credential data between member devices; it is not required for each rotating code and it does not have to deliver ready-made OTPs from the server.
A browser using guest 2FA Live similarly calculates codes inside the page. Clearing the page or reloading it removes guest input, so it will not remember an old seed just because the website account was enrolled previously. For a durable copy, plan encrypted Vault storage and recovery material separately.
Why a matching code can still be unsafe to share
Anyone who sees the current OTP may be able to relay it within the valid window. The threat is especially acute when a login page imitates the real site's design and address. A code only proves that someone supplied a current value, not that the page asking for it is authentic. Pay attention to the exact domain, the sign-in action, and unexpected prompts for multiple consecutive codes.
Never share the underlying setup QR or Base32 key to obtain troubleshooting help. For a code problem, record non-sensitive details such as the displayed error class, whether the clock is synchronized, and which profile fields the original service explicitly supports. A support channel that asks you to transmit your real seed or recovery key should not be treated as a safe diagnostic path.