An employee enters his password on a convincing fake login page. Within minutes, an attacker reads e-mail, downloads quotations and sends a payment request on behalf of the director. This type of incident rarely starts with a technically complicated attack. Often one captured password is enough. The question is that MFA mandatory is therefore not only legal for many SMEs, but especially business-critical.
The short answer: there is no general law in the Netherlands that says that every company is required to use multi-factor authentication for every application. However, in practice, MFA may be necessary to comply with legislation, contractual requirements, insurance conditions or a duty of care for information security. Moreover, for accounts with access to Microsoft 365, cloud applications, financial systems and customer data, it has become one of the most logical basic measures.
Is MFA mandatory under Dutch law?
MFA, or multi-factor authentication, requires additional proof that someone is actually the correct user in addition to a password. This can be an approval in an authenticator app, a security key, a fingerprint or facial recognition. An SMS code is also possible, but offers less protection against, for example, SIM swapping and interception.
The GDPR does not literally mention MFA as a mandatory measure. Article 32 of the GDPR does require organizations to take appropriate technical and organizational measures to secure personal data. What is appropriate depends on the risk. The more sensitive the data, the greater the potential damage in the event of misuse and the more dependent your organization is on digital systems, the more stringent the security requirement.
For a shared calendar with little sensitive information, this consideration is different than for a mailbox with personnel files, financial data and customer contracts. If a password alone does not provide sufficient protection against a real and known risk, MFA may be necessary to meet the GDPR’s obligation to provide appropriate security. The question is therefore not only whether MFA is literally in the law, but whether you can reasonably demonstrate that your access is properly secured without MFA.
Additional frameworks apply to some organisations. Think of companies that fall under the NIS2 regulations and their Dutch implementation, financial institutions with DORA obligations or organizations in healthcare and government. These rules do not always prescribe exactly one authentication method, but they do require demonstrable risk management and appropriate access security. MFA is often an obvious measure, especially for remote access and administrator accounts.
Agreements outside legislation can also be decisive. Customers are increasingly asking for MFA in tenders, vendors are setting requirements for admin portals, and cyber insurers may require MFA for email, remote access, and financial systems. If you do not meet this condition, this may have consequences for coverage or payment after an incident.
When is MFA actually indispensable?
For most SME organizations, MFA is not equally urgent everywhere, but in some places postponement is difficult to defend. Email is at the top. A mailbox is often the key to password resets, quotations, invoices, calendars and internal communication. Anyone who gains access to one account can also commit credible fraud under the name of an employee or director.
Microsoft 365, cloud storage, VPN connections, remote desktop access, accounting software, CRM systems, and administrator accounts also deserve MFA. With these systems, the impact of abuse is significant: downtime, data loss, fraud, reputational damage or a data breach. An even stricter standard applies to administrator accounts. They can change settings, create accounts and disable security. There, MFA is not a luxury, but a minimal threshold.
Also pay attention to exceptions that unnoticeably form a back door. Think of old protocols that only work with username and password, shared accounts, service accounts and devices that are out of sight of central management. If you implement MFA but leave such exceptions unattended, the risk remains. Good security is not just about ticking the box, but about getting a grip on all access routes.
MFA is more than a checkmark in Microsoft 365
Many organizations turn on MFA in Microsoft 365 and then consider the topic complete. That is understandable, but too limited. An attacker could trick users into approving a login request, steal session cookies, or exploit weak recovery procedures. MFA fatigue in particular, where users repeatedly receive notifications until they press approve out of irritation, is a known risk.
The chosen method therefore makes a difference. An authenticator app with caller ID is usually more secure than a simple push notification. For positions with elevated privileges or access to highly sensitive information, phishing-resistant methods, such as FIDO2 security keys or passkeys, may be appropriate. This requires a little more preparation, but significantly reduces the risk of phishing.
At the same time, security must remain workable. A technician who needs to quickly open a work order while on the road has different needs than a finance officer who authorizes payments. The goal is not to impose as many barriers as possible on employees, but to ask for extra verification when the risk justifies it. Location, device status, user role and the type of application can be taken into account.
Introducing MFA without unnecessary unrest
A phased introduction prevents MFA from being experienced as a sudden blockage. Start with insight: what accounts exist, what systems contain critical information, and who has admin privileges? This overview often immediately shows where the greatest risks are and which accounts are no longer needed.
Subsequently, this approach works well for many SMEs:
- First, secure admin accounts and email. This immediately reduces the risk of large-scale abuse and account takeovers.
- Choose an appropriate verification method. Whenever possible, prefer an authenticator app, caller ID, and for critical roles, phishing-resistant authentication.
- Communicate before activation. Briefly explain why MFA is needed, what employees should do and where they can get help if a phone is lost or replaced.
- Expand to other systems in a controlled manner. Test per application whether users, service accounts and links continue to function. Document approved exceptions.
Communication deserves more attention than is often thought. Employees are not a weak link that needs to be corrected, but people who must be able to do their work. A clear explanation of recognizable phishing emails, unexpected MFA notifications and the reporting route in case of doubt makes MFA more effective. Those who understand why a notification appears are less likely to approve an attack.
Arrange the recovery process as well. What happens if an employee loses their phone, if a director abroad has no access or if the authenticator app no longer works? A secure process for identity verification and recovery codes prevents panic and prevents employees from looking for unsafe workarounds. In addition, keep emergency accounts carefully, with strong security and strict control. These accounts are intended for emergencies, not for daily use.
Demonstrability is just as important as technology
If a customer, auditor, insurer or regulator asks questions, you don’t want to have to say that MFA ‘is on in our opinion’. You want to be able to show which systems require MFA, what method is used, what exceptions exist, and who approved them. Combine that with periodic checks on administrator rights, login activity and old accounts.
That doesn’t mean that every SMB needs a heavy compliance program. A clear access policy, an up-to-date overview of critical systems and a fixed control cycle already bring a lot of structure. For organizations without their own IT department , a managed IT partner can help keep those controls from disappearing between daily tickets and projects. Nexer not only looks at the technical attitude, but also at the continuity of the people and processes around it.
The right question is: what risk do you accept?
MFA is not required by law in exactly the same way in all situations. But when it comes to accessing email, cloud environments, remote connections, and systems with sensitive or financial data, it’s now hard to explain why you rely solely on passwords. The costs of implementation are usually limited. The consequences of one account taken over cannot be that at all.
Therefore, do not choose MFA because a checklist requires it, but because your organization must remain accessible, reliable and operational. Start with the accounts where one mistake immediately has major consequences. This makes security concrete: less chance of downtime, more control over access and space to continue growing without digital worries.
