Multi-Factor Authentication (MFA)
Multi-factor authentication (MFA) is a login method that verifies a user's identity using at least two independent factors from different categories (knowledge, possession, inherence).
Multi-factor authentication (MFA) is a login method in which a user proves their identity not just with a password, but additionally with at least one further, independent proof. Only when two or more factors from different categories are correctly provided does the system grant access. The goal is that a stolen or guessed password alone is no longer enough to take over an account.
The factors come from three categories: knowledge (something only the user knows, e.g. a password or PIN), possession (something only the user has, e.g. a smartphone, hardware token or smart card) and inherence (something the user is, e.g. a fingerprint or face scan). When exactly two factors are required, this is called two-factor authentication (2FA), the most common special case of MFA.
At a glance
- At least two independent factors from different categories: knowledge, possession, inherence.
- 2FA is the best-known special case of MFA (exactly two factors).
- Effectively protects against phishing, credential stuffing and password leaks.
- Factors must be independent: two passwords do not constitute MFA.
- Increasingly standard for ERP access and in some cases required by regulation.
How does multi-factor authentication (MFA) work?
At login, the user first enters their username and password as usual (knowledge factor). The system then requests a second proof from a different category before releasing the session. Only when both factors are correct is authentication complete.
The independence of the factors is crucial: they must come from different categories so that an attacker cannot capture both at once via a single attack path. Two passwords, or a password plus a security question, are therefore not genuine MFA, because both belong to the knowledge category.
In case the second factor is lost, sound methods provide fallback options: single-use recovery codes, a registered backup device or a defined process via IT administration. Without such provisions, a lost or reset smartphone can lock a user out of their own account. Secure recovery is therefore an integral part of a well-designed MFA rollout and must not itself become a weak point.
Common second factors
Time-based one-time passwords (TOTP) from authenticator apps such as Google Authenticator or Microsoft Authenticator generate a new code every 30 seconds. Push confirmations send a request directly to the app, which the user approves with a tap.
Hardware security keys based on the FIDO2/WebAuthn standard (e.g. YubiKey) and passkeys are considered particularly phishing-resistant. SMS or email codes are also widespread but are regarded as weaker due to interception and SIM-swapping risks.
Why MFA matters
Passwords are the weakest point of most systems: they are reused, exposed in leaks, harvested via phishing or guessed through automated attacks (credential stuffing, brute force). MFA decouples security from the password alone, because an attacker additionally needs the second factor, which they usually do not possess.
In practice, MFA drastically reduces account takeovers because a captured password leads nowhere. For companies this is especially relevant for systems with sensitive data and far-reaching permissions. For this reason, cyber insurers, auditors and security standards such as ISO 27001 today generally require MFA for privileged and externally reachable access.
MFA is not a cure-all: poorly implemented methods can be bypassed, for example through MFA fatigue attacks in which users are bombarded with push requests until they accidentally approve one. MFA only becomes effective through phishing-resistant factors, clear processes for lost devices and staff training. Security arises from the interplay of technology and organization, not from flipping a single switch.
Multi-factor authentication (MFA) in the ERP system
An ERP system consolidates highly sensitive business data: financial accounting, customer and supplier master data, prices, stock levels and payment runs. A compromised account can enable merchandise fraud, manipulated transfers or data theft. MFA is therefore a central building block for securing ERP accounts, especially with cloud ERP that is reachable over the open internet.
Technically, MFA in the ERP is either provided natively by the software or implemented via an upstream identity management through single sign-on. In both cases the check applies before the user's actual roles and permissions take effect. A risk-based tiering makes sense: critical actions such as payment approvals or administrator access require MFA mandatorily, while routine access within the corporate network can proceed with less friction.
MFA, SSO and role permissions working together
MFA answers the question "Are you really who you claim to be?" (authentication). This is distinct from authorization via permissions and roles, which defines what a user is allowed to do after a successful login. Combined with single sign-on, the user logs in once centrally together with the second factor and thereby gains secured access to multiple systems.
DACH specifics and legal framework
In the DACH region, MFA is underpinned by several frameworks. The GDPR requires "appropriate technical and organizational measures" in Art. 32 to protect personal data, and MFA is considered state of the art here for sensitive systems. The BSI's IT-Grundschutz explicitly recommends MFA for administrative access and access reachable from the internet.
In payment transactions, strong customer authentication (SCA) with at least two factors has been mandatory for years under the EU PSD2 directive, an everyday example of legally mandated MFA. For companies this means: MFA is long past being merely "nice to have" and is, in many contexts, a prerequisite for compliance, insurability and the secure operation of business-critical systems.
Example
MFA for the ERP access of a trading company
A mid-sized online retailer runs a cloud ERP that is reachable from the home office and on the move. After a phishing incident at a competitor, management introduces MFA for all access: employees still log in with a password but additionally confirm the login via push in an authenticator app on their company phone.
A few weeks later, an accountant's password surfaces in a data leak and is tried out by an attacker. The login fails because the push confirmation on the accountant's smartphone never comes, he sees the unexpected request, declines it and reports the incident. Access to payment runs and customer data thus remains denied, even though the password was compromised.
Frequently asked questions
Related services
Questions about Multi-Factor Authentication (MFA) in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.