Prepare a safe account-level change
Enable two-factor authentication for your own panel login and prove a fresh sign-in works while the current session remains open.
Start with a panel login that belongs to you and a recovery method you can retain securely. Confirm that you can sign in with the current password and that a supported authenticator app is available on a device you control. If your team shares one panel login, ask the account owner to define named access and recovery responsibility before changing its sign-in method. Two-step authentication for the hosting panel is separate from two-factor authentication for the WHMCS client area; enabling one does not enable the other.
DirectAdmin describes its user menu as Two-Step Authentication, reachable from the password icon or the account password area. Panel skin, permissions and provider configuration can change what appears. If the option is absent, ask support whether it is enabled for your account; do not try to alter server-wide settings.
Pair the authenticator and save recovery codes
Open Two-Step Authentication while the current session remains active. Follow the panel’s secret or QR-code flow to add the account to your authenticator app, enter the temporary code requested by DirectAdmin and enable the feature. Check the account label in the app so you can distinguish this panel from any other service. Do not send the QR code, secret or current code in a ticket; anyone with the secret may be able to generate future codes.
If the panel offers one-time scratch codes, create them and store them securely outside the device that holds the authenticator. DirectAdmin says each scratch code works once and is removed after use. Record who is authorised to retrieve them and how your team will regain access if the device is lost. Avoid storing codes in a publicly served directory or an unprotected note.
Test a second sign-in before closing the first
Open a separate private browser session and sign in with the same named account. Confirm that DirectAdmin asks for the second code and that a fresh authenticator code succeeds. Keep the original session open until this works and the recovery codes are safely held. A code rejection may reflect a mistyped value or time mismatch; DirectAdmin notes that its Test Code feedback can indicate a code for a different time. Check the device clock, then use the supported recovery or contact support if the new login remains unavailable.
For example, sign in from a fresh private window with the authenticator while the old session is open. Verify a recovery code is stored safely, but do not consume or share one merely to document setup.
Keep access controlled after a device change
When you replace a phone, follow the panel’s supported re-enrolment procedure while you still have an authorised login or recovery code. Test the replacement in a new session, then retire the old authenticator entry and any exposed recovery material according to your account policy. If you are already locked out, use the verified Novasean account recovery route. Support may need to establish account ownership before changing authentication; a scratch code is preferable when available.
Frequently asked questions
Does this protect my email or client-area login too? No. Those are separate identities and must be checked individually.
Can I skip scratch codes because I have a phone backup? A device backup may not restore the authenticator entry. Where DirectAdmin offers scratch codes, keep them as a separate recovery route.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.