Authenticator Apps and OTP Guide: TOTP, HOTP and Push

Authenticator apps and one-time passwords are the most widely deployed second factor, and most teams run them without knowing how the seed, the clock and the verifier actually work. A six-digit code is only as strong as the shared secret behind it, the way that secret was enrolled and stored, the verifier's replay and rate-limit rules, and the recovery path when a phone is lost. This guide explains HOTP (RFC 4226) and TOTP (RFC 6238), the parameters that matter, seed handling on both sides, backup codes, app backup and migration, hardware OATH tokens, and where OTP sits against SMS, email codes, push and FIDO2 under NIST SP 800-63B-4. It is written for identity engineers, IAM administrators and application developers who run or build OTP-based MFA.

Key takeaways

• The seed is the credential. TOTP and HOTP codes are derived from a symmetric secret held by both the app and the server; anyone who copies the QR code, the backup file or the server's seed store can generate valid codes.
• OTP is not phishing-resistant. NIST SP 800-63B-4 states "OTP authentication is not phishing-resistant." A real-time phishing page relays the code within its validity window, as Cloudflare saw in 2022.
• Verifier rules decide real strength. Accept each code once, keep the time window tight, and limit failed attempts; NIST caps consecutive failures at 100 and allows lower limits.
• Recovery is part of the authenticator. App backup, phone migration, backup codes and help desk resets are where OTP deployments usually fail, so design them before rollout.
• Use OTP as a floor, not a target. TOTP apps are a clear improvement on SMS and email codes, but the NCSC ranks code generators below FIDO2 and push with number matching; plan the move to passkeys or security keys for high-risk users.

How HOTP and TOTP work

Both are open OATH algorithms published by the IETF as Informational RFCs, so any compliant app or token works with any compliant server.

• HOTP (RFC 4226, December 2005): HOTP(K,C) = Truncate(HMAC-SHA-1(K,C)), where K is the shared secret and C is a counter that both sides increment. Dynamic truncation takes the low-order 4 bits of the last byte of the HMAC as an offset, reads 4 bytes from there, masks the top bit, and reduces the result modulo 10 to the power of the number of digits. Implementations "MUST extract a 6-digit code at a minimum".
• TOTP (RFC 6238, May 2011): TOTP replaces the counter with time: T = (Current Unix time - T0) / X, rounded down, with a default time step X of 30 seconds and T0 of 0 (the Unix epoch). TOTP implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 instead of HMAC-SHA-1, and keys SHOULD be the length of the HMAC output.
• What the code proves: possession of the seed at the moment the code was generated. It does not prove which website the user is talking to, which is the root of OTP's phishing weakness.

TOTP vs HOTP

Choose TOTP unless a device has no clock. RFC 4226's own analysis puts the chance of a brute-force success at roughly s × v / 10^Digit, where s is the look-ahead window and v the number of attempts allowed, so a wide HOTP window directly weakens the factor.

Parameters that matter

The otpauth URI behind the QR code

Most apps enrol by scanning a QR code that encodes a Key URI of the form otpauth://totp/Issuer:account?secret=...&issuer=Issuer. The secret is the Base32-encoded seed, with padding omitted. Optional parameters are algorithm, digits, period and, for HOTP, a required counter. Google's documentation notes that its Authenticator implementations ignore algorithm and period, so a server that issues SHA-256 or 60-second seeds must test every app it supports or users will see codes that never validate. Always set both the issuer prefix and the issuer parameter so users can tell accounts apart.

Enrolment and seed handling

Because the QR code is the seed in plain form, enrolment is the moment of greatest exposure.

• Generate the seed on the server: Microsoft Entra ID, for example, generates the secret key for software tokens and presents it to the app. Use a cryptographically secure generator and the full key length.
• Prove the binding: require the user to enter a valid code before the factor is activated. This catches clock and parameter mismatches and proves the user captured the seed.
• Protect the enrolment action: registering a new authenticator should require an existing strong factor or a help desk issued temporary credential, not just a password. OWASP advises "Require reauthentication with an existing enrolled factor before allowing changes" and "Do not rely solely on the active session, as it may be hijacked." Enrolment hijack is covered in the MFA Fatigue and Bypass Guide.
• Never log or email the seed: do not cache the QR page, and treat a QR screenshot in a support ticket as credential exposure.
• Notify on change: tell the user through another channel whenever an authenticator is added or removed.

Server-side seed storage

Unlike a password hash, the verifier must be able to recover the seed to compute the expected code. NIST SP 800-63B-4 requires that these symmetric keys "SHALL be strongly protected against unauthorized disclosure by access controls". RFC 4226 recommends encrypting stored secrets with tamper-resistant hardware and decrypting them only when needed for verification, and RFC 6238 says the key store "MUST be in a secure area". In practice: envelope encryption under an HSM or cloud KMS key, a separate database role for the seed table, and no readable seeds in backups.

