Short answer: Authenticator apps work offline because a time-based one-time password, or TOTP, is calculated locally from two inputs already available to the authenticator: a secret key saved during enrollment and the device's current time. The login service stores a corresponding secret and performs the same calculation. If both sides use matching settings and sufficiently accurate clocks, they produce the same short-lived code without sending the code to each other.
Google Authenticator, Microsoft Authenticator, Aegis, 2FAS, Bitwarden Authenticator, Ente Auth, and the new SecurityBox Authenticator can all generate TOTP codes. Their main differences are where the secret keys are stored, which devices they support, whether they synchronize or back up entries, and who controls the infrastructure.
What is a TOTP authenticator?
A TOTP authenticator is software or hardware that generates temporary verification codes using the Time-Based One-Time Password algorithm described in RFC 6238. TOTP extends the HMAC-based one-time password algorithm by replacing an event counter with a time-derived counter.
A common TOTP code contains six digits and changes every 30 seconds, although the algorithm can use other digit lengths, time periods, and HMAC algorithms when both the authenticator and verifier support the same parameters. SecurityBox supports six-digit and eight-digit codes, SHA-1, SHA-256, SHA-512, and periods from 15 to 120 seconds.
How can an authenticator generate codes without internet?
The authenticator does not download each code from the website. Enrollment gives both sides the information needed to calculate it independently.
- The service creates a secret. When TOTP is enabled, the service generates a random secret key for the account.
- The secret is transferred once. The service commonly displays a QR code containing an
otpauth://totp/...provisioning URI. A setup key can be entered manually instead. - The authenticator protects the secret. The application saves the secret and associated settings such as issuer, account, algorithm, digits, and period.
- Time becomes a counter. The current Unix time is divided into fixed time steps. RFC 6238 uses 30 seconds as its default step.
- Both sides calculate the result. The authenticator and service apply the same HMAC-based calculation to the shared secret and time counter, then truncate the output to the required number of digits.
- The service compares the submitted code. During sign-in, the service calculates its expected code and may also check a small adjacent window to allow reasonable clock drift and typing delay.
Only the final short-lived code must be entered during login. Generating it does not require Wi-Fi, mobile data, SMS, or a public API. The website or application being accessed may still require a network connection, and enrollment, synchronization, backup, push approval, or account recovery may have separate connectivity requirements.
A simplified TOTP calculation
time_counter = floor((current_unix_time - T0) / period)
hmac_result = HMAC(shared_secret, time_counter)
code = truncate(hmac_result) modulo 10^digitsThis simplified outline leaves out byte encoding and dynamic truncation details, but it explains why the same secret, time step, algorithm, and digit count produce the same code. RFC 6238 permits HMAC-SHA-1, HMAC-SHA-256, or HMAC-SHA-512. Implementations must agree on every parameter.
Why does the device clock matter?
TOTP replaces a stored event counter with a time-derived counter. If a phone, workstation, container host, or authentication server has the wrong time, the two sides can calculate codes for different time windows. A small verification window may tolerate limited drift, but it cannot correct a clock that is substantially wrong.
Use automatic time synchronization on devices and reliable NTP on self-hosted servers. Check the clock first when every newly generated code is rejected. Google notes that current Google Authenticator versions use the operating system's time setting, while Bitwarden also identifies an out-of-step system clock as a common cause of invalid TOTP codes.
Offline TOTP is different from push approval
| Method | How it works | Internet required by authenticator? |
|---|---|---|
| TOTP code | Generated from a stored secret and current time | No, after setup |
| Push approval | A service sends a sign-in request to the authenticator | Normally yes |
| SMS code | A carrier delivers a code generated by the service | Requires cellular delivery |
| Recovery code | A previously generated single-use code is entered | Generation or retrieval varies |
| Passkey or security key | Public-key authentication is bound to the requesting service | The authentication operation may be local, but the service session still needs connectivity |
Microsoft's official Authenticator FAQ makes this distinction directly: verification codes do not need internet or phone service, while sign-in notifications and responses do require connectivity. This is why the same app can provide an offline TOTP code but fail to display a push approval when a device is disconnected.
Popular authenticator apps
| Authenticator | Platforms and model | Notable consideration |
|---|---|---|
| Google Authenticator | Android and iOS; codes can remain on-device or synchronize through a Google Account | Offline code generation is supported; decide whether account synchronization matches the desired recovery model |
| Microsoft Authenticator | Android and iOS; TOTP codes plus Microsoft sign-in capabilities | TOTP works offline, but push notifications and approval responses require internet |
| Aegis Authenticator | Android; open-source TOTP and HOTP application with an encrypted vault | Supports password or biometric vault unlock, encrypted exports, and backups controlled by the user |
| 2FAS Auth | Android and iOS; local-first, open-source authenticator | Designed to work offline and without requiring an account; review backup choices before relying on one device |
| Bitwarden Authenticator | Android and iOS; standalone TOTP app with local codes and optional Bitwarden synchronization | Can be kept separate from the password vault or connected for convenience, depending on the chosen trust boundary |
| Ente Auth | Mobile, desktop, and web; open-source with optional end-to-end encrypted synchronization | Offers account-free offline mode, but offline entries require a deliberate encrypted backup or export for recovery |
| SecurityBox Authenticator | Self-hosted responsive web application for individual SecurityBox users | Does not require public internet, but the browser must reach the organization's SecurityBox server |
No authenticator is universally best. Select one based on supported platforms, secret-storage design, backup and export controls, account recovery, open-source requirements, enterprise administration, and whether authentication secrets should remain on a separate device.
Device-only, synchronized, integrated, or self-hosted?
Device-only storage
A device-only authenticator keeps secrets on one phone or computer. This minimizes remote dependencies and works offline, but device loss can become account loss unless recovery codes or encrypted exports are stored safely.
Synchronized authenticators
Synchronization makes replacement devices and multi-device use easier. It also introduces a synchronization account and service into the trust model. Confirm that secrets are encrypted appropriately and protect the sync account with strong, independent authentication.
Authenticator inside a password manager
Keeping passwords and TOTP secrets in one vault is convenient and can improve usability. It also places both factors within one software and account boundary. Some users deliberately separate them; others prioritize reliable access and managed recovery. The right choice depends on the threat model.
Self-hosted authenticator service
A self-hosted service centralizes storage, access control, backups, and web availability under the organization's administration. It avoids dependence on public internet when used on a private network, but the service, database, master key, HTTPS endpoint, and backups become critical infrastructure.
SecurityBox Authenticator is added in the new release
The new SecurityBox release adds a private Authenticator workspace for every signed-in user. It stores and generates TOTP codes for services that support standard authenticator-app setup, providing a self-hosted alternative to a separate mobile authenticator.
- Private authenticator entries scoped to the SecurityBox user who created them
- AES-GCM encrypted account names, setup keys, and TOTP settings
- Six-digit and eight-digit verification codes
- SHA-1, SHA-256, and SHA-512 TOTP algorithms
- Periods from 15 to 120 seconds
- Automatic refresh with a visible countdown
- Codes hidden by default with click-to-reveal and clipboard copy
- A responsive interface for desktop, tablet, and mobile browsers
Open SecurityBox and select Authenticator from the main page or navigation bar. Each row shows the service, account, hidden code, and remaining time. Selecting the code area reveals the current value, and a copy button becomes available. The value changes automatically at the end of its configured period.
Three ways to add a TOTP account in SecurityBox
1. Scan with the camera
Open Add New, select the Camera tab, permit camera access, and place the service's TOTP QR code inside the scanner frame. SecurityBox uses the browser's native BarcodeDetector when available and includes a local JavaScript QR decoder as a fallback. Camera frames are processed in the browser and are not uploaded.
Browser camera access requires a secure context. It works on localhost; remote hostnames and IP addresses normally require HTTPS. After the browser decodes the QR content, the provisioning payload is sent to the authenticated SecurityBox server for validation and encrypted storage.
2. Read a QR image
Select the QR Image tab and choose a supported image containing the setup QR code. The image itself is decoded locally in the browser and is not uploaded. The decoded TOTP data is then validated by SecurityBox before the encrypted entry is stored.
3. Enter a setup key
Select Setup Key, enter the service and account names, and provide the Base32 secret supplied by the service. A complete otpauth://totp/... URI can also be pasted; SecurityBox reads the issuer, account, and TOTP settings from it.
otpauth://totp/Issuer:Account?secret=BASE32SECRET&issuer=IssuerSecurityBox accepts TOTP provisioning data only. Counter-based HOTP QR codes are rejected.
How SecurityBox protects authenticator entries
Before saving an entry, SecurityBox validates the TOTP URI or setup key on the server. It then encrypts the complete authenticator payload using AES-GCM with a unique random salt, a unique random nonce, user-specific authenticated data, and the configured PasswordVault:MasterKey.
The authenticator_entries table stores encrypted payloads rather than readable setup keys. Queries are scoped to the authenticated owner. Generated codes are returned only to that owner, and responses are marked as non-cacheable.
Operational requirement: keep PasswordVault:MasterKey secret, stable, and backed up through a protected recovery process. Changing or losing it prevents existing authenticator entries from being decrypted. Replace the development key before production deployment, provide SecurityBox through HTTPS, restrict database and host access, and test database-plus-key recovery together.
Does SecurityBox Authenticator work offline?
SecurityBox Authenticator can work when the public internet is unavailable if the browser can still reach the self-hosted SecurityBox server over the local network, VPN, or another private route. The server decrypts the owner's entry and generates the requested code, so a browser with no route to SecurityBox cannot display a code.
This differs from a phone authenticator that stores the secret and calculates the TOTP entirely on the phone. It also means the SecurityBox host clock must be accurate. Use a reliable internal or external time source appropriate to the deployment.
TOTP security limitations and best practices
- Protect the setup secret. Anyone who copies a TOTP secret can generate the same future codes.
- Do not share live codes. Support agents should not ask for an authenticator code. A current code can be relayed immediately by a phishing site.
- Use HTTPS. Protect enrollment data, sessions, and submitted verification codes in transit.
- Keep recovery codes separately. Do not make a single phone, server, vault, or synchronization account the only recovery path.
- Back up deliberately. Encrypt authenticator exports and protect their passwords. A plaintext export contains the long-term secrets.
- Secure time. Monitor clock synchronization on self-hosted verifiers and authenticator servers.
- Prefer phishing-resistant methods where required. NIST states that manually entered OTP outputs are not phishing-resistant because an impostor verifier can relay them. Passkeys, WebAuthn, or appropriate security keys should be considered for higher-risk accounts.
TOTP remains useful because it adds a possession-based step, works across many services, and does not depend on SMS delivery. It should be one layer in a broader account-security and recovery design.
Run the new SecurityBox Authenticator
Start or update the SecurityBox deployment using the image and configuration appropriate to your environment. The authenticator table is created automatically when SecurityBox starts.
docker pull ssiroos/securitybox
docker compose up -dFor local Docker-host access, open http://localhost:5285. Configure HTTPS before using camera access from a remote hostname or IP address.
Explore SecurityBox features and deployment information or open the official SecurityBox image on Docker Hub.
Frequently asked questions
Can an authenticator app generate codes in airplane mode?
Yes, a locally stored TOTP entry can generate codes in airplane mode because it uses the saved secret and device time. Synchronization, push approvals, backups, enrollment, and the login service may still require connectivity.
Why does the website know the same authenticator code?
The website's verifier and authenticator were provisioned with corresponding copies of the same secret and parameters. They independently calculate the expected value for the current time window.
Why is my authenticator code always invalid?
Check the device and server clocks, time zone configuration, selected account, algorithm, digit count, and period. Re-enroll the authenticator if the stored secret no longer matches the service.
Does a TOTP QR code contain the secret?
Usually yes. A provisioning QR commonly encodes an otpauth:// URI containing the Base32 secret and account settings. Treat setup QR codes and screenshots as sensitive credentials.
Are TOTP codes phishing-resistant?
No. A user can be tricked into entering a current TOTP code into an impostor site that relays it to the real service. Use passkeys, WebAuthn, or security keys when phishing resistance is required.
Can SecurityBox generate codes without public internet?
Yes, when the user can reach the self-hosted SecurityBox server over a local or private network. The browser cannot generate SecurityBox codes by itself when the server is unreachable.
Who can view a SecurityBox Authenticator entry?
Authenticator entries are scoped to the signed-in user who created them. Other SecurityBox users cannot list those entries or request their generated codes through the application.
What happens if the SecurityBox master key changes?
Existing authenticator entries cannot be decrypted without the original PasswordVault:MasterKey. Keep it stable and back it up separately from the database through a protected recovery process.
Offline codes depend on shared secrets and accurate time
TOTP authenticators do not need a live connection to a code provider. They need protected secret material, matching algorithm settings, and an accurate clock. Mobile apps keep those inputs on the device; synchronized apps add a protected recovery service; and SecurityBox provides a self-hosted, per-user server model. Understanding that storage boundary is the key to choosing and operating an authenticator safely.