TOTP Validity Calculator

Size the RFC 6238 TOTP acceptance window from the time step and drift tolerance, and see the clock skew it forgives.

Inputs

Time step (X)seconds

RFC 6238 recommends a 30-second step, which is what every mainstream authenticator app uses.

Drift windows accepted each sidesteps

Client clock skewseconds

Code lengthdigits

Total Acceptance Window

90seconds

Time Steps Accepted

3steps

Clock Skew Tolerated

30seconds

Verdict for This Client

Accepted — the skew fits inside the drift window

Chance a Random Code Is Accepted

0.000300%

Average Remaining Life of a Displayed Code

15.0seconds

Step by step

Values used
Time step (X) = 30 seconds; Drift windows accepted each side = 1 steps; Client clock skew = 12 seconds; Code length = 6 digits
TOTP Validity
acceptance window = time step × (2 × drift windows + 1); clock skew tolerated = drift windows × time step.
False-accept probability
P(random code accepted) = steps accepted ÷ 10^digits.
Total Acceptance Window
= 90 seconds
Time Steps Accepted
= 3 steps
Clock Skew Tolerated
= 30 seconds
Verdict for This Client
= Accepted — the skew fits inside the drift window
Chance a Random Code Is Accepted
= 0.000300
Average Remaining Life of a Displayed Code
= 15.0 seconds

How it works

TOTP is HOTP with the counter set to floor((current time − T0) ÷ X), so validation means recomputing the code for the current step. Because client and server clocks drift, RFC 6238 lets the server also test one step either side, which triples the acceptance window to 90 seconds at the standard 30-second step and triples the false-accept probability with it. Every extra drift window you allow to placate users with bad clocks widens both the replay window for a phished code and the odds of a blind guess, so the tolerance should be a deliberate decision rather than a default nobody read.

Formulas

TOTP Validity

acceptance window = time step × (2 × drift windows + 1); clock skew tolerated = drift windows × time step.

time step: X in RFC 6238 — the counter interval, normally 30 seconds
drift windows: Steps the server also checks on each side of the current one

False-accept probability

P(random code accepted) = steps accepted ÷ 10^digits.

Frequently Asked Questions

How is TOTP Validity calculated?

acceptance window = time step × (2 × drift windows + 1); clock skew tolerated = drift windows × time step. TOTP is HOTP with the counter set to floor((current time − T0) ÷ X), so validation means recomputing the code for the current step. Because client and server clocks drift, RFC 6238 lets the server also test one step either side, which triples the acceptance window to 90 seconds at the standard 30-second step and triples the false-accept probability with it.

Why does TOTP Validity matter?

Every extra drift window you allow to placate users with bad clocks widens both the replay window for a phished code and the odds of a blind guess, so the tolerance should be a deliberate decision rather than a default nobody read.

What values do I need to enter?

This calculator takes 4 inputs: Time step (X), Drift windows accepted each side, Client clock skew, Code length. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why is the window 90 seconds when the code shows for 30?

The server accepts the previous, current and next step. A code the user typed just as the step rolled over still validates, which is the whole point — but it also means a code stays replayable for up to 90 seconds after it was generated.

How do I handle a client whose clock is badly wrong?

Do not widen the window for everyone. RFC 6238 suggests recording a per-client drift offset once the user has successfully authenticated, then applying that offset on later validations so the shared window stays narrow.

You might also need

HOTP Counter Calculator OTP Lifetime Calculator MFA Security Calculator