Is multiple authentication (MFA) mandatory for an ICT service provider? A straightforward answer does not exist, and that is precisely why this question comes up so often with supervisory authorities, contracting parties and in security questionnaires. The NIS2 Directive explicitly names multi-factor authentication or continuous authentication as an example of a measure that forms part of the duty of care, but does not prescribe on which system, for whom and at what moment this must be applied. That implementation is left to the organisation itself, and this makes the subject more complex than a simple yes or no.
What is clear: once an account provides remote access to a customer's systems, data or infrastructure, supervisory authorities and contracting parties alike expect more than just a password. This applies to your own staff, to subcontractors and to temporary access that is revoked after a project ends. Where that expectation is less stringent is for internal, low-risk access that is not reachable from outside. This is the boundary that this article explores further.
Why MFA appears in almost every questionnaire
As an ICT service provider, you are often the party that logs in remotely for a customer, performs updates or resolves incidents. That access path is precisely what makes an attacker interested: a single stolen password can then grant access to multiple customer environments at once. Contracting parties who themselves fall under the duty of care must assess their suppliers, and multiple authentication on remote access is one of the first things asked about. Those who have no answer to this notice that questionnaires take longer or that a contract is put on hold.
in a few questions see whether your organisation is affected through the supply chain provides a first indication of how heavily such requirements may land on you. For an SME service provider working for multiple contracting parties subject to the duty of care, there is a good chance that the same question comes up repeatedly, only worded slightly differently.
Where MFA is structurally expected
Three access paths come up most often in practice as places where multiple authentication should be in place. First, remote management: every connection through which an administrator can reach a system from outside the network, including VPN access and remote desktop connections. Second, access to customer systems: accounts specifically created to log into a contracting party, especially when that access grants administrative rights. Third, subcontractors and external parties performing work on your behalf at a customer; their access falls under the same expectation, even though the subcontractor itself does not directly appear in the questionnaire.
With these three categories, the pattern is always the same: the further the access stands from your own, physically protected network, the stronger the expectation that a second verification step is present.
Where the discussion remains open
Within your own office network, for an account that operates only locally and without external connection, the necessity of MFA is less clear-cut. This does not mean it is unimportant, but rather that the assessment there concerns risk and proportionality more than a hard rule. The same nuance applies to shared functional accounts not linked to an individual: these call for a different solution than a second step per person, for instance by abolishing the account in favour of personal login credentials.
This is the category where organisations most often struggle when a security questionnaire arrives: not the clear-cut cases, but the systems that fall somewhere in between. read through the explanation per situation helps you see which category a specific system is likely to fall into, without having to read the entire directive first.
What this means for your own file
For the duty of care, it is not only a question of whether MFA is enabled, but also whether that is demonstrable: who made the decision, on which systems is it turned on, and what is the status of the systems where it is still missing. This is precisely the kind of documentation that a living file requires instead of a one-off action. If in doubt about how strictly a specific access should be assessed, the supervisor or a lawyer remains the right party to assess that for your situation; this explanation is intended to sharpen the question, not to replace it.
Curious how this topic fits into your own file? read where the information on secria.eu comes from shows how we maintain sources, and the free NIS2 check gives you an initial picture of where you stand in just a few minutes.