Multi-Factor Authentication Best Practices
This guide is part of the documentation available in SecBoard. It explains what multi-factor authentication (MFA) is, why it matters, and how to apply MFA best practices. In SecBoard, user accounts and access are managed in the SecBoard Cabinet (users and groups). Enforcing MFA for those accounts—where possible at your identity provider or application level—reduces the risk of account takeover and supports your security programme.
What is Multi-Factor Authentication?
Multi-factor authentication (MFA), also called two-factor authentication (2FA) when two factors are used, requires users to prove identity with more than one type of credential. Typically this is “something you know” (password), plus “something you have” (phone, token) or “something you are” (biometric). Even if a password is stolen or phished, an attacker without the second factor cannot complete login. MFA is one of the most effective controls to protect user accounts and is recommended by standards such as NIST CSF (Protect), ISO 27001 (A.5.16), and PCI DSS.
In SecBoard, users and groups are managed in the Cabinet. SecBoard does not implement MFA itself; MFA is usually enabled in your identity provider (e.g. Active Directory, Azure AD, Okta) or in the application layer. This guide summarises best practices so you can configure and operate MFA in line with your policy and with what SecBoard tracks (users, groups, permissions).
Types of authentication factors
MFA relies on different factor types. Using at least two distinct types (e.g. password + authenticator app) is stronger than two of the same type (e.g. two passwords).
MFA methods: strengths and considerations
Not all second factors are equally strong. Phishing-resistant methods (FIDO2/WebAuthn, hardware tokens) are preferred for high-privilege and high-risk access.
| Method | Pros | Considerations |
|---|---|---|
| SMS / voice | Widely available, no extra device for many users. | Vulnerable to SIM swap and interception; NIST and others recommend avoiding for new deployments. Use only if stronger options are not feasible. |
| TOTP (authenticator app) | Works offline, no carrier dependency, common and user-friendly. | Can be phished if user enters code on a fake site. Prefer phishing-resistant methods for admins and sensitive systems. |
| Hardware tokens (e.g. YubiKey) | Phishing-resistant when used with FIDO/WebAuthn, no battery for FIDO2. | Cost and distribution; users must have token. Ideal for privileged and high-risk accounts. |
| FIDO2 / WebAuthn | Phishing-resistant, can use platform (device) or roaming (e.g. USB) authenticators. | Requires supporting IdP and applications. Best choice for new deployments where supported. |
| Push approval (app) | Good user experience, no code entry. | Can be vulnerable to fatigue attacks; ensure timeout and clear context. Prefer with step-up for sensitive actions. |
MFA best practices
Apply these practices when designing and operating MFA for your organisation:
- Enforce MFA for all users, and prioritise privileged accounts. Admin and service accounts are high-value targets; require MFA (and preferably phishing-resistant MFA) for anyone with elevated access. In SecBoard, users in groups with broad permissions should be covered by your organisation’s MFA policy.
- Prefer phishing-resistant methods where possible. FIDO2/WebAuthn and hardware tokens resist real-time phishing. Use them for critical systems and privileged access; use TOTP or other methods for general users if needed.
- Avoid SMS as the sole second factor for new deployments. Use TOTP, push, or FIDO2 instead. If SMS is unavoidable, pair it with other controls and monitor for SIM swap and abuse.
- Use recovery codes and secure account recovery. Provide one-time recovery codes and store them securely. Recovery and “remember this device” options must not weaken security (e.g. limit duration and scope).
- Combine MFA with other controls. Strong passwords, conditional access (e.g. by network or device), and session timeouts complement MFA. In SecBoard, access is also controlled by groups and company assignment; keep user lists and group membership up to date.
- Train users and handle exceptions. Explain why MFA is required and how to use it safely (e.g. never approve unexpected prompts). Define a clear process for lost devices or locked-out users without bypassing MFA insecurely.
MFA and SecBoard
SecBoard manages users and groups in the Cabinet and controls access to modules (e.g. incidents, assets, compliance) via permissions and company assignment. MFA is not built into SecBoard; it is implemented at your identity provider or application layer. To align MFA with SecBoard:
| Area | Role |
|---|---|
| Cabinet users and groups | Keep user accounts and group membership accurate. Enforce MFA for all SecBoard users at your IdP or login layer; require stronger MFA (e.g. FIDO2) for users in admin or sensitive groups. |
| Access control | Use SecBoard permissions and company assignment to limit who sees which data. MFA protects the account; permissions define what that account can do inside SecBoard. |
| Framework Compliance | If you use NIST CSF, ISO 27001, or similar, document MFA-related controls (e.g. access control, authentication) and attach evidence. SecBoard Framework Compliance helps you track and demonstrate that MFA is in place and reviewed. |
| Incidents and awareness | Account compromise and phishing can be recorded in the SecBoard Incident Register. Use incidents and training (e.g. phishing simulations if you use SecBoard Gophish) to reinforce the importance of MFA and safe behaviour. |
When you enable or strengthen MFA, keep SecBoard user and group data in sync with your IdP so that access reviews and audits remain accurate.
Getting started
- Define an MFA policy: who must use MFA, which methods are allowed, and any exceptions. Prefer phishing-resistant methods for privileged and high-risk access.
- Enable MFA at your identity provider or application for all users who access SecBoard and other business systems. Prioritise admin and powerful accounts.
- Maintain Cabinet users and groups in SecBoard so permissions reflect current roles. Use Framework Compliance to document and evidence MFA-related controls if required by your framework.
- Train users, provide recovery options, and monitor for suspicious sign-ins and account issues. Use the Incident Register for any confirmed compromises.
MFA and SecBoard Cabinet
This guide is part of the documentation available in SecBoard. User accounts and access are managed in the SecBoard Cabinet (users and groups). Enforce multi-factor authentication at your identity provider or application level for all users, especially those with elevated permissions. Use SecBoard Framework Compliance to document MFA-related controls and evidence, and the SecBoard Incident Register to record account or phishing-related incidents. The "Guide" button on the Cabinet Users page opens this text.
Applying MFA best practices—including phishing-resistant methods for privileged access—reduces the risk of account takeover and supports your overall security and compliance posture.
Frequently asked questions
What is multi-factor authentication? — MFA (or 2FA) requires more than one type of credential to sign in, for example a password plus a code from an app or a hardware token. It greatly reduces the risk of account takeover when passwords are stolen or phished.
Which MFA method is best? — For high-privilege and high-risk access, prefer phishing-resistant methods: FIDO2/WebAuthn or hardware tokens. For general users, TOTP (authenticator app) or push approval are good options. Avoid SMS as the sole second factor where possible.
Does SecBoard provide MFA? — SecBoard does not implement MFA itself. Enable MFA in your identity provider (e.g. Azure AD, Okta) or in the application that users use to sign in. SecBoard Cabinet manages users and groups; keep MFA enforced for those accounts at the IdP or login layer.
How do I document MFA for compliance? — Use SecBoard Framework Compliance to create controls related to authentication and access (e.g. under NIST Protect or ISO 27001 A.5.16). Attach evidence (policy, IdP configuration, user coverage) and assign owners so you can demonstrate MFA is in place and reviewed.
What if a user loses their MFA device? — Define a secure account recovery process: for example, one-time recovery codes, verified identity check, or help desk procedure. Avoid permanently disabling MFA or using weak fallbacks. Document the process and train support staff.