Verify global and individual TrueNAS 2FA state together

Bottom line: Keep the global setting and each user’s enrollment state in separate columns. Decide what the organization requires, then verify the actual login behavior rather than treating one enabled toggle as the full account-control result.

Source fact: what the authority says

The TrueNAS global 2FA guide requires correct system time for its time-based authenticator codes. Users with individual 2FA configured are not prompted for codes until global 2FA is enabled. When global 2FA is enabled, users without individual configuration are prompted on their next login, but setup is optional and can be skipped without preventing access. The documented SSH login branch separately requires enabling two-factor authentication for SSH, enabling the user’s SSH password login and starting the SSH service.

What the source does not establish

This article describes the versioned configuration branches, not a guarantee of mandatory enrollment for every account. It does not approve enabling SSH or password login where those features are outside the organization’s access policy.

Applicability questions

• Which administrator and ordinary-user accounts are in scope?
• What global and individual 2FA state does each account actually have?
• Does policy permit skipped setup, or is another enforcement decision required?
• Is SSH needed at all, and what approved recovery route remains available?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends an account-state matrix with global activation, individual enrollment and required login channels recorded separately. Compare the requirement with the guide’s skip behavior before announcing that all users have completed enrollment. Keep an unresolved unenrolled account visible to the access owner.

Prepare proposed cases for an enrolled user and an authorized test user without individual setup. Record the expected setup prompt and what policy requires if the user skips it. Do not use a production administrator’s access as an experiment in losing the only recovery route.

Review system time and the protected authenticator-recovery arrangements before the attended change. Ask another authorized operator to follow the recovery procedure without exposing shared secrets or capturing authenticator codes in ordinary evidence.

Leave SSH disabled where it is not required by the approved design. If the SSH branch is needed, have the access owner separately approve its prerequisites and test population. Avoid broadening login channels solely to demonstrate that the documentation contains that workflow.

Verification and evidence

Proposed verification: test the enrolled and unenrolled cases through the intended web login flow, recording prompts and outcomes without saving passwords or codes. Compare the observations with the account-state matrix and explicitly note any permitted skip. Investigate a global-state mismatch before extending the change.

Where expressly approved, test the SSH branch separately with the named account and current service settings. Verify the recovery route within its authorized scope and retain only sanitized results. Treat web enrollment, SSH login and policy acceptance as separate observations requiring their own sign-off.

Official references

• TrueNAS — Managing Global 2FA (Two-Factor Authentication) — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.