Multiple verification, often called MFA, is a second check on top of a password: a code from an app, an SMS or a physical key. Whether this is mandatory for a software company cannot be answered with a simple yes or no, because the NIS2 Directive does not prescribe a specific technique. Article 21 does require organisations falling under the duty of care to implement appropriate measures for access control and multiple authentication, and supervisory authorities look at where the risk is greatest.
For a software company, in practice this involves two very different places: the development pipeline that you use yourself, and the software that you deliver to customers. Both require their own assessment, and that assessment is not equally strict everywhere.
Two places where multiple verification plays a role
The first place is internal: the environment in which your developers work. Source code, the development pipeline, cloud consoles and the systems with which you roll out to production. The second place is in the product itself: if the software you build or deliver has a login screen, multiple verification is also a topic there, both for your own users and for your customer's end users. A security questionnaire from a client almost always asks about both, often in separate questions that are worded slightly differently than you would expect.
For access to your development pipeline
The strongest expectation lies here. Who can access the source code, who can deploy to production, and who has administrator rights on the cloud environment form the greatest risk if a password alone is stolen or reused. For these accounts, multiple verification is considered a baseline measure in virtually every security framework, and it is also what supervisory authorities and clients expect first. Version control, the development pipeline itself, and in particular any account with rights to deploy code to production, should in practice without exception be protected by a second step.
This also includes a look at who actually still needs that access. A record that shows per system who may access it and why makes it easier to answer this question in a questionnaire with a concrete answer rather than an assumption. how access control and multiple verification are explained per topic provides a starting point for this.
For the software you deliver
The second level is the software itself. If your product has a login function, the question of whether you offer multiple verification almost always comes back in a security questionnaire, and sometimes even as a contractual requirement. That is a different assessment than for your own development pipeline: here it is not about what you use yourself, but about what you deliver to your customer. A client who is themselves subject to the duty of care must, according to Article 21, also assess their supply chain, and the question of whether your product supports strong authentication is part of that.
The answer does not have to be that it is mandatory everywhere. Often it is sufficient to show that the option exists, that users are encouraged to use it, and that you have a plan to expand it where the risk justifies it.
Where it is less obvious
Not every account or environment requires the same level of security. A test environment without real customer data, an internal documentation system with read-only access, or a standalone tool used occasionally by one developer carry different risks than an account with production access. The duty of care requires measures proportionate to the risks, not a uniform heavy-handed approach everywhere. Supervisors assess this based on proportionality, meaning that a reasoned decision not to apply multi-factor authentication in certain places is just as valid a part of a dossier as the places where it is implemented.
The justification is the key word here. A choice without explanation can quickly look like an omission in a questionnaire, whereas the same choice with a brief reason is often exactly the answer a client is looking for.
What this means for your conversation with a client
A client sending a questionnaire usually does not want to know whether you comply with every detail, but whether you understand where your risks lie and how you manage them deliberately. For multi-factor authentication, that means: being able to show what is implemented in your development environment, what is in the product, and why the rest is configured differently. Those who have documented this per system with a status and an owner do not need to look up the answer again the next time a questionnaire arrives.
Whether and how this plays out for your own organization depends on your role in the supply chain and what your clients specifically ask; when in doubt, consult the text of the directive itself or seek advice from a consultant. To get a first sense of where you stand, a first indication in a few questions provides an initial indication, and an explanation of where the information comes from shows how that indication is reached.
To read more broadly about how this topic relates to the other measures under the duty of care, you will find that in the overview of topics per situation. The quick-scan and the knowledge base are freely accessible, without requiring you to create an account.