The consequence of getting this wrong is a mass re-enrolment. After the Dropbox Sign breach, Dropbox said the attacker accessed authentication information including "multi-factor authentication" data and told customers: "Customers who use an authenticator app for multi-factor authentication should reset it." Have a tested process to revoke every seed and force re-enrolment before you need it.

Hardware OATH tokens and seed files

Hardware tokens arrive with seeds programmed at the factory, so the vendor ships a seed file. RFC 6030, the Portable Symmetric Key Container (PSKC), is the standard XML format for transporting OTP seeds; it protects keys with pre-shared keys, passphrase-derived keys (PBKDF2) or a recipient's public key, and requires a keyed MAC where the encryption mode lacks integrity. Treat the seed file as a credential store: import it, verify the import, then destroy the file. In Microsoft Entra ID the Authentication Policy Administrator role manages the token inventory, reads do not return the secret, and the secret cannot be updated; users can self-assign and activate a token from Security info by entering its current code. OWASP notes the main residual risk: "Stolen tokens can be used without a PIN or device unlock code."

Backup codes, app backup and migration

Every answer to a lost phone is also a recovery path an attacker can use.

• Backup codes: NIST treats these as look-up secrets: at least six decimal digits, "used successfully only once", and "stored in a hashed form using an approved hashing function". They are not phishing-resistant. Issue them at enrolment, show them once, and alert when one is used.
• Two authenticators: NIST says CSPs and verifiers "SHOULD encourage subscribers to maintain at least two separate means of authentication". A second TOTP device, a hardware token or a passkey reduces help desk resets more than any backup scheme.
• Cloud-synced apps: Google announced in April 2023 that Authenticator could back up codes to the user's Google Account; before that, codes "were only stored on a single device". Sync improves durability but makes the seeds only as safe as the sync account and its recovery.
• Platform-bound restore: Microsoft Authenticator backup and restore works only on the same device type, so an iOS backup cannot be restored on Android. For work or school accounts "Only the account name is restored", and the user must sign in again, which means re-registration through your enrolment controls.
• Vendor incidents: in July 2024 Twilio said an unauthenticated endpoint let threat actors identify data associated with Authy accounts, including phone numbers, stated that "Authy accounts are not compromised", and asked users to update and watch for phishing and smishing. The app vendor's own security becomes part of your threat model.
• Password managers holding TOTP seeds: storing the seed in the same vault as the password is convenient, but a single vault compromise then yields both factors. Accept it for low-risk personal accounts; for workforce accounts keep the second factor on a separate device or move to passkeys.

Push approval and app-based codes

Most enterprise authenticator apps (for example Microsoft Authenticator, Okta Verify and Duo) offer push approval alongside TOTP codes. Microsoft notes that Authenticator also generates codes when set up for push, so users have a fallback without connectivity. Push brings its own attack, prompt fatigue, which the NCSC cites when it describes challenge-based apps as giving "only partial phishing resistance". Number matching, push rate limits and the fallback paths that bypass them are covered in the MFA Fatigue and Bypass Guide; check that disabling push does not leave a TOTP code path with weaker rate limits.

Comparing OTP and other second factors

NIST SP 800-63B-4 (final, July 2025) requires verifiers to "offer at least one phishing-resistant authentication option at AAL2", explains that manual entry "does not bind the authenticator output to the specific session being authenticated", and does not list OTP among the authenticators permitted at AAL3. See the Passwordless and Passkeys Guide and the Hardware Security Keys Guide for the next step.

Known weaknesses and how attackers exploit them

• OTP phishing by real-time relay: in August 2022 Cloudflare described a page that collected employees' credentials and TOTP codes and relayed them to the attacker through Telegram so they could be used before expiry. Three employees entered credentials, and the attack failed only because Cloudflare uses FIDO2 keys and not TOTP.
• Interception (ATT&CK T1111): Multi-Factor Authentication Interception covers capturing token input on a compromised device and intercepting codes sent by SMS or email, including by compromising an SMS messaging service.
• Seed theft: from the server's seed store, from cloud backups of the app, from screenshots of the enrolment QR code, or from a password manager that holds both factors.
• Weak verifier logic: codes accepted more than once, windows of several minutes, no lockout, or a lockout that resets when a new code is requested.
• Recovery bypass: a help desk that resets the authenticator after a convincing call makes the factor irrelevant. See the Account Recovery and Help Desk Security Guide.

Choosing the right option

