---
title: "Multi-Factor Authentication (MFA): Definition"
description: "Learn how to implement multi-factor authentication that satisfies ISO 27001, SOC 2, NIS2, and DORA requirements. Covers MFA methods, FIDO2/WebAuthn, conditional access, phishing-resistant MFA, and compliance evidence."
canonical: https://www.orbiqhq.com/glossary/multi-factor-authentication
html: https://www.orbiqhq.com/glossary/multi-factor-authentication
publisher: Orbiq GmbH
language: en
---
# Multi-Factor Authentication (MFA): Definition

Learn how to implement multi-factor authentication that satisfies ISO 27001, SOC 2, NIS2, and DORA requirements. Covers MFA methods, FIDO2/WebAuthn, conditional access, phishing-resistant MFA, and compliance evidence.


## What Is Multi-Factor Authentication?

Multi-factor authentication (MFA) is a security mechanism that requires users to verify their identity using two or more independent factors before gaining access to a system, application, or data. By combining multiple authentication factors from different categories, MFA ensures that compromising a single credential (such as a password) is insufficient for an attacker to gain access.

With credential theft and phishing attacks accounting for the majority of breaches, MFA has become a baseline security control required by virtually every compliance framework including ISO 27001, SOC 2, NIS2, and DORA.

## Authentication Factor Types

| Factor Type | Category | Examples | Strength |
| --- | --- | --- | --- |
| **Password/PIN** | Something you know | Passwords, PINs, security questions | Low (phishable, guessable) |
| **TOTP code** | Something you have | Google Authenticator, Authy, Microsoft Authenticator | Medium (phishable via proxy) |
| **SMS code** | Something you have | One-time code via SMS | Low-Medium (interceptable) |
| **Push notification** | Something you have | Duo Push, Microsoft Authenticator push | Medium (susceptible to fatigue attacks) |
| **Hardware security key** | Something you have | YubiKey, Google Titan, Feitian | High (phishing-resistant) |
| **Biometric** | Something you are | Fingerprint, face recognition, iris scan | High (bound to individual) |
| **Passkey** | Something you have + are | FIDO2 synced credentials with biometric unlock | High (phishing-resistant, passwordless) |

## MFA Methods Comparison

| Method | Phishing Resistant | User Experience | Deployment Complexity | Cost |
| --- | --- | --- | --- | --- |
| **SMS OTP** | No | Medium | Low | Low |
| **TOTP app** | No | Medium | Low | Free |
| **Push notification** | No | High | Medium | Per-user licensing |
| **Hardware security key** | Yes | Medium | Medium | Per-key hardware cost |
| **Platform biometric** | Yes | High | Low | Built into devices |
| **Passkey** | Yes | Very High | Medium | Free |
| **Smart card + PIN** | Yes | Low | High | Per-card + infrastructure |

## Conditional Access Policies

| Condition | Risk Level | MFA Requirement |
| --- | --- | --- |
| **Known device + known location** | Low | No MFA (session token valid) |
| **Known device + new location** | Medium | MFA required |
| **New device + any location** | High | MFA required + device registration |
| **Privileged action** | High | Step-up MFA required |
| **Admin/privileged account** | Critical | MFA always required (phishing-resistant preferred) |
| **Impossible travel detected** | Critical | MFA required + security review |

## MFA Implementation Architecture

| Component | Function | Examples |
| --- | --- | --- |
| **Identity provider (IdP)** | Centralised authentication and MFA enforcement | Azure AD, Okta, Google Workspace, Auth0 |
| **MFA service** | Second-factor verification | Duo, RSA SecurID, built-in IdP MFA |
| **SSO integration** | Single sign-on with MFA at the IdP | SAML 2.0, OIDC, OAuth 2.0 |
| **Directory service** | User and group management for MFA policies | Active Directory, LDAP, SCIM |
| **Authenticator apps** | Client-side TOTP/push generation | Google Authenticator, Microsoft Authenticator, Authy |
| **FIDO2 server** | WebAuthn credential management | Built into modern IdPs |

