The three factor categories and why they matter
Authentication factors are tested throughout the Security+ SY0-701 exam — not just in the Identity and Access Management objectives, but in network security, endpoint security, and incident response scenarios. If you have a shaky understanding of which factor is which, you will miss questions that have nothing to do with authentication theory.
Something you know: A secret the user knows. Passwords, PINs, security question answers, passphrases. Weakness: can be guessed, stolen, or phished. A password is always something you know, even if it is 32 characters long and randomly generated.
Something you have: A physical or digital object in the user's possession. Hardware tokens, smart cards, software authenticator apps (Google Authenticator, Microsoft Authenticator), PIV/CAC cards, a one-time code sent to a registered phone. Weakness: can be lost, stolen, or cloned. A one-time passcode (OTP) sent via SMS is something you have — the SIM card is the physical possession.
Something you are: A biometric — a physical characteristic of the user. Fingerprint, retinal scan, facial recognition, voice pattern, palm vein recognition. Weakness: cannot be reset if compromised. A fingerprint cannot be changed like a password.
A fourth factor also appears on Security+: somewhere you are (geolocation). This is a less common test target but appears in adaptive authentication and context-aware access scenarios.
The wrong answer patterns
Pattern 1: Confusing OTP with something you know
A question asks which factor a time-based OTP (TOTP) from an authenticator app represents. The distractor choices include "something you know." This is wrong — the TOTP itself is generated by an app on a device you possess. The factor is something you have. The fact that you see the code on screen and read it does not make it something you know — knowing the code is transient and meaningless without the device.
Pattern 2: Treating a smart card PIN as a separate factor
A smart card requires both the physical card (something you have) and a PIN (something you know). This combination is two-factor authentication. A question might ask what factor a smart card PIN represents in isolation. It is something you know — but the full smart card + PIN combination is 2FA. The exam will test whether you can distinguish the factor of one component from the combined authentication.
Pattern 3: Confusing biometrics with PINs
"A user unlocks their phone by drawing a pattern." That is something you know — a memorised sequence. "A user unlocks their phone using their fingerprint." That is something you are. Pattern, PIN, and password all fall under something you know regardless of the input method. A drawn pattern on a touchscreen is no different from a PIN from a factor perspective.
Pattern 4: Calling location an additional factor in all contexts
Geolocation is used in adaptive authentication — if a user normally logs in from the UK and suddenly authenticates from a different country, the system flags it or requires step-up authentication. This is somewhere you are. The exam might describe this scenario and ask which type of factor the location check represents. Location alone is not a primary authentication factor — it is a context signal used to trigger additional verification.
Multi-factor authentication on the exam
MFA requires at least two different factor categories. Two passwords is not MFA. A password and a security question answer is not MFA — both are something you know. A password plus a hardware token is MFA. A PIN plus a fingerprint is MFA.
This distinction shows up in Security+ scenario questions: "An organisation requires users to enter a password and answer a security question. Which statement is true?" The correct answer is that this is single-factor authentication (two instances of something you know) and does not qualify as MFA.
SSO, SAML, and OAuth factor questions
Single sign-on (SSO) reduces the number of authentication prompts but does not reduce the number of factor categories. A user who authenticates to an SSO portal with MFA still uses MFA — the portal then passes the authenticated session to other applications via SAML assertions or OAuth tokens. The factor question is about the initial authentication to the identity provider, not about each individual application.
Practise authentication factor questions
Security+ practice questions on Courseiva include authentication, access control, and identity management scenarios. The identity and access management topic guide covers factor types, AAA frameworks, and common authentication protocols. For a full session, use the Security+ practice test.
Frequently asked questions
Is a hardware security key (like YubiKey) something you have or something you are? Something you have. It is a physical device. Some hardware keys also support biometric unlock (fingerprint on the key), which adds something you are for unlocking the key itself — but the key as an authentication factor is still something you have.
What about knowledge-based authentication (KBA)? KBA — security questions like "what was the name of your first pet?" — is something you know. It is also considered weak because the answers are often publicly discoverable or guessable. The Security+ exam treats KBA as something you know and sometimes contrasts it with stronger factors.
If I use an authenticator app, which factor am I using? Something you have — the device running the app. If the app also requires a biometric or PIN to open, that is an additional factor, but the TOTP code itself represents the device possession.
FIDO2 and Passkeys — Why They're in SY0-701
FIDO2 is the authentication standard behind passkeys and hardware security keys. It is explicitly on the SY0-701 objectives because it represents the replacement for passwords.
How FIDO2 works: FIDO2 uses public-key cryptography for authentication. When you register a FIDO2 credential with a website, your device generates a key pair. The private key stays on your device (never leaves). The website stores only your public key. When you authenticate, the website challenges your device, and your device signs the challenge with the private key. The website verifies the signature with the stored public key.
Why this eliminates phishing: The private key never leaves your device. It is also domain-bound — a phishing site at fake-bank.com cannot receive a valid FIDO2 assertion intended for real-bank.com because the credential is cryptographically bound to the legitimate origin. This is why FIDO2 is considered phishing-resistant authentication.
Passkeys: The consumer-friendly implementation of FIDO2. A passkey is stored on your device (phone, computer) and syncs via the cloud (iCloud Keychain, Google Password Manager). When you sign in, you authenticate to your device (biometric or PIN), and the device handles the FIDO2 cryptographic exchange with the website. No password involved.
Exam question pattern: "An organisation wants to implement phishing-resistant authentication that eliminates passwords entirely." The answer is FIDO2/passkeys. "Which authentication method uses asymmetric cryptography where the private key never leaves the user's device?" FIDO2.
Authentication Protocols
Kerberos: The default authentication protocol in Windows Active Directory environments. Kerberos is a ticket-based system that avoids sending passwords over the network.
The flow: the user authenticates to the Key Distribution Center (KDC). The KDC has two components: the Authentication Server (AS) issues a Ticket Granting Ticket (TGT). The Ticket Granting Server (TGS) issues service tickets for specific services. When the user wants to access a service, they present the TGT to the TGS and receive a service ticket. They present the service ticket to the service — their password was only used at the initial AS exchange.
Exam exam focus: "What does a user present to the Ticket Granting Server to obtain a service ticket?" TGT. "Which Kerberos component issues the initial ticket after the user provides their credentials?" Authentication Server (AS).
RADIUS vs TACACS+: Both provide centralised authentication for network devices.
| Feature | RADIUS | TACACS+ |
|---|---|---|
| Protocol | UDP (ports 1812/1813) | TCP (port 49) |
| Encrypts | Password only | Entire packet |
| AAA separation | Combined | Separate (auth, authz, accounting independent) |
| Vendor | Open standard | Cisco proprietary |
| Best for | Network access (VPN, Wi-Fi) | Device administration |
The critical exam fact: TACACS+ encrypts the entire packet body. RADIUS encrypts only the password. This makes TACACS+ more secure for situations where the full session content is sensitive. The exam asks this directly: "Which protocol encrypts the entire authentication payload rather than just the password?" TACACS+.
The use case distinction: RADIUS is typically used for authenticating users connecting to a network (VPN users, wireless users). TACACS+ is used for authenticating administrators logging into network devices (routers, switches). This distinction appears in exam scenarios.
Certificate-Based Authentication
How smartcard authentication works: The smartcard contains a private key in tamper-resistant hardware (you cannot extract the private key). The card also contains a certificate (public key) signed by the organisation's CA. When the user inserts the card and enters their PIN, the workstation uses the card's private key to sign a challenge from the authentication server. The server verifies the signature using the public key from the certificate.
Two factors: the physical card (something you have) and the PIN (something you know). Smartcard authentication is inherently two-factor.
PIV (Personal Identity Verification) cards: The US government standard for smartcard authentication. PIV cards conform to FIPS 201 and are required for federal employees and contractors accessing government systems. The PIV card contains the user's certificate, private key, and biometric data.
CAC (Common Access Card): The military version of the PIV card. Used by US Department of Defense personnel. Functionally similar to PIV but with additional data fields for military use.
Exam scenario: "A government agency requires all employees to authenticate using a physical card and a PIN before accessing workstations." This describes smartcard/PIV card authentication. The factors involved are something you have (card) and something you know (PIN).
OAuth vs OIDC vs SAML — The Federation Confusion
These three appear together in exam questions and look interchangeable. They are not.
OAuth 2.0: An authorisation framework, not an authentication protocol. OAuth is about granting third-party applications limited access to a resource on your behalf. When you click "Sign in with Google" on a non-Google app, OAuth is what allows you to grant that app access to your Google profile information without giving it your Google password. OAuth issues access tokens, not identity assertions.
OpenID Connect (OIDC): Authentication built on top of OAuth 2.0. OIDC adds the identity layer — it tells the relying party who the user is (not just that they authorised access to something). OIDC issues ID tokens (JWTs) that contain user identity information. "Sign in with Google" for the purpose of establishing who you are uses OIDC. Modern SSO implementations often use OIDC.
SAML (Security Assertion Markup Language): An older XML-based federation standard commonly used in enterprise SSO. SAML issues assertions (statements about the user's identity and attributes). It is widely used for B2B federation and is the foundation of many enterprise SSO solutions (Salesforce, AWS IAM, many SaaS apps support SAML-based SSO).
The one-line exam guide:
- OAuth = authorisation (what can this app do on my behalf?)
- OIDC = authentication on top of OAuth (who is this user?)
- SAML = enterprise federation/SSO, XML-based, common in B2B
Exam scenario: "A developer wants to allow users to log into a mobile app using their existing corporate identity without the app storing passwords." The protocol is OIDC. "An enterprise wants to federate authentication between their HR system and three SaaS applications." SAML.
What Makes a Password Policy Strong — The Specific Numbers the Exam Tests
Length is more important than complexity. A 20-character password of random words ("correct-horse-battery-staple") is stronger than a 10-character password with uppercase, lowercase, numbers, and symbols. NIST SP 800-63B (the current guidance) recommends focusing on length over complexity requirements.
The NIST shift: The old guidance (require uppercase + lowercase + numbers + symbols, change every 90 days) has been revised. NIST now recommends:
- Minimum 8 characters (though 15+ is better practice)
- No mandatory complexity rules
- No mandatory rotation unless there is evidence of compromise
- Check passwords against lists of known compromised passwords
Breach password checking: Modern identity systems check submitted passwords against databases of previously breached passwords (like HaveIBeenPwned's list of billions of compromised credentials). If a user tries to set a password that was compromised in a previous breach, they are prevented from using it — even if it meets all length and complexity requirements. This is explicit in current NIST guidance.
The exam numbers to know:
- Minimum NIST-recommended length: 8 characters
- What security-conscious organisations use: 12–16 characters minimum
- Maximum length NIST recommends supporting: at least 64 characters (do not arbitrarily limit password length)
Account lockout: After a defined number of failed attempts (typically 5–10), accounts should lock or impose increasing delays. This prevents brute force and credential stuffing. The lockout policy is on the exam in the context of protecting passwords.