What is multi-factor authentication (MFA)?
Multi-factor authentication verifies an identity with at least two pieces of proof from different categories, such as a password and a security key. Two-factor authentication (2FA) is the case with exactly two. A password and a security question are both knowledge and therefore not MFA.
The legal anchor is § 30(2) sentence 2 no. 10 of the BSI Act (BSIG): essential and important entities need "solutions for multi-factor authentication or continuous authentication". The provision transposes Article 21(2)(j) of Directive (EU) 2022/2555. Outside that group, MFA can follow from contracts, industry standards such as PCI DSS or the risk assessment under Article 32 GDPR.
| Category | Examples | Weak point |
|---|---|---|
| Knowledge | password, PIN, recovery code | shared or harvested on fake sign-in pages |
| Possession | security key, smart card, authenticator app on a registered device | loss of the device, takeover of the mobile number |
| Inherence | fingerprint, facial recognition | cannot be changed; may be subject to works council co-determination in Germany |
Does a passkey count as MFA?
A passkey is a sign-in key based on the FIDO Alliance standards and bound to a specific service (BSI on passkeys, in German). Whether it counts as MFA depends on one detail: does the service require the user to unlock the key with a PIN or biometric? Under Appendix B of NIST SP 800-63B-4, the "User Verified" flag shows whether an authenticator counts as multi-factor; without verification it counts as single-factor.
Tapping a security key only proves presence ("User Present"), not a PIN or biometric. So check in the service's configuration whether it requires user verification.
Which methods are phishing-resistant?
| Method | Phishing-resistant | Limit |
|---|---|---|
| password and SMS code | no | the code can be relayed; the mobile number can be taken over |
| password and app code | no | a fake page relays the code at once |
| password and push approval, including number matching | no | reduces accidental approvals but does not bind the sign-in to the genuine service |
| passkey or security key with user verification | yes | protection still depends on enrolment and recovery |
Under section 3.2.5 of NIST SP 800-63B-4, phishing resistance requires cryptographic authentication; methods where a code is typed in, such as SMS or app codes, do not count as phishing-resistant. They still protect against reused passwords. The BSI advises against receiving the code on the same device used for signing in (in German). For administrator accounts and remote access, a phishing-resistant method is the stronger choice.
Check the routes around sign-in
Fictional example: administrators sign in with passkeys. The service desk, however, replaces a lost factor once the caller gives a name and staff number. The enrolment report shows "MFA active"; it does not show the gap.
Check these four routes with a test account or a tabletop exercise:
| Route | Question | Passes if | Evidence |
|---|---|---|---|
| normal sign-in | Does the application enforce the intended method for this account? | a sign-in without the intended method is refused | policy and matching sign-in record |
| device loss | What identity check applies before a new factor is registered? | a new factor is registered only after a check that a caller cannot pass with name and staff number alone | recovery procedure and test result |
| fallback method | Can a weaker method bypass the intended one? | no weaker method is allowed for the account, except in approved exceptions | permitted methods and exception decisions |
| after recovery | Are old factors and sessions invalidated and is the user notified? | old factors and sessions are invalid and the user has been notified | revocation and notification logs |
An emergency access route can be intentional. It needs an owner, its own protection and monitoring, and it is tested.
Enrolled does not mean enforced
That staff have registered a second factor does not prove that every application requires it. Check covered accounts, policy exceptions, legacy sign-in protocols without MFA and the actual sign-ins.
Service accounts for automated processes cannot be protected interactively with MFA; they need their own controls such as restricted rights. For staff without a company phone, plan hardware tokens or smart cards. And MFA does not replace access control: being allowed to sign in does not mean being allowed to do everything. The guide to implementing an ISMS shows where MFA sits in the ISMS.
MFA evidence per asset in Rizzqo
In Rizzqo, the authentication requirements of the held catalogues, such as ISO/IEC 27002, appear on every supporting asset with a sign-in: VPN access, the email service or a cloud console. The asset owner answers whether MFA is enforced there and attaches the identity provider configuration as evidence. The answer is finalised with name and timestamp.
For a legacy system without a second factor, the risk owner assesses the risk with likelihood as a percentage and impact in euros. Compensating measures run as tasks that synchronise both ways with Jira.