MFA — Multi-Factor Authentication

Multi-Factor Authentication (MFA) requires users to verify identity through two or more independent factors — something they know (password), something they have (phone, hardware key) or something they are (biometric). MFA dramatically reduces account-takeover risk from phishing, password leaks and credential stuffing. For ERP-bearing organisations, MFA has become a standard control rather than an optional enhancement, with regulatory mandates under NIS-2, DORA and industry-specific compliance regimes.

Authentication factors

Knowledge factor — password, PIN, security questions. Increasingly considered insufficient as a single factor
Possession factor — smartphone, hardware token, smart card
Biometric factor — fingerprint, face, voice. Often used as device unlock combined with possession factor
Location factor — conditional access from corporate network or trusted geography
Behavioural factor — typing rhythm, mouse patterns. Mostly used in fraud-detection

True MFA requires factors from different categories — two passwords are still single-factor regardless of complexity.

Common technologies

TOTP (Time-based One-Time Password) — rotating 6-digit code in authenticator app (Google Authenticator, Microsoft Authenticator, Authy, 1Password). Standardised under RFC 6238, widely supported, low cost. Phishable in real-time attacks. SMS one-time codes — once dominant, now discouraged due to SIM-swapping attacks. Should not be used for high-privilege accounts. Push notifications — authenticator app prompts user to approve login. More user-friendly than TOTP but vulnerable to MFA-fatigue attacks. FIDO2 / WebAuthn — passwordless or password-plus-key authentication using hardware keys (YubiKey, SoloKey) or platform authenticators (Touch ID, Windows Hello). Phishing-resistant by design. Recommended for high-privilege accounts. Smart cards — classical PKI-based authentication, still common in regulated industries and government.

Regulatory drivers in DACH

Several DACH and EU regulations effectively mandate MFA. NIS-2 (EU 2022/2555, effective from 2024/2025 transposition): essential and important entities must implement risk-management measures including access controls; MFA is the de-facto interpretation for privileged access. DORA (EU financial services): mandates strong customer authentication for ICT systems handling financial data. PSD2 SCA (payment services): mandates strong customer authentication for electronic payments. ISO 27001 Annex A.9: requires access controls proportionate to risk. BSI IT-Grundschutz (Germany federal office for information security): MFA recommended for all critical systems. For ERP-bearing organisations, MFA is now an audit baseline, not an optional security enhancement.

ERP implementation patterns

Three integration patterns. (1) Native ERP MFA: ERP includes built-in MFA configuration (SAP S/4HANA, Microsoft Dynamics 365, NetSuite, Oracle Cloud ERP all do). Simple to deploy, limited to that ERP. (2) MFA via SSO/IdP: ERP delegates authentication to a central identity provider (Microsoft Entra ID, Okta, PingFederate, Keycloak), which enforces MFA before issuing the SSO token. Standard for organisations with multiple applications. Recommended approach for DACH mid-market. (3) Network-level MFA: VPN or zero-trust access platforms (Zscaler, Cloudflare Access, Tailscale) enforce MFA before allowing any application access. Common for high-security environments. The SSO-based pattern dominates modern deployments because it scales across the full application portfolio with a single MFA policy.

Frequently Asked Questions

Is SMS-based MFA still acceptable?

Acceptable for low-risk consumer-facing scenarios; not acceptable for ERP access or any account with material financial or data-protection exposure. SIM-swapping attacks and SS7 interception have demonstrated SMS-MFA bypass at scale. Use TOTP, push notifications or FIDO2 hardware keys instead for business-critical access.

How do we handle MFA for shared service accounts?

Service accounts (used by integration jobs, scheduled tasks, third-party tools) should not have human-style MFA. Use service-account authentication mechanisms instead: certificate-based authentication, OAuth client credentials, managed identities (Azure Managed Identity, AWS IAM Roles). The principle: humans need MFA, machines need certificates.

What about MFA-fatigue attacks?

Push-notification MFA is vulnerable to attackers spamming the user with login requests until accidental approval. Defences: number-matching (user must enter a 2-digit code from the login screen into the authenticator), risk-based prompting (suppress prompts from suspicious sources), security training emphasising the 'deny and report' response to unexpected MFA prompts. Microsoft Authenticator and Okta Verify both implement number-matching as default since 2023.