If there is one question you can expect on every questionnaire, it is this one. For buyers, MFA is the quickest litmus test: whoever does not have this switched on usually does not have the rest in order either.
What does MFA need to be on?
On everything reachable from the internet, starting with email. A compromised mailbox is the key to everything else: password resets, redirecting invoices, working your way through to colleagues. After that: VPN, remote desktop, cloud applications and your suppliers' management portals.
"Required on" is the criterion here, not "available". An environment where MFA is possible but three accounts do not use it fails the audit on precisely those three accounts.
Why do administrators need separate accounts?
An administrator who spends the day mailing and browsing from their admin account hands an attacker the keys to the building with the first successful phishing email. The measure is: an ordinary account for everyday work and a separate admin account for administrative tasks, both with MFA. This costs little and appears on every serious questionnaire.
Does SMS count as a second factor?
SMS is better than nothing, but an authenticator app or a hardware key is stronger; SMS codes can be intercepted through SIM swap fraud. You do not have to migrate in one go: start new accounts on an app and phase out SMS for the accounts with the most access.
What does secure communication have to do with this?
Alongside authentication, part (j) also names secure communication, including communication during a crisis. The practical question: if ransomware takes down your email, how do you then reach your team and your customers? An up-to-date phone list kept offline and an agreed fallback channel are enough, as long as they exist before the incident.
One of our applications cannot do MFA. Now what?
That happens regularly, usually with older industry software. The answer is not "then we do nothing", but closing off the access around it and recording that: make the application reachable only through a connection that sits behind MFA itself, limit the number of accounts to those who genuinely need it, and enforce longer, unique passwords from a password vault.
Add a date on which you will look at it again, or a requirement towards the vendor at the next contract renewal. A questionnaire saying "not possible, this is what we do instead, and this is the plan" reads very differently from an empty box.
What evidence will a customer ask for?
Rarely a screenshot of your settings. What auditors and buyers do ask for: a short description of where MFA is enforced, and something showing that it really is on everywhere. An export from your identity management with the number of accounts with and without MFA is the strongest item, and it takes one action per quarter.
Record the exceptions as well: which accounts have no MFA, why, and what you do instead. An honest exception list makes the rest of your answer more credible. How to gather this kind of evidence without turning it into a project is covered in proving your measures work.
What if an employee loses their phone?
That is the moment MFA falls over in practice, because the pressure to just help quickly is high. It is also exactly where the attack sits: a call to the help desk saying "I lost my phone, can you turn off MFA for a moment" is a well-established way in.
So agree in advance how recovery works: who may register a new factor, how the caller's identity is established, and that MFA is never switched off temporarily but set up again. Backup codes handed to staff when they join, which they keep themselves, take most of the friction out. Put the procedure on paper alongside the rest of your incident arrangements; it is one of the few rules you need at a moment when there is a hurry.
MFA is one of the ten duty of care measures; the other nine come up on the same questionnaire, and the first is usually access control.