This chapter covers Multi-Factor Authentication (MFA), a foundational security control that requires users to present two or more distinct authentication factors to verify their identity. For the SY0-701 exam, objective 1.2 under General Security Concepts, you must understand the types of factors, how MFA works, common implementations, and how attackers bypass it. Mastering MFA is critical because it is one of the most effective defenses against credential theft and is widely tested in scenario-based questions.
Jump to a section
Imagine a bank vault that requires two separate keys to open. The first key is something you have: a physical key kept in your pocket. The second key is something you are: a fingerprint scanner that only you can activate. Even if a thief steals your physical key, they cannot open the vault because they lack your fingerprint. Conversely, a thief cannot replicate your fingerprint without the physical key. This two-key system dramatically reduces the risk of unauthorized access compared to a single-key vault. In cybersecurity, Multi-Factor Authentication (MFA) works similarly. The first factor (e.g., a password) is like the physical key—something you know. The second factor (e.g., a one-time code from an authenticator app) is like the fingerprint—something you have or are. An attacker who steals your password (the first key) still cannot access your account without the second factor (the second key). This mechanism ensures that compromising one factor alone is insufficient for authentication, significantly raising the bar for attackers.
What is Multi-Factor Authentication (MFA)?
Multi-Factor Authentication (MFA) is a security mechanism that requires a user to provide two or more independent credentials from different categories of authentication factors to verify their identity. The goal is to create a layered defense that makes it significantly harder for an attacker to gain unauthorized access, even if one factor (e.g., a password) is compromised. MFA is a core component of the principle of defense in depth and is mandated by many compliance frameworks (e.g., PCI DSS, HIPAA, NIST SP 800-63).
The Three Authentication Factors
The three primary categories of authentication factors are:
Something you know (Knowledge Factor): This includes passwords, PINs, security questions, or passphrases. This is the most common factor but also the most vulnerable to phishing, brute force, and credential stuffing.
Something you have (Possession Factor): This includes physical devices like smart cards, hardware tokens (e.g., YubiKey), software tokens (e.g., Google Authenticator), or SMS/call-based one-time passwords (OTP). The device must be in the user's possession.
Something you are (Inherence Factor): This includes biometric characteristics like fingerprints, facial recognition, iris scans, voice patterns, or behavioral biometrics (e.g., typing rhythm).
Some frameworks also include additional factors: - Somewhere you are (Location Factor): Based on geolocation, IP address, or network proximity. Often used as a risk-based (adaptive) authentication signal. - Something you do (Action Factor): Behavioral patterns like swipe gestures or typing speed.
For SY0-701, focus on the three primary factors. MFA must use at least two different categories. Using two passwords (both something you know) is not MFA—it is two-step verification (2SV) but not true multi-factor.
How MFA Works Mechanically
A typical MFA authentication flow (e.g., logging into a web application) follows these steps:
1. User initiates login: The user enters their username and password (first factor: something you know). 2. Server validates first factor: The authentication server checks the password against stored hash (e.g., bcrypt, PBKDF2). If valid, it proceeds to request the second factor. 3. Second factor challenge: The server sends a challenge to the user's registered second factor device. For example: - TOTP (Time-based One-Time Password): The server and authenticator app share a secret key (seed). Both generate a 6-digit code using the current time (typically 30-second window). The server verifies the code the user enters. - Push notification: The server sends a push to the user's mobile app (e.g., Microsoft Authenticator). The user approves or denies. - SMS OTP: The server sends a one-time code via SMS. 4. User provides second factor: The user enters the TOTP code, approves the push, or enters the SMS code. 5. Server validates second factor: The server checks the second factor. For TOTP, it computes the expected code using the shared secret and current time. If valid, authentication succeeds. 6. Session creation: The server issues a session token or cookie, often with a flag indicating MFA was used.
Key Components, Variants, and Standards
TOTP (RFC 6238): Time-based one-time password algorithm. Uses a shared secret and current Unix timestamp (divided into 30-second intervals) to generate a code. Commonly used in Google Authenticator, Microsoft Authenticator, Authy.
HOTP (RFC 4226): HMAC-based one-time password algorithm. Uses a counter that increments with each authentication. Less common than TOTP.
U2F / FIDO2 / WebAuthn (W3C standard): Hardware-based authentication using public-key cryptography. The device (e.g., YubiKey) generates a key pair; the private key never leaves the device. The server stores the public key. Authentication requires a physical tap. This is phishing-resistant because the device binds to the website origin (prevents relay attacks).
SMS OTP: While widely used, SMS is considered less secure due to SIM swapping and SS7 vulnerabilities. NIST SP 800-63 deprecated SMS as an out-of-band verifier.
Adaptive (Risk-based) Authentication: Not a factor itself, but a policy that may require MFA only when risk is high (e.g., new device, unusual location).
How Attackers Exploit MFA and How Defenders Deploy It
Attack techniques against MFA:
MFA Fatigue Attack: Attacker repeatedly sends push notifications until the user accidentally approves. Mitigation: number matching (user must enter a number shown on screen) or require PIN.
SIM Swapping: Attacker convinces carrier to transfer victim's phone number to attacker's SIM, intercepting SMS codes. Mitigation: use TOTP or hardware tokens instead of SMS.
Man-in-the-Middle (MITM) / Evilginx: Attacker sets up a reverse proxy that intercepts credentials and session cookies, including MFA tokens. Mitigation: use phishing-resistant MFA (FIDO2) with origin binding.
Pass-the-Cookie: After MFA, the session cookie is stolen via malware or XSS. Attacker uses the cookie without re-authenticating. Mitigation: short session timeouts, token binding, and device posture checks.
Social Engineering: Tricking user into revealing MFA codes. Mitigation: user training, and never share codes.
Defender deployment best practices:
Enforce MFA for all users, especially administrators and privileged accounts.
Use phishing-resistant MFA (FIDO2/WebAuthn) where possible.
Implement conditional access policies to require MFA based on risk.
Monitor for failed MFA attempts and MFA fatigue attacks.
Use number matching for push notifications to prevent accidental approvals.
Real Command/Tool Examples
- Generating a TOTP secret with `oathtool` (Linux):
oathtool --totp -b <base32_secret>- Verifying a TOTP code:
oathtool --totp -b <base32_secret> -d 6- Using `openssl` to generate a random secret:
openssl rand -base32 20Windows - Enforcing MFA via Group Policy: Not directly; MFA is typically enforced via Azure AD Conditional Access or third-party IAM.
NIST SP 800-63B: Defines assurance levels (IAL, AAL, FAL). AAL2 requires two factors, AAL3 requires phishing-resistant MFA.
User Submits Primary Credentials
The user enters their username and password (first factor) on the login page. The browser sends these credentials to the authentication server over HTTPS (TLS 1.2+). The server hashes the password (e.g., using bcrypt with a cost factor of 10) and compares it to the stored hash. If the password matches, the server proceeds to the second factor step. If not, an error is returned. Logs: the server logs 'Authentication: primary factor success for user X' or 'Authentication: primary factor failure for user X'.
Server Requests Second Factor
After successful primary authentication, the server sends a response to the client indicating that a second factor is required. The client may display a prompt like 'Enter your authenticator code' or send a push notification. The server generates a challenge specific to the user's registered second factor. For TOTP, the server computes the expected code using the shared secret and current time window. For push, the server sends a notification to the device registered via Firebase Cloud Messaging (FCM) or Apple Push Notification Service (APNs). Logs: 'MFA challenge sent to user X via method TOTP'.
User Provides Second Factor
The user retrieves the second factor: they open their authenticator app (e.g., Google Authenticator) and read the 6-digit TOTP code, or they receive an SMS code, or they approve a push notification. The user enters the code into the login form or taps 'Approve' on their phone. The client sends this response to the server. For TOTP, the code is sent as a string. For push, the device sends an approval token signed with the device's private key. Logs: 'MFA response received for user X'.
Server Validates Second Factor
The server validates the second factor. For TOTP, it computes the expected code using the shared secret and the current time (with a tolerance of +/-1 time step to account for clock drift). If the code matches, validation succeeds. For push, the server verifies the approval token's signature. If validation fails (e.g., code expired or invalid), the server may allow retries (typically 3-5 attempts) before locking the account or requiring re-authentication. Logs: 'MFA validation success for user X' or 'MFA validation failure for user X'.
Session Token Issued with MFA Flag
Upon successful MFA, the server creates a session token (e.g., a JWT or opaque session cookie) that includes a claim or attribute indicating that MFA was performed (e.g., `"amr": ["pwd", "otp"]`). This session token is sent back to the client and stored (e.g., in a secure HTTP-only cookie). Subsequent requests include this token. Applications may check the MFA claim to allow access to sensitive resources or to skip re-authentication for a limited time. Logs: 'Session created for user X with MFA flag set.'
Scenario 1: MFA Fatigue Attack in an Enterprise
A SOC analyst notices a spike in push notification approvals from a single user, John, over a 10-minute period. The logs show 50 MFA push requests from an unfamiliar IP address (185.xxx.xxx.xxx) located in a different country. John approved one of these pushes, likely due to fatigue. The analyst uses the SIEM (e.g., Splunk) to correlate the event with subsequent logins from that IP. The analyst immediately revokes John's session tokens and forces a password reset. The correct response is to block the attacker's IP, investigate the account for any data access, and implement number matching for MFA pushes to prevent accidental approvals. A common mistake is to ignore the multiple push requests, assuming they are benign, leading to account compromise.
Scenario 2: SIM Swapping Leading to Account Takeover
A helpdesk engineer receives a call from an attacker posing as a user, claiming to have lost their phone and requesting a SIM transfer to a new number. The helpdesk engineer, lacking proper verification procedures, processes the request. The attacker now receives SMS MFA codes for the victim's accounts. The engineer should have verified the user's identity using out-of-band methods (e.g., calling back a known number) and checked for recent SIM change requests. The correct response after detecting a SIM swap is to immediately lock the user's accounts, revert the SIM change, and require re-enrollment with a hardware token. Common mistake: helpdesk does not have a strict identity verification process, leading to frequent social engineering success.
Scenario 3: Phishing-Resistant MFA Implementation
A security architect deploys FIDO2 security keys (e.g., YubiKey) for all employees. During a phishing simulation, an attacker sends a fake Office 365 login page. Employees with TOTP-based MFA might enter their credentials and TOTP code, which the attacker can use in real-time (evilginx proxy). However, employees using FIDO2 keys cannot be phished because the key's private key is bound to the legitimate site's origin (e.g., login.microsoftonline.com). The architect reviews logs showing zero successful authentications via the phishing site. The correct approach is to enforce phishing-resistant MFA for high-risk users. Common mistake: assuming all MFA is equally secure, leading to reliance on SMS or TOTP alone.
Exactly What SY0-701 Tests on This Objective
Objective 1.2: 'Given a scenario, analyze potential indicators to determine the type of attack.' However, MFA is explicitly listed under authentication controls in Domain 3 (Implementation). Expect questions on:
Identifying the three authentication factors: knowledge, possession, inherence.
Recognizing that MFA uses two or more different factor types.
Understanding common MFA implementations: TOTP, HOTP, SMS, push notifications, smart cards, biometrics.
Knowing attack vectors against MFA: phishing, SIM swapping, MFA fatigue, man-in-the-middle, pass-the-cookie.
Selecting appropriate MFA methods based on security requirements (e.g., phishing-resistant for high-security environments).
Most Common Wrong Answers and Why
'Two-step verification is the same as MFA.' Wrong: Two-step verification uses two steps from the same factor (e.g., password + security question). MFA requires different factor types. Candidates often confuse 2SV with MFA.
'SMS is the most secure MFA method.' Wrong: SMS is vulnerable to SIM swapping and SS7 attacks. The exam favors phishing-resistant methods like FIDO2.
'Biometrics alone are sufficient for authentication.' Wrong: Biometrics are a single factor (inherence). MFA requires at least two factors. Biometrics can be spoofed or fail (e.g., wet fingers).
'MFA completely eliminates account takeover.' Wrong: MFA reduces risk but can be bypassed via session cookie theft, MFA fatigue, or social engineering.
Specific Terms and Acronyms
TOTP (Time-based One-Time Password) – RFC 6238
HOTP (HMAC-based One-Time Password) – RFC 4226
FIDO2 (Fast IDentity Online) – includes WebAuthn and CTAP
U2F (Universal 2nd Factor) – predecessor to FIDO2
RADIUS (Remote Authentication Dial-In User Service) – often used to proxy MFA
LDAP (Lightweight Directory Access Protocol) – directory services
SAML (Security Assertion Markup Language) – federated identity with MFA support
OAuth (Open Authorization) – token-based auth, often used with MFA
Common Trick Questions
'Which of the following is an example of MFA?' Look for two different factor types. Example: 'Password and fingerprint' (knowledge + inherence) is MFA. 'Password and PIN' is not.
'Which MFA method is most resistant to phishing?' Answer: FIDO2/WebAuthn because it uses origin-bound keys.
'What is the primary weakness of SMS-based MFA?' Answer: SIM swapping and interception.
Decision Rule for Eliminating Wrong Answers
On scenario questions, first identify the factor types mentioned. If the scenario describes two items from the same category (e.g., password and PIN), eliminate 'MFA' as the answer. If the question asks for the best MFA method given a threat (e.g., phishing), choose phishing-resistant methods (FIDO2) over convenience-based (SMS). For attacks, if the attacker repeatedly sends push notifications, the attack is MFA fatigue.
MFA requires at least two different authentication factor types: knowledge, possession, inherence.
TOTP (RFC 6238) generates a 6-digit code that changes every 30 seconds using a shared secret and time.
FIDO2/WebAuthn provides phishing-resistant MFA by binding the key to the website origin.
SMS-based MFA is deprecated by NIST due to SIM swapping and SS7 vulnerabilities.
MFA fatigue attacks involve repeated push notifications to trick users into approving.
Session cookies can be stolen after MFA; use short timeouts and token binding.
Adaptive MFA uses risk signals (location, device) to determine when to require MFA.
These come up on the exam all the time. Here's how to tell them apart.
TOTP (Time-based One-Time Password)
Shared secret between server and authenticator app.
Code changes every 30 seconds.
Vulnerable to phishing if user enters code on fake site.
No hardware requirement (software token).
Standard: RFC 6238.
FIDO2 / WebAuthn
Public-key cryptography; private key never leaves device.
No shared secret; server stores public key.
Phishing-resistant; key is bound to origin.
Requires hardware security key or platform authenticator.
Standard: W3C WebAuthn / FIDO2.
Mistake
MFA always uses three factors.
Correct
MFA requires at least two different factors. Three factors is possible but not required. Some systems use adaptive MFA that may only require a second factor under certain conditions.
Mistake
SMS-based MFA is secure because it requires a physical phone.
Correct
SMS is vulnerable to SIM swapping, SS7 interception, and phishing. NIST SP 800-63B deprecates SMS as an out-of-band verifier. Use TOTP or hardware tokens instead.
Mistake
Two-step verification is the same as MFA.
Correct
Two-step verification uses two steps from the same factor (e.g., password + security question). MFA requires steps from at least two different factor categories.
Mistake
Once MFA is passed, the session is safe indefinitely.
Correct
Attackers can steal session cookies after MFA (pass-the-cookie). Short session timeouts, token binding, and device posture checks are needed.
Mistake
Biometric MFA cannot be bypassed.
Correct
Biometrics can be spoofed (e.g., silicone fingerprints, deepfake voice). They are often used as a second factor but should be combined with liveness detection.
MFA requires two or more different categories of authentication factors (e.g., password + fingerprint). Two-step verification (2SV) uses two steps from the same factor (e.g., password + PIN). The exam distinguishes them: MFA is stronger because compromising one factor does not give access. Example: A bank requiring a password and a security question is 2SV, not MFA.
FIDO2/WebAuthn is the best because it uses public-key cryptography and binds the authentication to the website origin. Even if a user visits a fake site, the security key will not authenticate because the origin does not match. TOTP and SMS can be phished in real-time via reverse proxy attacks (e.g., Evilginx).
TOTP (Time-based One-Time Password) uses a shared secret key between the server and the authenticator app. Both derive a 6-digit code from the current Unix timestamp divided into 30-second intervals. The user enters the code, and the server verifies it by computing the expected code. If the code matches, authentication succeeds. RFC 6238 defines the algorithm.
An MFA fatigue attack occurs when an attacker repeatedly sends MFA push notifications to a user's device, hoping the user eventually approves out of annoyance or confusion. Defenses include implementing number matching (user must enter a number shown on the login screen), requiring a PIN, or using adaptive MFA that limits push frequency. Monitoring for multiple failed or approved pushes in a short time is also critical.
Yes, MFA can be bypassed in several ways: session cookie theft (pass-the-cookie), MFA fatigue, SIM swapping (for SMS), man-in-the-middle attacks (evilginx), and social engineering. However, phishing-resistant MFA (FIDO2) significantly reduces these risks. The exam expects you to know that MFA reduces risk but does not eliminate it.
The three factors are: (1) Something you know – passwords, PINs, security questions. (2) Something you have – smart cards, hardware tokens, mobile phones, authenticator apps. (3) Something you are – biometrics like fingerprints, facial recognition, iris scans, voice recognition. MFA must use at least two different categories.
Yes, that is MFA because a password is 'something you know' and a fingerprint is 'something you are' – two different factor categories. This is a common exam example of proper MFA.
You've just covered Multi-Factor Authentication (MFA) — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?