This chapter covers Multi-Factor Authentication (MFA) types for users, a critical topic for the CompTIA A+ Core 2 (220-1102) exam under Domain 2.0: Security, Objective 2.2. Questions on MFA typically appear in about 5-10% of the exam, often in scenario-based questions where you must choose the correct authentication factor type or identify a configuration weakness. You will learn the three authentication factor categories (something you know, have, are), the specific MFA methods used in enterprise environments, and how to implement them correctly to meet security requirements.
Jump to a section
Imagine a high-security bank vault that requires two different keys to open. The first key is something you have—a physical brass key that you carry on your keychain. The second key is something you know—a combination code that you must enter on a keypad. Without both, the vault remains sealed. In this analogy, the brass key represents a hardware token or smartphone authenticator app (something you have), and the combination represents a password (something you know). A third factor could be a biometric scanner (something you are), like a fingerprint reader. If an attacker steals your brass key (hardware token) but doesn't know the combination, they cannot open the vault. Similarly, if they guess your password but don't have the key, they are locked out. This is exactly how MFA works: it requires two or more independent factors from different categories—knowledge, possession, and inherence—so that compromising one factor does not grant access. The vault's security is not just about having two locks; it's about having locks of different types that an attacker cannot bypass with a single method (e.g., phishing or stealing a device).
What is Multi-Factor Authentication (MFA)?
Multi-Factor Authentication (MFA) is a security mechanism that requires users to present two or more independent credentials from different categories to verify their identity. The three categories are: - Something you know: passwords, PINs, security questions. - Something you have: smart cards, hardware tokens (e.g., RSA SecurID), software tokens (e.g., Google Authenticator), mobile phone (SMS or phone call). - Something you are: biometrics (fingerprint, facial recognition, iris scan, voice recognition).
MFA is distinct from two-step verification (2SV), which may use two factors from the same category (e.g., password + security question). True MFA always uses at least two different categories.
Why MFA Exists
Passwords alone are vulnerable to phishing, brute-force attacks, credential stuffing, and keylogging. MFA mitigates these by adding a second layer that an attacker cannot easily obtain. Even if a password is stolen, the attacker still needs the second factor—something the user physically possesses or a biometric trait.
How MFA Works Internally
User initiates authentication: The user enters their username and password (first factor – knowledge).
Server validates first factor: The authentication server verifies the password against its database (e.g., Active Directory, LDAP). If valid, the server initiates the second factor challenge.
Second factor challenge: The server sends a challenge to the user's registered device or requests a biometric scan. For a time-based one-time password (TOTP), the server and the authenticator app share a secret key and the current time (usually 30-second intervals). The user enters the code displayed on their device.
Server validates second factor: The server computes the expected TOTP using the shared secret and the current time. If the user's input matches, the server grants access.
Session established: The server issues a session token (e.g., cookie, JWT) that the user's browser or application uses for subsequent requests.
Key Components, Values, Defaults, and Timers
TOTP (RFC 6238): Uses a shared secret and the current Unix time divided by a time step (default 30 seconds). The authenticator generates a 6-8 digit code.
HOTP (RFC 4226): Uses a shared secret and a moving counter that increments with each successful authentication. Counter values are synchronized between server and client.
SMS/Phone: The server generates a one-time code (usually 6 digits) and sends it via SMS or automated call. This is less secure due to SIM swapping and interception risks.
Push notifications: The server sends a push to a registered mobile app (e.g., Microsoft Authenticator). The user approves or denies the request. This uses asymmetric cryptography to sign the approval.
FIDO2/WebAuthn: Uses public-key cryptography. The device generates a key pair; the private key never leaves the device. The server stores the public key. Authentication involves a challenge-response protocol.
Biometrics: Fingerprint sensors use capacitive or ultrasonic scanning. Facial recognition (e.g., Windows Hello) uses infrared cameras to prevent photos. Iris scans use near-infrared light.
Configuration and Verification Commands
On Windows, MFA is often configured via Group Policy or Microsoft 365 admin center. For Azure AD MFA:
- Enable MFA per user: In Azure AD portal, go to Users > Multi-Factor Authentication > Select user > Enable.
- Conditional Access policies: Define policies that require MFA based on sign-in risk, location, device compliance, etc.
- Verification: Use Get-MsolUser -UserPrincipalName user@domain.com | Select-Object StrongAuthenticationRequirements in PowerShell to check MFA status.
On Linux, PAM modules (e.g., pam_google_authenticator.so) can be configured for SSH MFA. Edit /etc/pam.d/sshd:
auth required pam_google_authenticator.soThen restart SSH service. Users must run google-authenticator to generate a secret key and emergency codes.
Interaction with Related Technologies
Single Sign-On (SSO): MFA can be integrated with SSO providers (e.g., Okta, Azure AD). The user authenticates once with MFA, and SSO tokens are issued for multiple applications.
Federation: Protocols like SAML and OIDC can carry MFA claims. The identity provider asserts that MFA was performed, and the service provider trusts that assertion.
VPN: Remote access VPNs (e.g., Cisco AnyConnect) can require MFA before granting network access. This is often done via RADIUS with a token server.
Smart cards: Used with PKI. The card contains a private key; the user must know the PIN to unlock it. This is two-factor (possession + knowledge).
Common MFA Methods
Hardware tokens: RSA SecurID (6-digit code changes every 60 seconds), YubiKey (USB/NFC device for FIDO2).
Software tokens: Google Authenticator, Microsoft Authenticator, Authy (TOTP/HOTP).
SMS/voice codes: Convenient but vulnerable to SIM swapping and SS7 attacks.
Push-based: Microsoft Authenticator push, Duo Security push. User sees a notification and taps Approve.
Biometrics: Windows Hello (face/fingerprint), Apple Face ID/Touch ID, fingerprint readers for laptops.
Smart card: PIV (Personal Identity Verification) cards used by US federal agencies.
Best Practices
Always require MFA for administrative accounts.
Use phishing-resistant MFA (e.g., FIDO2, smart cards) for high-value accounts.
Avoid SMS as the only second factor if possible; prefer TOTP or push.
Provide backup methods: recovery codes, alternative phone/email, or offline codes.
Enforce MFA via conditional access policies rather than per-user enablement for better user experience.
Exam Relevance
CompTIA A+ 220-1102 expects you to:
Distinguish between authentication factors (something you know, have, are).
Identify MFA methods: smart card, token, biometric, TOTP, SMS, push notification.
Understand that MFA requires at least two different categories.
Recognize common attacks against MFA: SIM swapping, phishing (for OTP codes), man-in-the-middle.
Know that biometrics include fingerprint, facial recognition, iris, voice.
Summary
MFA is a foundational security control that dramatically reduces the risk of account compromise. The 220-1102 exam focuses on identifying factor types and appropriate MFA methods for given scenarios. Remember: true MFA uses factors from at least two different categories. Smart cards are something you have + something you know (PIN). Biometrics alone are not MFA—they are a single factor.
User enters credentials
The user provides their username and password (first factor – something they know). This is sent over an encrypted TLS connection to the authentication server. The server hashes the password (e.g., with bcrypt or SHA-256) and compares it to the stored hash. If the hash matches, the server proceeds to the second factor challenge. If not, access is denied immediately. At this stage, the server may also check for account lockout policies (e.g., after 5 failed attempts) and conditional access conditions (e.g., location, device compliance).
Server initiates second factor challenge
After validating the first factor, the server sends a challenge to the user's registered second factor device. For TOTP, the server does not send anything; it expects the user to enter a code from their authenticator app. The user opens the app, which displays a 6-digit code that changes every 30 seconds. The app generates this code using the shared secret (provisioned during enrollment) and the current Unix time divided by 30. For push notifications, the server sends a push message to the user's phone via Apple Push Notification Service (APNS) or Firebase Cloud Messaging (FCM). The user sees a notification with details (e.g., location, app) and taps Approve.
User provides second factor
The user enters the TOTP code from their authenticator app, or taps Approve on a push notification, or inserts a smart card and enters the PIN. For biometrics, the user scans their fingerprint or face. The client device (e.g., laptop, phone) processes the biometric locally using a dedicated security chip (TPM or Secure Enclave) and sends a signed assertion to the server. For hardware tokens like YubiKey, the user touches the button, which sends a FIDO2 assertion. The communication is encrypted and may include a nonce to prevent replay attacks.
Server validates second factor
The server verifies the second factor. For TOTP, it computes the expected code using the shared secret and the current time (with a window of ±1 interval to account for clock drift). If the code matches, authentication succeeds. For push, the server receives a signed approval from the device; it verifies the signature using the device's public key. For biometrics, the server validates the signed assertion from the device. If the second factor is invalid (e.g., wrong code, expired), the server denies access and may log the attempt. The server may also enforce rate limiting (e.g., max 3 attempts per minute) to prevent brute-force.
Session established
Upon successful MFA, the server creates a session token (e.g., a signed JWT or a session cookie) that includes claims about the authentication method (e.g., MFA performed). The token has an expiration time (e.g., 8 hours). The client uses this token for subsequent requests. The server may also issue refresh tokens for long-lived sessions. If the session is used from a new device or location, the server may re-prompt for MFA (step-up authentication). The session is terminated when the user logs out or the token expires.
Enterprise Scenario 1: Remote VPN Access with Hardware Tokens
A large enterprise with 5,000 remote employees uses Cisco AnyConnect VPN for remote access. The security team mandates MFA for all VPN connections. They deploy RSA SecurID hardware tokens to each employee. Each token displays a 6-digit code that changes every 60 seconds. The VPN concentrator is configured to authenticate against RSA Authentication Manager via RADIUS. When a user connects, they enter their Active Directory username and password (first factor). The VPN server then prompts for the token code. The user reads the current code from their token and enters it. The RSA server validates the code using the shared secret and time. If correct, the VPN connection is established. This setup prevents unauthorized access even if an employee's password is phished. Common issues: token clock drift (requires resync), lost tokens (must be revoked and replaced), and users entering expired codes (they must wait for the next code).
Enterprise Scenario 2: Microsoft 365 with Conditional Access MFA
A mid-size company uses Microsoft 365 and wants to require MFA for all users accessing email from outside the corporate network. They configure Azure AD Conditional Access policies: if the sign-in risk is medium or higher, or if the device is not compliant, MFA is required. Users enroll in MFA via the Microsoft Authenticator app (push notifications). When a user attempts to access Outlook Web App from a non-corporate IP, Azure AD triggers a push notification to the user's phone. The user sees the sign-in request details (e.g., location, app) and taps Approve. The approval is cryptographically signed and sent to Azure AD. If the user denies or the request times out (default 5 minutes), access is blocked. This approach balances security and usability: most sign-ins from trusted locations are password-only, while suspicious or remote sign-ins require MFA. Common misconfigurations: not excluding emergency access accounts (break-glass accounts) from MFA policies, leading to lockouts.
Enterprise Scenario 3: Biometric MFA for Physical Access
A government facility uses smart cards (PIV cards) for physical access to secure areas. Each card has an embedded chip with the user's private key and a digital certificate. To enter a secured door, the user inserts their card into a reader and enters a PIN (something you have + something you know). This is two-factor authentication. Some high-security areas also require a fingerprint scan (something you are). The fingerprint reader uses a capacitive sensor and sends a hash of the fingerprint template to the access control server. The server compares it to the stored template. Only after all three factors are verified does the door unlock. This layered approach ensures that a lost card alone does not grant access, and a coerced PIN without the card is useless. Common issues: false rejects due to dirty sensors, users forgetting PINs, and card cloning attacks (mitigated by chip-based PKI).
What 220-1102 Tests on MFA
Objective 2.2: Given a scenario, apply authentication methods and best practices. The exam focuses on:
Identifying the three authentication factor categories: something you know (password, PIN), something you have (smart card, token, phone), something you are (biometric).
Recognizing MFA methods: smart card, token (hardware/software), biometric, TOTP, SMS, push notification.
Understanding that MFA requires at least two different categories.
Knowing common attacks: SIM swapping (targets SMS MFA), phishing for OTP codes, man-in-the-middle (e.g., Evilginx).
Best practices: use MFA for all admin accounts, avoid SMS when possible, have backup methods.
Most Common Wrong Answers and Why
"Biometrics alone are MFA" – Wrong. Biometrics are a single factor (something you are). MFA requires at least two different categories. Biometrics + password is MFA.
"SMS is the most secure second factor" – Wrong. SMS is vulnerable to SIM swapping and interception. TOTP or push are more secure.
"A password and a security question is MFA" – Wrong. Both are something you know; they are from the same category. This is two-step verification, not MFA.
"Smart cards are something you know" – Wrong. The card itself is something you have; the PIN is something you know. Together they are two-factor.
Specific Numbers, Values, and Terms That Appear on the Exam
TOTP code length: 6 digits (commonly).
TOTP time step: 30 seconds (default).
HOTP uses a counter, not time.
Common hardware tokens: RSA SecurID, YubiKey.
Common software tokens: Google Authenticator, Microsoft Authenticator.
Biometric types: fingerprint, facial recognition, iris scan, voice recognition, palm print.
Smart card standards: PIV (Personal Identity Verification) for US federal employees.
Push notification: Duo Security, Microsoft Authenticator.
Edge Cases and Exceptions the Exam Loves to Test
What if a user loses their phone? They should have backup codes (pre-generated one-time codes) or an alternative method (e.g., another phone, email).
What if biometric fails due to injury? The system should fall back to another factor (e.g., password + token).
What if the token clock drifts? The server allows a time window of ±1 interval (e.g., 90 seconds for TOTP with 30-second step).
What is the difference between 2FA and MFA? MFA requires two or more different categories; 2FA is a subset of MFA. Some sources use the terms interchangeably, but the exam expects MFA to mean different categories.
How to Eliminate Wrong Answers
If the question says "uses two different types of authentication factors," it's MFA. If it says "uses two passwords," it's not MFA.
If the scenario involves a physical device (card, token, phone), that's "something you have."
If the scenario involves a body part (fingerprint, face), that's "something you are."
If the scenario involves knowledge (password, PIN, answer to a question), that's "something you know."
If two factors are from the same category, it's not MFA.
For attacks: SIM swapping targets SMS; phishing targets OTP codes; man-in-the-middle targets push notifications (by showing a fake login page).
MFA requires at least two different authentication factor categories: something you know, something you have, and something you are.
Common MFA methods for the 220-1102 exam: smart card, hardware token, software token (TOTP), SMS, push notification, biometrics.
TOTP codes are typically 6 digits and change every 30 seconds (RFC 6238).
SMS-based MFA is less secure due to SIM swapping and interception risks.
Smart cards are something you have; the PIN is something you know; together they are two-factor.
Biometrics alone are a single factor; they must be combined with another factor for MFA.
Always enable MFA for administrative accounts and use phishing-resistant methods (e.g., FIDO2, smart cards) where possible.
Provide backup methods (recovery codes, alternative phone/email) in case the primary second factor is lost.
Conditional access policies can require MFA based on risk, location, or device compliance.
These come up on the exam all the time. Here's how to tell them apart.
TOTP (Time-based One-Time Password)
Uses a shared secret and current time (30-second step).
User must manually type the code from an authenticator app.
No network connectivity required on the authenticator device after initial sync.
Vulnerable to phishing if user is tricked into entering code on a fake site.
Common apps: Google Authenticator, Microsoft Authenticator, Authy.
Push Notification
Uses asymmetric cryptography; server sends push to device via APNS/FCM.
User taps Approve or Deny on the notification.
Requires internet connectivity on the device to receive the push.
More resistant to phishing because the user sees the context (e.g., location, app) before approving.
Common providers: Microsoft Authenticator, Duo Security, Okta Verify.
Mistake
MFA and two-step verification are the same thing.
Correct
Two-step verification (2SV) may use two factors from the same category (e.g., password + security question). MFA requires at least two different categories (e.g., password + token). The 220-1102 exam expects this distinction.
Mistake
SMS-based MFA is secure because the code is sent directly to the user's phone.
Correct
SMS is vulnerable to SIM swapping attacks, where an attacker convinces the mobile carrier to transfer the phone number to a new SIM. Also, SMS can be intercepted via SS7 protocol vulnerabilities. CompTIA recommends using app-based or hardware tokens instead.
Mistake
A smart card alone is two-factor authentication.
Correct
A smart card is something you have. It becomes two-factor only when combined with a PIN (something you know) or a biometric (something you are). The card itself is a single factor.
Mistake
Biometric authentication is always more secure than passwords.
Correct
Biometrics are convenient but have limitations. They cannot be changed if compromised (e.g., a fingerprint is permanent). Also, some biometric systems can be spoofed (e.g., high-resolution photos for facial recognition). Biometrics are best used as a second factor, not the sole factor.
Mistake
Once MFA is set up, it never needs to be changed.
Correct
MFA configurations should be reviewed regularly. If a user loses their phone or token, the second factor must be reset. Also, if a shared secret is exposed (e.g., database breach), new secrets should be issued. Recovery codes should be updated after use.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Two-factor authentication (2FA) is a subset of MFA that uses exactly two factors from different categories. MFA can use two or more factors, but they must be from different categories. In common usage, 2FA and MFA are often used interchangeably, but the CompTIA A+ exam expects that MFA requires factors from at least two different categories (knowledge, possession, inherence). For example, a password and a security question are both knowledge factors, so that is not MFA. A password and a smart card is MFA because it uses knowledge and possession.
No. The CompTIA A+ exam considers SMS-based MFA as less secure because it is vulnerable to SIM swapping attacks, where an attacker convinces the mobile carrier to transfer the phone number to a new SIM. Additionally, SMS messages can be intercepted via SS7 protocol vulnerabilities. The exam recommends using app-based authenticators (TOTP) or hardware tokens as more secure alternatives. However, SMS is still better than no MFA.
The three categories are: something you know (knowledge), something you have (possession), and something you are (inherence). Examples: password (knowledge), smart card (possession), fingerprint (inherence). For MFA, you must use at least two different categories. For example, a smart card plus a PIN uses possession and knowledge. Biometrics alone are a single factor (inherence).
A hardware token is a physical device that generates a one-time password (OTP) at regular intervals. The most common example is RSA SecurID, which displays a 6-digit code that changes every 60 seconds. The token shares a secret key with the authentication server. Both the token and server use the same algorithm (based on time) to generate the code. The user reads the current code and enters it during login. Hardware tokens are something you have and are considered a possession factor.
A smart card is a plastic card with an embedded integrated circuit chip that stores a private key and digital certificate. It is used for authentication by inserting it into a card reader and entering a PIN. The card is something you have, and the PIN is something you know, making it two-factor authentication. Smart cards are commonly used in government and enterprise environments (e.g., PIV cards for US federal employees). They are resistant to phishing because the private key never leaves the card.
Yes, biometrics can be used as a single factor (e.g., fingerprint to unlock a phone). However, for MFA, biometrics must be combined with another factor from a different category. For example, a fingerprint scanner plus a password is MFA (inherence + knowledge). The CompTIA A+ exam emphasizes that biometrics alone are not MFA.
Recovery codes are one-time use codes generated during MFA enrollment. They allow the user to authenticate if they lose access to their second factor (e.g., lost phone, broken token). Each code can be used only once. Users should store them securely (e.g., in a safe or password manager). The exam expects that you should always provide backup methods for MFA.
You've just covered MFA Types for Users — now see how well it sticks with free 220-1102 practice questions. Full explanations included, no account needed.
Done with this chapter?