Short answer: DashboardFox now includes two-factor authentication (authenticator app, email code, or text message), password security with breached-password screening, account lockout, self-service password reset and one-time sign-in links, and new administrator controls like disabling accounts, forcing a password change, and service accounts for integrations. On DashboardFox Cloud, a secure baseline is already switched on for every site. On self-hosted installs, every new feature starts off, so an upgrade changes nothing until your administrator turns each one on.
Security reviews have become a standard part of buying BI software, and sign-in security is one of the first things reviewers ask about. This release closes the most common gaps: it adds a second factor for every user, stronger password rules, and the account controls an administrator needs to run a secure deployment without filing support tickets.
What's new
- Two-factor authentication by authenticator app, email code, or text message, plus Cisco Duo — set to Off, Optional, or Required.
- Password security following NIST SP 800-63B: 12-character minimum, common-password and breached-password screening.
- Account lockout after five wrong passwords, with an Unlock button for administrators.
- Self-service recovery: "Forgot password?" and "Email me a sign-in link" on the sign-in page.
- Welcome emails that let new users set their own password — you never see or send it.
- Administrator controls: disable an account, force a password change, unlock, and reset a user's two-factor.
- Service accounts so integrations, embedded dashboards, and Server Sync keep signing in automatically.
- A full audit trail of every sign-in security event.
Two-factor authentication
Two-factor adds a second step after the password. Users choose from the methods you allow: an authenticator app such as Google Authenticator, Microsoft Authenticator, Authy, or 1Password; a six-digit email code; or a six-digit text-message code. Cisco Duo push and passcode remain available as well.
Administrators pick one of three modes. Off never prompts anyone. Optional lets users turn on two-factor from My Profile. Required makes every password user enroll before they can reach their dashboards. You can also mark individual users as "Ask to set up two-factor at next sign-in" to roll it out to key people first.
Each user gets 10 single-use backup codes at enrollment, can enroll more than one method with a "Try another way" option at sign-in, and can tell a browser to remember this device for 30 days.
Password security and account lockout
With password security on, every new or changed password must be 12 to 128 characters, can't contain the user's login name, and is checked against a built-in list of common passwords and against known breach data. The breach check uses k-anonymity — only a short fragment of a hash is sent, so the password itself never leaves your site. When a password is refused, the message explains why and suggests a passphrase of four or five random words instead. Existing passwords aren't affected until a user changes theirs.
Account lockout locks an account for five minutes after five wrong passwords. Only wrong-password attempts count — a database or network error never locks anyone out. Administrators see a "Locked until" time on the user and can unlock it at any time.
Self-service recovery and welcome emails
Users can reset a forgotten password or sign in with a one-time email link without contacting you. Links expire after 15 minutes, work once, and are rate limited. If the user has two-factor turned on, they still need their code — a reset link alone can't take over an account. Both options can be turned off if everyone signs in through your own identity system.
When you create a user, you can send a welcome email in your own words with a link to set their own password, valid for 72 hours. You never handle anyone's password.
New administrator controls
- Disable an account — any active session ends immediately and every sign-in method is refused.
- Force a password change at the user's next sign-in, or for everyone whose password is older than a set number of days.
- Unlock a locked account, and reset two-factor for a user who lost their phone.
- Send a setup or reset link to any user, even when self-service reset is turned off.
- Service accounts for anything that signs in automatically — your application, an embedded dashboard, a script, or Server Sync. They skip the second factor so automations keep running, and every skip is recorded in the audit log.
The Users list now shows Disabled, Locked, and Service labels at a glance.
A complete audit trail
Every sign-in security event is written to the audit log: password resets and changes, sign-in links, lockouts and unlocks, two-factor enrollments, challenges, and failures, backup-code use, remembered devices, disabled accounts, and service-account changes. It's the evidence a security reviewer asks for, and it stays in your DashboardFox database.
Cloud vs Self-Hosted: what's different
The features are the same in both. What differs is what's switched on for you and what you set up yourself.
| Topic | DashboardFox Cloud | Self-Hosted |
|---|---|---|
| Starting point | Password security, lockout, password reset, and sign-in links are on for every site; two-factor is available in Optional mode | Every new feature is off after an upgrade, so nothing changes until your administrator turns it on |
| Password rules and lockout | Always on; Enterprise customers can adjust them | Your administrator turns each one on or off |
| Text-message codes | Sent from DashboardFox's number, nothing to set up | Connect your own Twilio account or any SMS gateway with an HTTP API |
| Cisco Duo, your own SMS provider, header-based SSO | Scale and Enterprise | Available to configure on your install |
| Email for codes and links | Works out of the box | Uses your SMTP server and the Public URL you set |
| Breached-password screening | Always available | Needs outbound internet; offline servers still get the common-password check |
A few self-hosted notes. Air-gapped installs can use everything except the breach check — authenticator-app codes need nothing external at all. If you run DashboardFox on more than one server, lockout attempts are counted per server and clear on restart. And because email links are built from the Public URL setting, set it to the address your users actually visit before turning on password reset.
Getting started
On DashboardFox Cloud, open Settings → Server Settings → Security Settings to confirm the defaults, write your welcome email, and decide whether to make two-factor Required. The Login security lesson in the Academy walks through it in about eight minutes.
On self-hosted, upgrade to the latest release, then follow the recommended order: set the Public URL, turn on password reset, set two-factor to Optional, mark integration accounts as service accounts, pilot with your administrators, then switch to Required. Make sure SMTP is configured first — reset links, welcome emails, and email codes all depend on it.
If you embed DashboardFox in your own application, check how your users sign in before you make two-factor Required. An embedded sign-in for a user who must enroll or enter a code will stop at that step, so use Optional mode, a service account, or header-based SSO for embedded users.
What's next
Native SAML 2.0 and OpenID Connect sign-in are in development. Until then, session-token SSO through the DoLogin API works on every plan, and header-based SSO is available on Scale and Enterprise and on self-hosted installs. For the full picture, see our security overview and the security review kit, or read the help guides on two-factor authentication, password security, and Cloud security defaults.
Frequently asked questions
Does DashboardFox support two-factor authentication?
Yes. Every DashboardFox plan includes two-factor authentication by authenticator app, email code, or text message. Administrators set it to Off, Optional, or Required, and each user gets 10 backup codes and can remember a trusted browser for 30 days. Cisco Duo is also supported — on Scale and Enterprise in DashboardFox Cloud, and on self-hosted installs.
Is two-factor authentication on by default?
On DashboardFox Cloud, two-factor authentication is available to every user in Optional mode, and administrators can make it Required. On self-hosted installs, every new security feature is off after an upgrade so nothing changes until an administrator turns it on.
What are DashboardFox's password rules?
When password security is on, passwords must be 12 to 128 characters, can't contain the user's login name, and are checked against a list of common passwords and against known breaches. The breach check uses k-anonymity, so the password itself is never sent anywhere. On DashboardFox Cloud, password security is always on; Enterprise customers can adjust it.
Does the breached-password check work on an air-gapped server?
The breach check needs to reach the breach-data service over the internet. If it can't, the password is allowed and a warning is written to the log; the built-in common-password list still applies. Everything else, including authenticator-app two-factor, works without internet access.
Do I need my own SMS provider for text-message codes?
Not on DashboardFox Cloud — text messages are sent from DashboardFox's number with nothing to set up. Scale and Enterprise customers can use their own Twilio account or SMS gateway instead. On self-hosted installs, you connect your own Twilio account or any SMS gateway with an HTTP API.
Does DashboardFox support SAML or OIDC single sign-on?
Native SAML 2.0 and OpenID Connect sign-in are in development. Today, DashboardFox supports session-token single sign-on through the DoLogin API on every plan, and header-based SSO on Scale and Enterprise in the cloud and on self-hosted installs.