## MFA Rollout Strategy

| Phase | Actions | Timeline |
| --- | --- | --- |
| **Phase 1** | Enable MFA for all administrator and privileged accounts | Week 1-2 |
| **Phase 2** | Enable MFA for IT and security teams | Week 3-4 |
| **Phase 3** | Enable MFA for all employees accessing sensitive systems | Month 2 |
| **Phase 4** | Enable MFA for all users and external collaborators | Month 3 |
| **Phase 5** | Migrate to phishing-resistant MFA (FIDO2/passkeys) | Month 4-6 |
| **Phase 6** | Implement conditional access and adaptive MFA | Month 6-9 |

## Compliance Requirements

### Framework Mapping

| Requirement | ISO 27001 | SOC 2 | NIS2 | DORA |
| --- | --- | --- | --- | --- |
| Multi-factor authentication | A.8.5 | CC6.1 | Art. 21(2)(j) | Art. 9(4)(c) |
| Privileged access controls | A.8.2 | CC6.3 | Art. 21(2)(i) | Art. 9(4)(c) |
| Access review | A.5.18 | CC6.2 | Art. 21(2)(i) | Art. 9(2) |
| Authentication logging | A.8.15 | CC7.2 | Art. 21(2)(g) | Art. 10(2) |
| Remote access security | A.8.1 | CC6.6 | Art. 21(2)(j) | Art. 9(4)(c) |
| Password policy | A.8.5 | CC6.1 | Art. 21(2)(j) | Art. 9(4)(b) |

### Audit Evidence

| Evidence Type | Description | Framework |
| --- | --- | --- |
| MFA policy | Documented policy requiring MFA for specified user groups | All frameworks |
| MFA enrollment report | Percentage of users with MFA enabled by method type | All frameworks |
| Conditional access rules | Configuration of risk-based MFA policies | ISO 27001, SOC 2 |
| Authentication logs | Records showing MFA challenges and results | All frameworks |
| MFA exception register | Documented exceptions with risk acceptance and review dates | All frameworks |
| Privileged account audit | Evidence that all privileged accounts have MFA enabled | All frameworks |
| Recovery procedure documentation | Process for MFA reset and account recovery | ISO 27001, SOC 2 |

## Common Mistakes

| Mistake | Risk | Fix |
| --- | --- | --- |
| MFA for admins only | Regular user accounts compromised via phishing | Enable MFA for all users, starting with high-risk groups |
| Relying solely on SMS | SIM swapping and interception attacks | Migrate to TOTP apps, push, or FIDO2 security keys |
| No MFA for service accounts | Privileged service accounts compromised | Use certificate-based auth or managed identities for service accounts |
| MFA fatigue vulnerability | Users approve fraudulent push notifications | Implement number matching, limit push attempts, use FIDO2 |
| No MFA bypass procedures | Users locked out with no recovery path | Document and test recovery procedures with identity verification |
| Excluding legacy applications | Unprotected entry points into the environment | Use reverse proxy or VPN with MFA for legacy apps |

## How Orbiq Supports MFA Compliance

Orbiq helps you demonstrate authentication security controls:

- **Evidence collection** — Centralise MFA policies, enrollment reports, and authentication logs
- **Continuous monitoring** — Track MFA adoption rates and authentication security posture
- **Trust Center** — Share your authentication security controls via your [Trust Center](/glossary/trust-center)
- **Compliance mapping** — Map MFA controls to ISO 27001, SOC 2, NIS2, and DORA
- **Audit readiness** — Pre-built evidence packages for auditor review

## Further Reading

- [Identity and Access Management](/glossary/identity-and-access-management) — Comprehensive IAM strategy
- [Privileged Access Management](/glossary/privileged-access-management) — Securing privileged accounts
- [Zero Trust](/glossary/zero-trust-architecture) — MFA as a zero trust foundation
- [Data Privacy](/glossary/data-privacy) — Authentication for privacy compliance
- [Security Awareness Training](/glossary/security-awareness-training) — Training users on MFA best practices