If you've set up multi-factor authentication for your organization, you've likely encountered two acronyms: TOTP and HOTP. Both generate one-time passwords. Both are open standards. But they work differently, and those differences matter — especially when managing shared codes across a team.

This guide explains both standards clearly, compares them, and helps you decide which is appropriate for your use cases.

What Is OTP?

OTP stands for One-Time Password. It's a numeric code (typically 6 digits) that is valid for a single authentication session. Unlike static passwords, OTPs change with each use — which is why they're a second factor in multi-factor authentication.

Both TOTP and HOTP generate OTPs, but they use different inputs to do so.

HOTP: HMAC-Based One-Time Password

HOTP (RFC 4226, published 2005) generates a code using:

A shared secret (the OTP seed, stored in the authenticator)
A counter (a number that increments with each code generated)

The formula: OTP = HMAC-SHA1(secret, counter) truncated to 6 digits

When a user generates an HOTP code, both the authenticator and the server increment their counter. The server accepts codes within a small window of the expected counter value to account for synchronization drift.

HOTP characteristics

Counter-based: the code changes only when you request a new one
Long-lived codes: a generated HOTP code doesn't expire until it's used (or the counter advances)
Synchronization required: if the counter gets out of sync between client and server, authentication fails
Less common today: TOTP has largely replaced HOTP for standard MFA use cases

When HOTP makes sense

HOTP works well for:

Hardware tokens with physical buttons (YubiKey OTP mode, RSA SecurID)
Scenarios where time synchronization is unreliable (air-gapped systems, offline environments)
One-time use codes in specific workflows (recovery codes)

TOTP: Time-Based One-Time Password

TOTP (RFC 6238, published 2011) generates a code using:

A shared secret (same as HOTP)
The current time (in 30-second intervals, by default)

The formula: OTP = HOTP(secret, floor(current_unix_time / 30))

Because both the authenticator and the server use the same time source, they independently generate the same code at the same moment — without needing to synchronize a counter.

TOTP characteristics

Time-based: codes expire every 30 seconds regardless of whether they're used
No synchronization required: time is the shared source of truth
Requires clock accuracy: device time must be approximately correct (servers usually accept ±1 interval)
Dominant standard: virtually every modern MFA implementation uses TOTP

When TOTP makes sense

TOTP is appropriate for:

Almost all web-based MFA implementations (AWS, GitHub, Google, Stripe, etc.)
Team-shared credentials in a shared vault
Any scenario where 30-second validity windows are acceptable

Side-by-Side Comparison

| Feature | TOTP | HOTP | |---|---|---| | RFC | RFC 6238 | RFC 4226 | | Input | Time | Counter | | Code expiry | 30 seconds | Only when used | | Clock sync needed | Yes | No | | Counter sync needed | No | Yes | | Common use cases | Web MFA, apps | Hardware tokens | | Supported by most services | Yes | Partial |

What This Means for Shared MFA Management

For IT teams managing shared codes, TOTP is almost always the right choice:

Universal compatibility: every major SaaS platform supports TOTP
Time-based expiry: even if a code is observed or intercepted, it's invalid within 30 seconds
No state management: no need to track counter values across multiple team members accessing the same code
Vault-friendly: time-based codes work naturally in shared vault scenarios — anyone accessing the code at the same moment sees the same value

HOTP introduces counter-state complexity in shared scenarios. If two team members request an HOTP code simultaneously, the counter advances differently for each, causing synchronization failures.

Algorithm Variants and Configuration

Modern TOTP implementations support some configuration options worth knowing:

Time step: Standard is 30 seconds. Some implementations use 60 seconds. Most vault solutions support both.

Code length: Standard is 6 digits. Some services use 8 digits. Check service documentation.

Hash algorithm: Standard is SHA-1. Some implementations support SHA-256 or SHA-512. Most services still use SHA-1 for TOTP.

Clock tolerance: Servers typically accept the previous interval and next interval to account for clock drift. This gives effective codes a ~90-second window.

When importing codes into a vault like Gatera, these parameters are encoded in the otpauth:// URI format or the QR code — so you don't need to configure them manually.

Reading an otpauth:// URI

When you export an OTP code from an authenticator app or get one from a service, it's often in this format:

otpauth://totp/ServiceName:user@example.com?secret=BASE32SECRET&issuer=ServiceName&algorithm=SHA1&digits=6&period=30

Key fields:

totp or hotp — the algorithm type
secret — the base32-encoded shared secret
algorithm — SHA1, SHA256, or SHA512
digits — code length (usually 6)
period — time step in seconds (TOTP only, usually 30)

A proper MFA vault handles this URI format natively, so importing and organizing codes is straightforward.

Conclusion

TOTP and HOTP are both valid OTP standards, but for team-based MFA management, TOTP is the clear choice. Its time-based expiry, universal compatibility, and stateless nature make it ideal for shared vault scenarios.

When building out your organization's authentication management, standardize on TOTP where possible, and use a dedicated team vault to manage code storage, access control, and audit logging.

Explore Gatera → — the shared MFA vault that supports TOTP and HOTP for IT teams and MSPs.

TOTP vs HOTP: What's the Difference and Which Should Your Team Use?