• SMS vs authenticator app: move to an app wherever users have a smartphone. The app removes SIM swap and carrier interception, costs nothing per code and works offline. OWASP advises: "Do not use SMS for high-value or PII-handling applications."
• App vs hardware OTP token: use hardware TOTP tokens for staff who cannot or will not use a personal phone, shared shop-floor roles and regions with phone restrictions. If you are buying hardware anyway, compare the cost with FIDO2 keys, which are phishing-resistant.
• When OTP is acceptable: general workforce and customer accounts at AAL2 where a phishing-resistant option is also offered. It is not acceptable as the only factor for administrators, help desk staff, developers with production or publishing rights, or anyone at AAL3.
• Small organisations: turn on TOTP or app-based MFA in the email and identity platform, issue backup codes, and buy security keys for the handful of administrators.
• Large organisations: manage authentication methods centrally, disable SMS and email OTP where an app is available, keep hardware OATH inventory under a named role, and set a dated target for phishing-resistant MFA on privileged groups.

How to implement: a phased rollout

1. Inventory: list every application that issues or verifies OTP, the parameters it uses, where seeds are stored and who can read them, and which accounts still use SMS or email codes.
2. Fix the verifier: enforce single use, a one-step window, attempt limits that do not reset on new codes, and drift recording. Test with a pilot group whose devices are deliberately set a minute fast and slow.
3. Protect seeds: move seed storage under KMS or HSM envelope encryption and restrict read access. Write and test the mass revoke-and-re-enrol runbook.
4. Enrol in rings: start with IT, then one business unit, then everyone. Require an existing factor or a temporary access pass for registration, verify a code before activation, and issue backup codes.
5. Retire weaker methods: once app coverage is high, disable SMS and email OTP for workforce accounts. Rollback is re-enabling the method for a named group, not for the whole tenant.
6. Plan the next step: move privileged users to FIDO2 or certificates and keep TOTP as a registered backup only where policy allows.

Detection and measurement

What to monitor

• Repeated invalid codes: a correct password followed by failed codes suggests the password is compromised; OWASP recommends notifying the user with time, browser and location.
• Authenticator registration and removal: especially a new device added shortly after a failed sign-in or a help desk call.
• Backup code use: each use should be rare and should alert the user and the SOC.
• Replay attempts: the same code submitted twice, which points to a relay or interception.
• Seed store access: reads of the seed table or decrypt calls on its KMS key from anything other than the verifier service.

Metrics that show it is working

• Share of accounts on SMS or email OTP: should fall steadily to near zero for the workforce.
• Accounts with two or more registered authenticators: a leading indicator of fewer risky resets.
• OTP-related help desk resets per 1,000 users per month: and the share verified to the required standard.
• Phishing-resistant coverage of privileged accounts: target 100 per cent.
• Time to revoke and re-enrol all seeds: measured in an exercise.

Framework mapping

Common failure patterns

• Treating codes as phishing-proof: the Twilio breach and 0ktapus campaign used SMS lures to fake sign-in pages that captured credentials and codes at scale.
• Seeds stored like ordinary data: once an attacker reads the seed table, every account's second factor is gone, as the Dropbox Sign reset advice shows.
• Parameters the app ignores: issuing SHA-256 or 60-second seeds that some apps silently treat as SHA-1 and 30 seconds, then widening the window to stop complaints.
• Recovery weaker than the factor: backup codes stored unhashed, or help desk resets on knowledge questions alone.
• Leaving SMS enabled beside the app: attackers choose the weaker method, so the app adds nothing while SMS stays registered.

Practitioner checklist

• Prefer TOTP over HOTP, with 30-second steps, six or more digits and at least 160-bit seeds.
• Accept each code once, allow at most one step of drift, and cap failures well below 100.
• Encrypt seeds under an HSM or KMS key and restrict who can read the seed store.
• Protect authenticator registration with an existing factor or a temporary access pass, and notify on every change.
• Issue single-use backup codes stored hashed, and encourage a second authenticator.
• Test every supported app against your algorithm, digit and period settings.
• Disable SMS and email OTP for workforce accounts once app coverage allows.
• Keep a tested runbook to revoke all seeds and force re-enrolment.
• Move administrators and other high-risk users to FIDO2 or certificate-based authentication.

Standards and references

• IETF: RFC 4226 HOTP: An HMAC-Based One-Time Password Algorithm
• IETF: RFC 6238 TOTP: Time-Based One-Time Password Algorithm
• NIST: SP 800-63B-4 Authentication and Authenticator Management
• IETF: RFC 6030 Portable Symmetric Key Container (PSKC)
• NCSC: Recommended types of MFA
• OWASP: Multifactor Authentication Cheat Sheet
• Microsoft Learn: OATH tokens authentication method in Microsoft Entra ID
• Google: Key Uri Format (google-authenticator wiki)

Related NHI Mgmt Group resources: MFA Guide · MFA Fatigue and Bypass Guide · Passwordless and Passkeys Guide · Hardware Security Keys Guide · Account Recovery and Help Desk Security Guide