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.
\nThe OPNsense TOTP guide 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.
\nThis 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.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE 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.
\nPrepare 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.
\nKeep 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.
\nTreat 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.
\nProposed 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.
\nAfter 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.
\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: what the authority says\nThe OPNsense TOTP guide 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich account and configured authentication server will the administration path use?\nWhat token/password order is selected on that server?\nWho holds the approved recovery access if the transition fails?\nHow will testers protect the seed, QR code and submitted credentials?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nPrepare 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.\nKeep 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.\nTreat 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.\nVerification and evidence\nProposed 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.\nAfter 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.\nOfficial references\n\nOPNsense — Configure 2FA TOTP & Google Authenticator — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: what the authority says\n\nThe [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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which account and configured authentication server will the administration path use?\n\n- What token/password order is selected on that server?\n\n- Who holds the approved recovery access if the transition fails?\n\n- How will testers protect the seed, QR code and submitted credentials?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\nPrepare 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.\n\nKeep 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.\n\nTreat 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.\n\n## Verification and evidence\n\nProposed 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.\n\nAfter 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.\n\n## Official references\n\n- [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.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/test-the-configured-opnsense-totp-input-order-before-switching-authentication/", "url": "https://update.dsesecurity.com/updates/test-the-configured-opnsense-totp-input-order-before-switching-authentication/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/test-the-configured-opnsense-totp-input-order-before-switching-authentication/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Test the configured OPNsense TOTP input order before switching authentication", "item": "https://update.dsesecurity.com/updates/test-the-configured-opnsense-totp-input-order-before-switching-authentication/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/test-the-configured-opnsense-totp-input-order-before-switching-authentication/#article", "identifier": "https://update.dsesecurity.com/updates/test-the-configured-opnsense-totp-input-order-before-switching-authentication/", "url": "https://update.dsesecurity.com/updates/test-the-configured-opnsense-totp-input-order-before-switching-authentication/", "headline": "Test the configured OPNsense TOTP input order before switching authentication", "description": "Verify the chosen authentication server and its token/password input order before changing the administration authentication backend.", "abstract": "Verify the chosen authentication server and its token/password input order before changing the administration authentication backend.", "articleBody": "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.\nSource fact: what the authority says\nThe OPNsense TOTP guide 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich account and configured authentication server will the administration path use?\nWhat token/password order is selected on that server?\nWho holds the approved recovery access if the transition fails?\nHow will testers protect the seed, QR code and submitted credentials?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nPrepare 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.\nKeep 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.\nTreat 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.\nVerification and evidence\nProposed 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.\nAfter 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.\nOfficial references\n\nOPNsense — Configure 2FA TOTP & Google Authenticator — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-30T06:04:51+00:00", "dateModified": "2026-10-30T06:05:13+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/test-the-configured-opnsense-totp-input-order-before-switching-authentication/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/test-the-configured-opnsense-totp-input-order-before-switching-authentication/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Test the configured OPNsense TOTP input order before switching authentication" }, "articleSection": [ "Cybersecurity", "Microsoft 365 & Identity" ], "keywords": [ "Cybersecurity", "Microsoft 365 & Identity", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "wordCount": 529, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "OPNsense — Configure 2FA TOTP & Google Authenticator", "url": "https://docs.opnsense.org/manual/how-tos/two_factor.html" } } ] } }