TOTP stands for Time-based One-Time Password. It is the algorithm behind the 6-digit codes you enter during two-factor authentication (2FA).
Defined in RFC 6238 (published in 2011), TOTP is an extension of HOTP (RFC 4226, counter-based) where the counter is replaced by time.
The principle is simple:
The TOTP algorithm breaks down into three main steps. Here is a simplified view of the calculation your app performs several times per minute:
// Step 1: Get the current time interval
T = floor(unix_timestamp / 30)
// Example: February 11, 2026 at 14:30:00 UTC
// timestamp = 1770843000
// T = 1770843000 / 30 = 59028100
// Step 2: Compute the HMAC
hmac = HMAC-SHA1(secret, T)
// Step 3: Truncate to get 6 digits
offset = hmac[last_byte] & 0x0F
code = (hmac[offset..offset+3] & 0x7FFFFFFF) % 1000000
// Result: a 6-digit code, e.g. 482937The crucial point is step 1: the calculation relies entirely on the UNIX timestamp, i.e., the number of seconds elapsed since January 1, 1970 00:00:00 UTC. Dividing by 30 creates 30-second "intervals".
T, and therefore not the same code. This is where NTP comes into play.
For TOTP to work, two devices that do not communicate directly with each other must arrive at the same result. The only shared variable is time.
NTP is the guarantor of this synchronization. Your phone synchronizes via NTP servers from your carrier or device manufacturer (Google, Apple). The authentication server synchronizes via its own NTP sources. Both parties thus obtain a consistent time within a few milliseconds — more than sufficient for TOTP's 30-second intervals.
To understand in detail how the NTP protocol works, see our dedicated guide.
All these apps use the same TOTP algorithm (RFC 6238). They are therefore interchangeable for most services:
The most well-known. Simple, no cloud backup (by default).
Cloud backup, push notifications, Microsoft 365 compatibility.
Encrypted backup, multi-device, desktop application.
Open source (Red Hat). No cloud dependency.
Stores secrets on a physical YubiKey. Uses the host device's clock.
Open source, encrypted backup, modern interface.
A mobile device's quartz crystal typically drifts by 0.5 to 2 seconds per day. Without regular NTP synchronization, this drift accumulates and eventually causes problems.
| Offset | Impact on TOTP | Consequence |
|---|---|---|
| 0 - 15 s | None | The code is within the current interval, everything works normally. |
| 15 - 30 s | Borderline | The code is at the end of the interval. May work thanks to server tolerance. |
| 30 - 60 s | Degraded | Works only if the server accepts T-1 or T+1. Unpredictable behavior. |
| 60 - 90 s | Near-total failure | The code rarely falls within the tolerance window. Frequent failures. |
| > 90 s | Total failure | Codes are systematically rejected. Requires clock resynchronization or a backup code. |
By default, TOTP uses a time step (timestep) of 30 seconds.
But most authentication servers implement a tolerance window
to compensate for slight drifts:
The most common configuration is to accept T-1, T, and T+1, which provides an effective window of about 90 seconds (3 intervals of 30 seconds). This setting is configurable on the server side:
To ensure your 2FA codes work at all times, follow these recommendations depending on your context:
If your 2FA codes are systematically rejected, it is very likely a clock issue. Check that automatic time synchronization is enabled on your device.
Yes, once the secret is configured, the app generates codes offline. It only needs the system time. However, without Internet for a long period, the clock will no longer be synchronized by NTP and will eventually drift enough to cause authentication failures.
NTP ensures that your phone and the authentication server share the same time. Without this synchronization, the generated TOTP codes do not match those expected by the server, and the login fails. It is an invisible but critical link in the security chain.
YubiKeys primarily use FIDO2/WebAuthn which does not depend on time, or HOTP (counter-based). However, when a YubiKey generates TOTP codes (via Yubico Authenticator), it depends on the host device's clock, as the key itself has no internal clock.
An attacker who manipulates your clock could invalidate your 2FA codes or exploit time windows. Use NTS (Network Time Security) to cryptographically authenticate your time source and prevent this type of attack.
The 30-second interval is a trade-off between security (a code valid for less time is harder to exploit) and usability (the user has enough time to read and enter the code). Some services use 60 seconds for more convenience, at the cost of a wider attack window.
Is your clock accurate enough for your 2FA codes? Test it now.
Check my clockNTP Infrastructure | Secure with NTS | Understanding NTP | FAQ