Passwords do not fail because of their length; they fail because they are transferable. Anyone who knows one can use it. Multi-factor authentication breaks that by requiring a second piece of proof of a different kind. It is therefore the measure with the best ratio of effort to effect against the most common routes of attack: phishing, reused credentials and automated guessing.
The three categories
| Category | Examples | Typical weakness |
|---|---|---|
| Knowledge | password, PIN, recovery code | gets shared, reused, phished |
| Possession | security key, smart card, authenticator app on a registered device, one-time code | loss of the device, takeover of the mobile number |
| Inherence | fingerprint, face recognition | not changeable, tied to the device, subject to employee co-determination |
What matters is the combination of different categories. A password and a security question are two knowledge factors and barely raise the level of protection, because both can be asked for through the same fake sign-in page.
Not every kind of MFA protects equally well
The difference lies in whether a method resists relaying by an attacker sitting in the middle. One-time codes, whether generated in an app or delivered by message, can be typed into a fake page by the user, and the attacker replays them in real time. Methods built on the FIDO2 and WebAuthn standards, which include passkeys, bind the sign-in cryptographically to the domain being called; a fake page therefore gets no usable answer.
That does not make one-time codes worthless. They reliably prevent the mass reuse of stolen passwords. For accounts with far-reaching rights, though, a phishing-resistant method is markedly stronger protection. The choice belongs in the risk assessment, not in a blanket rule.
MFA fatigue
One widespread attack does not target the technology but the person: with stolen credentials, the attacker triggers confirmation prompts repeatedly until one of them is approved. The countermeasures are methods that use number matching rather than simple approval, a limit on the number of prompts, display of location and application, and a low-friction way to report an unexpected prompt.
Where MFA should apply first
- Remote access from outside: VPN, terminal services, remote maintenance by service providers
- Administrative accounts in every system
- Email accounts, the recovery route for almost every other account
- Cloud services holding company data
- Applications handling data with particular protection needs
Regulatory context
There is no general statutory duty in Germany for every company to introduce MFA. For besonders wichtige and wichtige Einrichtungen under the German BSI Act, the catalogue in § 30(2) BSIG is a statutory minimum. No. 10, identical in wording to Article 21(2)(j) of Directive (EU) 2022/2555, calls there for solutions providing multi-factor authentication or continuous authentication. Which of the two an entity uses is its own decision; going without strong authentication altogether is not one of the options. Art. 32 GDPR requires a level of protection appropriate to the risk without prescribing methods. Where personal data is accessed remotely, the absence of strong authentication is hard to justify.
Operational questions to settle before rollout
- Recovery: how does someone who has lost their second factor regain access? That route is the most likely point of attack and has to be secured in its own right.
- Fallback: a second registered factor per user rather than a list of exemptions.
- Staff without a company phone: plan for hardware tokens or smart cards rather than assuming personal devices will be used.
- Co-determination and data protection: biometric methods and location display have to be agreed in advance.
- Service accounts: they usually cannot be protected by MFA and need other measures.