Multi-Factor Authentication MFA

A factor is one kind of evidence that the person logging in is the account holder. There are three kinds. Knowledge is something only the user knows, such as a password or a PIN. Possession is something only the user has, such as a phone or a security key. Inherence is something the user is, such as a fingerprint or a face.

The eIDAS Regulation uses the same three categories. It defines strong user authentication as authentication based on at least two factors from different categories (Article 3(51)). Two conditions in that definition explain what makes MFA work. The factors must be independent, so that the breach of one does not compromise the others. The design must protect the confidentiality of the authentication data.

A password followed by a security question is two steps of the same kind: both are knowledge, and both can be phished or guessed in the same way. A password followed by a code from the user's phone combines knowledge with possession.

Most methods add a possession or inherence factor to a password, and they differ in how hard that second factor is to steal or trick. The table lists the common ones with the main weak point of each.

The methods in the first three rows can be defeated by phishing, because the user can be persuaded to hand the proof to someone else. A security key or passkey resists this. The key is tied to the genuine site's address and will not answer a look-alike site. Any second factor is still better than none.

The plainest mention is in NIS2. Article 21(2)(j) lists "the use of multi-factor authentication or continuous authentication solutions" among the cybersecurity risk-management measures that essential and important entities must take, "where appropriate". The duty binds entities in scope of that directive, through national law.

The eIDAS Regulation supplies the definitions. Authentication is an electronic process that enables the confirmation of the electronic identification of a person, or of the origin and integrity of data (Article 3(5)). Strong user authentication is the two-factor form in Article 3(51). Article 5f(2) attaches a consequence. Private businesses that must use strong user authentication for online identification, by law or by contract, must accept the European Digital Identity Wallet when the user asks, no later than 36 months from the entry into force of the wallet's implementing acts. Those acts entered into force on 24 December 2024, which puts the deadline at 24 December 2027. Micro and small enterprises are excepted.

Financial entities have their own rule. DORA requires them to implement policies and protocols for strong authentication mechanisms (Article 9(4)(d)). Payment services law has its own term, strong customer authentication.

The GDPR does not name the technique. Article 32 requires controllers and processors to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. MFA is one common way to meet that duty where personal data can be reached over the internet.

No EU law says so in those words for every firm, but the duty usually arrives by another route. A firm that holds client identity documents, financial records or deal papers is a controller of personal data, and the GDPR security duty applies to it. A firm outside the scope of NIS2 may still be asked for MFA by a client that is inside it, because that client must manage the security of its suppliers.

In practice the question a firm is asked is where MFA is enforced. The accounts that matter first are email, remote access, administrator accounts, and any system where clients upload documents.

Because MFA protects the login, and attackers go around the login. The first route is account recovery. A user who has lost a phone must be able to get back in, so every system has a way to reset or re-issue the second factor. If that reset is granted after a phone call and a few questions with guessable answers, the second factor is only as strong as the phone call.

The second route is the session. After a successful login, the browser holds a token that keeps the user signed in. An attacker who steals that token, for example through a fake login page that relays the whole exchange, does not need the factors at all.

The third is enrolment. If an attacker with a stolen password is allowed to register their own phone as the second factor, MFA then protects the attacker.

The remedy for the first and third is the same. Check who the person is, at the strength used when they joined, before a factor is enrolled or reset.