The Three Authentication Factors
Authentication factors are categories of proof that verify your identity. MFA works because compromising one factor category does not compromise another — a stolen password doesn't give an attacker your fingerprint, and stealing your phone doesn't reveal your password.
MFA Types — TOTP, HOTP, Push, and Hardware Tokens
| Type | How It Works | Strength | Exam Key Point |
|---|---|---|---|
| TOTP | Time-based one-time password — generates a 6-digit code every 30 seconds using a shared secret + current time. Google Authenticator, Authy. | Strong | Code expires in 30 seconds — replay attacks fail |
| HOTP | HMAC-based one-time password — generates a code based on a counter that increments with each use. Older RSA SecurID tokens use this. | Moderate | Counter-based, not time-based — codes don't expire automatically |
| Push Notification | App on your phone receives a push asking "Approve this login?" — you tap Approve or Deny. Microsoft Authenticator, Duo. | Strong | Vulnerable to MFA fatigue attacks (push bombing) |
| Hardware Token | Physical device (YubiKey, RSA SecurID) generates codes or uses USB/NFC to authenticate. Cannot be phished remotely. | Very Strong | Most phishing-resistant MFA — code never entered manually |
| SMS OTP | One-time code sent via text message. Weakest MFA option — susceptible to SIM swapping. | Weak | Better than no MFA, but weakest option on exam questions |
| FIDO2 / Passkeys | Cryptographic key pair — private key stays on device, public key with server. No password transmitted. WebAuthn standard. | Strongest | Phishing-resistant by design — no shared secret to steal |
FIDO2 and Passkeys — the Future of Authentication
FIDO2 (Fast IDentity Online 2) is the authentication standard behind passkeys. Instead of transmitting a password or OTP code, FIDO2 uses public-key cryptography: your device holds a private key that never leaves it, and the server holds the corresponding public key. When you authenticate, your device signs a challenge with the private key — the server verifies the signature without ever seeing the private key or anything that could be stolen and replayed.
This makes FIDO2 inherently phishing-resistant. Even if an attacker tricks you into visiting a fake login page, there's no password or code to capture — the private key never leaves your device, and the cryptographic challenge is domain-specific (a fake site can't use the signature generated for the real site). The exam doesn't test FIDO2 implementation details deeply, but you should know it's the most phishing-resistant authentication method available.
MFA Fatigue Attacks — Push Bombing
MFA fatigue (push bombing) is an attack where an adversary who has stolen valid credentials repeatedly sends MFA push notifications to the victim's phone, hoping the victim approves one out of frustration, confusion, or distraction. The Uber breach in 2022 succeeded largely through MFA fatigue — the attacker sent continuous Duo pushes until the victim approved one.
Mitigations: Number matching (the push shows a number you must match to a number on screen — prevents blind approval), phishing-resistant MFA (FIDO2/hardware tokens eliminate push notifications entirely), rate limiting push notifications, and user awareness training.
Smart Cards and PIV
Smart cards combine something you have (the physical card with an embedded chip) and something you know (the PIN to unlock it), making them inherently two-factor. The US government's PIV (Personal Identity Verification) card is a smart card standard used for physical and logical access to federal facilities and systems. CAC (Common Access Card) is the DoD equivalent. Smart cards are covered on Security+ because they appear in enterprise and government access control scenarios — the exam expects you to know that a smart card requires a PIN to activate, making it two-factor by itself.
MFA requires factors from different categories. A password plus a security question is not MFA — both are knowledge factors. A password plus an authenticator app code is MFA — knowledge + possession. The exam will test this distinction with answer choices designed to trip up candidates who confuse "two steps" with "two factors."
Where MFA Fits in Zero Trust and IAM
MFA is a foundational control in Zero Trust architecture — "never trust, always verify" means every authentication attempt must be verified with strong factors regardless of network location. Even users inside the corporate network must MFA. Zero Trust policies often add additional context — if a user's location, device posture, or access pattern is unusual, step-up authentication can require a stronger second factor or re-authentication. MFA also directly satisfies compliance requirements: PCI-DSS requires MFA for remote access to the cardholder data environment, and HIPAA guidance recommends MFA for systems storing PHI.
Exam Scenarios
Common MFA Misconceptions on the Exam
Several MFA concepts are frequently misunderstood or tested as trick questions on Security+ exams. Being aware of these specific traps will help you avoid losing points on otherwise well-understood topics.
Two-step verification is not the same as two-factor authentication. Two-step verification simply means two sequential authentication steps — these steps could both be knowledge factors (password then a security question). True MFA requires factors from two different categories. The exam may present scenarios where a system uses "two-step" login but both steps are knowledge-based — that is not MFA. Only when different factor categories are combined does it count as MFA.
The order of factor verification does not determine which factor is "primary." Some exam candidates assume the password is always factor 1 and the OTP is factor 2, but this is just convention. The authentication is equally valid regardless of which factor is verified first. What matters is that factors from at least two different categories are required before access is granted.
Biometrics alone are not MFA. Fingerprint unlock on a phone is a single factor (something you are). It's a replacement for a PIN (something you know) — substituting one factor type for another. A phone that unlocks with fingerprint only (no PIN fallback) uses single-factor authentication, just with a biometric factor instead of a knowledge factor. MFA requires fingerprint AND PIN, or fingerprint AND an authenticator code — two different categories together.
Location as a factor is supplementary, not definitive. While location can be used as an additional signal in adaptive authentication, IP geolocation is imprecise and can be spoofed with VPNs. The exam recognizes location as a fourth factor but doesn't treat it as a substitute for knowledge, possession, or inherence factors in standard MFA scenarios.
Authenticator Apps vs Hardware Tokens — Practical Comparison
For Security+ candidates, understanding the practical tradeoffs between different MFA implementations helps in selecting the right answer for scenario-based questions about security requirements.
Authenticator apps (Google Authenticator, Microsoft Authenticator, Authy) are the most widely deployed TOTP solution. They are free, work offline (no internet connectivity required to generate codes), and can store hundreds of accounts. The code changes every 30 seconds (TOTP) based on the shared secret and current time — an attacker who intercepts one code cannot use it again after the 30-second window. The weakness is that if an attacker can see the current code displayed on screen (shoulder surfing) or intercept a TOTP code in transit through a real-time phishing proxy, they can use it within the valid time window. Authenticator app codes are not phishing-resistant in the way FIDO2 is.
Hardware security keys (YubiKey, Google Titan Key, FIDO2 keys) provide stronger security through public-key cryptography. The private key never leaves the hardware device — no network interception or phishing can capture it. The authentication is cryptographically bound to the domain being authenticated, so a phishing site for fake-bank.com cannot use a response generated for real-bank.com. For high-security roles (system administrators, finance executives, executives with access to sensitive systems), hardware keys are the recommended MFA method. The trade-off is cost ($25–$60 per key), physical provisioning (keys must be distributed to users), and the risk of loss (requiring a backup key enrollment process).
SMS OTP is convenient because it requires no app installation or hardware, but SIM-swapping attacks make it the weakest MFA option. NIST SP 800-63B categorizes SMS OTP as a restricted authenticator and recommends against it for high-value accounts. For exam scenarios: when the question says "most secure MFA option," the answer is hardware token or FIDO2. When it says "easiest to deploy at scale without device enrollment," SMS OTP is often the answer — with the caveat that it's the weakest option.
MFA Implementation Methods by Platform
MFA is implemented differently depending on the platform and use case. Understanding which methods are available in enterprise environments is relevant for both Security+ exam scenarios and real-world deployment decisions.
For Microsoft 365 and Azure Active Directory (now Microsoft Entra ID), MFA is enforced through Conditional Access policies or per-user MFA settings. Microsoft Authenticator is the preferred app, supporting push notifications with number matching, TOTP codes, and passwordless sign-in using biometrics on the phone. Azure AD also supports FIDO2 security keys and Windows Hello for Business (biometric/PIN MFA built into Windows 10/11 that uses TPM-backed credentials). Microsoft's security defaults, which can be enabled in any tenant, force MFA for all administrators and for all users when risky sign-ins are detected.
For VPN authentication, MFA is typically integrated through RADIUS. The VPN gateway sends the user's credentials to a RADIUS server, which in turn integrates with an MFA provider (Duo, Okta, Azure MFA) before returning the accept or reject decision. This architecture works with any VPN that supports RADIUS without modifying the VPN software itself — the MFA layer is inserted transparently. For exam scenarios: when asked how to add MFA to an existing VPN without replacing the VPN hardware, the answer involves RADIUS integration with an MFA provider.
Adaptive and Contextual Authentication
Adaptive authentication (also called risk-based authentication) dynamically adjusts the authentication requirements based on contextual risk signals at the time of login. Rather than requiring the same MFA method in every situation, an adaptive system evaluates the context and may allow a simpler login when risk is low, or require stronger verification when risk signals indicate something unusual.
Common risk signals used in adaptive authentication include: geographic location (is the user logging in from their normal city, or from an unfamiliar country?), device posture (is this a known, corporate-managed device, or an unrecognized device?), time of access (logging in at 3am when the user normally works 9-5?), velocity (the user logged in from New York 20 minutes ago — how are they now logging in from London?), and IP reputation (is the source IP associated with VPN exit nodes, Tor, or known malicious infrastructure?).
When risk signals exceed a threshold, the system triggers step-up authentication — requiring an additional or stronger factor before granting access. A user logging in from their usual device on the corporate network might get through with password + TOTP code. The same user logging in from an unknown device in a foreign country might be asked for a hardware token or might have the session blocked pending IT review. Microsoft Azure AD Conditional Access and Okta Adaptive MFA implement this model.
Out-of-Band Authentication
Out-of-Band (OOB) authentication verifies identity using a separate communications channel from the one being authenticated. The idea is that an attacker who has compromised one channel (e.g., intercepted your browser session) cannot simultaneously compromise a completely different channel (e.g., your cellular network for receiving SMS).
The most common OOB method is SMS OTP — you log in via web browser, and a one-time code is sent to your phone via SMS. The authentication requires both channels: your computer (which the attacker may have compromised) and your phone (a separate channel). Phone calls delivering a spoken OTP are another OOB method. Modern OOB authentication using push notifications to an authenticator app is more secure than SMS because the push channel uses the app's own encrypted connection rather than the SMS network.
SMS OOB is considered the weakest form of MFA because the SMS channel can be compromised via SIM swapping — an attack where the attacker convinces the mobile carrier to transfer the victim's phone number to a SIM card the attacker controls. Once they have the phone number, all SMS messages (including OTP codes) are delivered to the attacker. For this reason, NIST SP 800-63-3 restricts SMS OTP to specific use cases and recommends app-based or hardware alternatives.
MFA and Single Sign-On (SSO)
SSO (Single Sign-On) allows users to authenticate once and access multiple applications without re-authenticating for each one. MFA and SSO work together — rather than being in tension with each other, combining them gives you strong security at the SSO login point plus seamless access to all connected applications.
The typical enterprise architecture combines an Identity Provider (IdP) — such as Microsoft Azure AD, Okta, or Ping Identity — with SSO protocols (SAML 2.0 or OpenID Connect/OAuth 2.0). Users authenticate to the IdP once with MFA, receive a session token, and that token is used to access all connected service providers (applications) without re-entering credentials. From the user's perspective, they log in once in the morning and their email, CRM, HR system, and collaboration tools all work without additional prompts.
For Security+ exam scenarios: if the question asks for a way to reduce password fatigue and the number of login prompts while maintaining strong security, the answer is SSO combined with MFA at the IdP. If the question asks what the risk is of SSO without MFA, the answer is that a single stolen password grants access to every connected application — making MFA at the SSO entry point even more critical.
PCI-DSS v4.0: Requires MFA for all access into the cardholder data environment (CDE), for all remote access, and for all administrative access. Single-factor authentication is not acceptable for any privileged access in PCI scope.
HIPAA: Does not mandate MFA explicitly but the Security Rule's access control requirements effectively make it a best practice for any system processing ePHI. HHS has issued guidance strongly recommending MFA for covered entities.
NIST SP 800-63-3: Defines authentication assurance levels (AAL1/2/3). AAL2 requires MFA; AAL3 requires hardware cryptographic authenticators (FIDO2/smart cards). Federal systems handling sensitive data require AAL2 or higher.