# Test the configured OPNsense TOTP input order before switching authentication > Verify the chosen authentication server and its token/password input order before changing the administration authentication backend. - Canonical URL: https://update.dsesecurity.com/updates/test-the-configured-opnsense-totp-input-order-before-switching-authentication/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-30T06:04:51+00:00 - Modified: 2026-10-30T06:05:13+00:00 - Last reviewed by DSE: 2026-10-30 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Verify the chosen authentication server and its token/password input order before changing the administration authentication backend. ## Potentially affected OPNsense deployments using the documented local-plus-TOTP authentication server. ## DSE recommendation Test the intended account and configured input order before switching the administration authentication source. ## Article Bottom line: Confirm the selected authentication server and its token/password order before changing administrative sign-in. Keep a successful tester result separate from verification of the actual administration path. ## Source fact: what the authority says The [OPNsense TOTP guide](https://docs.opnsense.org/manual/how-tos/two_factor.html) directs choosing the configured authentication server in System Access Tester and entering the username there. The default password-field input places the token before the regular password, but the OTP server can be configured for the reverse order. The guide says credentials are validated against Local Database by default and directs changing the Administration authentication source only after testing the token. It warns that possession of the OTP seed or QR code is sufficient to calculate tokens. ## What the source does not establish This article covers the documented local TOTP input and administration-backend transition. It does not establish that every service uses the same authentication source or that a proposed rollout preserves all recovery access. ## Applicability questions - Which account and configured authentication server will the administration path use? - What token/password order is selected on that server? - Who holds the approved recovery access if the transition fails? - How will testers protect the seed, QR code and submitted credentials? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. DSE recommends writing the proposed sign-in sequence as an account, server and input-order record. Have the administrator confirm all three against the intended configuration before testing. Keep actual passwords and generated tokens out of that record; describe their order without copying their values into a ticket. Prepare two proposed cases for the tester: the configured order and a deliberately incorrect order, using an expressly authorized test account. Record the selected server with each observation. Stop on an unexplained result rather than adjusting several authentication settings until a login happens to succeed. Keep the administration-backend change as a separate decision after the tester exercise. Arrange a controlled maintenance window and a separately verified recovery route with the system owner. Name the person who can reverse the change and the condition for doing so before ending the existing administrative session. Treat enrollment material as a credential. Agree how an authorized operator obtains it, where it may be displayed and how temporary copies will be removed. Use redacted configuration evidence for the change record rather than a QR image. Reconcile the account population before extending the configuration to additional administrators. ## Verification and evidence Proposed verification: select the named authentication server in the tester and submit the approved account using its configured order. Retain the timestamp and actual success or failure without the secret input. Compare the deliberately incorrect case separately; investigate unexpected acceptance instead of assuming the order setting was exercised. After an approved backend transition, open a separate administrative sign-in through the intended access path while recovery access remains available. Record that observation independently of the tester result. Have the owner accept the demonstrated path and unresolved exceptions before retiring temporary access or expanding the rollout. ## Official references - [OPNsense — Configure 2FA TOTP & Google Authenticator](https://docs.opnsense.org/manual/how-tos/two_factor.html) — official product documentation; confirm the installed release and configuration. Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: OPNsense — Configure 2FA TOTP & Google Authenticator - Authority: docs.opnsense.org - URL: https://docs.opnsense.org/manual/how-tos/two_factor.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Test the configured OPNsense TOTP input order before switching authentication,” DSE Security, https://update.dsesecurity.com/updates/test-the-configured-opnsense-totp-input-order-before-switching-authentication/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.