Security+ 801 Countdown, T-11: Authentication Modernized With Passkeys, Backup Codes, and Breach Checks

Authentication is the step where a system decides whether the party presenting a credential is the account holder it claims to be. Authenticators are grouped by factor: something you know (a password or PIN), something you have (a phone, a token, or a security key), and something you are (a biometric). Multifactor authentication (MFA) combines at least two factors, but the quality of an MFA design depends less on the count than on whether an attacker who controls a lookalike sign-in page can relay what the user provides. A password can be retyped anywhere, and so can a six-digit code. A passkey cannot, because what it produces is a digital signature that is valid only for the site that issued the challenge.

That distinction, relayable versus origin-bound, organizes the modern authentication toolkit. Passkeys are the phishing-resistant option. One-time passwords (OTPs), whether computed by an app or delivered by SMS, are the middle ground: stronger than a password alone, still relayable. Backup codes exist because every stronger authenticator can be lost, and a recovery path that an impostor cannot trigger is part of the design. Around all of them sits a password policy, which, done well, checks each new password against breach data instead of demanding symbols and periodic rotation. SY0-801 objective 4.5 expands this material, listing passkeys, one-time passwords, backup codes, compromised credential monitoring, account auditing, and a policy report alongside the older token, biometric, and password concepts (CompTIA 2025). The same list keeps Complexity and Expiration among its password best practices, two rules NIST SP 800-63B-4 (July 2025) now forbids, so a candidate needs the exam’s vocabulary and a way to answer when the exam and the standard disagree.

Passkeys and origin binding

A passkey is a public-key credential managed through the Web Authentication (WebAuthn) API. WebAuthn Level 3, a W3C Recommendation dated August 25, 2026, says discoverable credentials are “also called passkeys” (W3C 2026). Registration creates a key pair scoped to a Relying Party ID (RP ID) such as example.com, where the relying party is the website or service that will verify future sign-ins; the server stores only the credential ID and the public key. At sign-in the server sends a random challenge, the browser writes a structure called clientDataJSON containing that challenge and the page’s real origin, and the authenticator signs. FIDO2 adds CTAP, the Client to Authenticator Protocol, for roaming authenticators such as security keys; CTAP 2.3 became a Proposed Standard on February 26, 2026 (FIDO Alliance 2026).

The assertion the server receives, decoded with synthetic values and real hashes:

clientDataJSON = {"type":"webauthn.get","challenge":"jzocDlt9miJExh4PO516UQ","origin":"https://login.example.com","crossOrigin":false}
SHA-256(clientDataJSON) = d370000542d55b6bbfb900cb7c8deb91103e52580261ddb4d591943115e7790b

authenticatorData (37 bytes, no extensions)
  rpIdHash  = a379a6f6eeafb9a55e378c118034e2751e682fab9f2d30ab13d2125586ce1947   # SHA-256("example.com")
  flags     = 0x1D                                                               # UP 0x01 + UV 0x04 + BE 0x08 + BS 0x10
  signCount = 00000000                                                           # legal: no counter kept

signature = Sign(privateKey, authenticatorData || SHA-256(clientDataJSON))

The relying party checks type, challenge, origin, rpIdHash, and flags, then verifies the signature with the stored public key. The security property lives in that origin check. On a lookalike such as login.example-support.com the browser will not use example.com’s credential, because example.com is not a registrable suffix of that origin. An adversary-in-the-middle (AiTM) proxy that relays the real challenge still yields clientDataJSON carrying the proxy’s origin, which the server rejects. NIST calls this verifier name binding (NIST 2025, Sec. 3.2.5); AiTM mechanics are at T-28.

The flags byte deserves a close read. UP (user present) is a touch; UV (user verified) means a PIN or local biometric was required before the key would sign, and NIST treats a credential without UV as single-factor. The biometric template never leaves the device. BE (backup eligible) marks a multi-device passkey that can sync; BS says it has. A device-bound passkey on a security key with a PIN reads 0x05. Authenticators without a counter leave signCount “constant at zero.”

Synced and device-bound passkeys are both phishing-resistant; they differ in assurance. NIST SP 800-63B-4 Appendix B accepts syncable authenticators at authenticator assurance level 2 (AAL2) when the sync fabric encrypts keys at 112-bit strength or better and access to it requires AAL2-equivalent MFA, but “syncable authenticators SHALL NOT be used at AAL3,” which demands a non-exportable key (NIST 2025). Basically, a synced passkey trades some assurance for surviving a lost phone.

“Passwordless” is the umbrella term for sign-in methods that replace the password entirely, and a passkey is the phishing-resistant passwordless method. Microsoft’s authentication methods report counts FIDO2 keys, Windows Hello for Business, and Authenticator phone sign-in under that umbrella (Microsoft n.d.-a), and on May 1, 2025 Microsoft said new Microsoft accounts would be “passwordless by default” (Jakkal and Chik 2025). A password manager is a different tool: it still stores shared secrets. Autofill helps, but a password pasted into a lookalike page is gone.

One-time passwords, tokens, and backup codes

A one-time password is a short code that is valid for a single use or a single time window, derived from a seed shared between the authenticator and the server. HOTP (RFC 4226) computes HMAC-SHA-1 over an event counter and truncates the result to at least six digits. TOTP (RFC 6238) is HOTP with the event counter replaced by a time counter, by default the number of 30-second steps since the Unix epoch (M’Raihi et al. 2005; M’Raihi et al. 2011). The RFC 6238 Appendix B vector, worked by hand:

K        = "12345678901234567890"   (Base32 GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ)
time     = 1111111109               (2005-03-18 01:58:29 UTC)
T        = floor(1111111109 / 30) = 37037036 = 0x00000000023523EC
HMAC     = HMAC-SHA-1(K, T) = 278c02e53610f84c40bd9135acd4101012410a14
offset   = last byte 0x14 & 0x0F = 4
P        = bytes 4..7 = 0x3610f84c & 0x7FFFFFFF = 907081804
6 digits = 907081804 mod 10^6 = 081804
8 digits = 907081804 mod 10^8 = 07081804   (the RFC 6238 table value)

Enrollment delivers the seed as a QR code encoding otpauth://totp/Example:alice@example.com?secret=GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ&issuer=Example&period=30, a de facto vendor format, not an IETF standard (Google n.d.). The seed is the whole secret: whoever copies the QR code or the server’s seed store can mint codes.

A soft token is an authenticator app computing TOTP; a hard token is a dedicated device such as an OATH fob and, by inference, a FIDO2 key. Microsoft’s report uses the same split, “Hardware OATH token” and “Software OATH token” (Microsoft n.d.-a). An SMS code is neither: it is out-of-band delivery over the phone network, NIST’s only “restricted” authenticator, and exposed to SIM swap and SS7 interception (CISA 2022). The deeper limit applies to every OTP, however delivered. NIST states that “OTP authentication is not phishing-resistant,” because a typed code can be relayed within its time step (NIST 2025). CISA ranks FIDO/WebAuthn and PKI first and says SMS or voice “should only be used as a last resort.” When I teach this in ITN 260, I put the two artifacts side by side: six digits a human can retype anywhere, versus a signature valid for one origin.

Backup codes answer a different question: what happens when the primary authenticator is lost. NIST classifies them as look-up secrets: “something you have” even though you type them, not phishing-resistant, at least six digits, accepted once, and stored hashed. NIST’s saved recovery codes carry at least 64 bits of randomness, are kept offline, are replaced after use, and a replacement triggers a notification (NIST 2025, Sec. 3.1.2 and 4.2.1.1). Print or vault them, never in the mailbox they would recover, and alert on any backup-code sign-in (an inference consistent with that notification rule). Pre-issued codes, or a second registered authenticator, also remove the help-desk reset call a social engineer could imitate.

Password policy and NIST SP 800-63B-4

Passwords are not going away, so the objective also lists five classic best-practice settings, Length, Complexity, Reuse, Expiration, and Age, and three newer ones, Compromised credential monitoring, Account auditing, and Policy report. Each of the classic five has a direct counterpart in Active Directory, and NIST SP 800-63B-4 has a position on most of them. The table lines the three up.

Best practice	NIST SP 800-63B-4	Classic AD setting
Length	15 minimum as sole factor; 8 within MFA; SHOULD allow 64 or more	MinPasswordLength (default 7)
Complexity	SHALL NOT impose composition rules	ComplexityEnabled (3 of 4 character types)
Reuse	No requirement	PasswordHistoryCount (default and maximum 24)
Expiration	SHALL NOT force periodic change; SHALL force on compromise	MaxPasswordAge (default 42 days)
Age	No requirement	MinPasswordAge (default 1 day)
Compromised credential monitoring	SHALL check a blocklist, including breach corpuses, at set or change	Entra Password Protection; leaked-credentials detection
Account auditing	No direct counterpart	Search-ADAccount
Policy report	No counterpart	Get-ADDefaultDomainPasswordPolicy

NIST is silent on Reuse and Age, not opposed; minimum age exists only so users cannot cycle through the history back to an old password (Microsoft n.d.-d). The two rules NIST forbids outright are composition requirements and periodic expiration, with one deliberate exception: a change SHALL be forced when a compromise is detected. NIST also requires allowing password managers and autofill, and bans hints, security questions, and truncation (NIST 2025, Sec. 3.1.1.2).

Breach checks without sending the password

Compromised credential monitoring means checking a password against corpuses of leaked credentials, and the engineering problem is doing that without handing the password to anyone. The Have I Been Pwned range API solves it with a prefix query:

$ printf '%s' 'P@ssw0rd' | shasum -a 1
21bd12dc183f740ee76f27b78eb39c8ad972a757  -
$ curl -s https://api.pwnedpasswords.com/range/21BD1 | grep -i '^2DC183F740EE76F27B78EB39C8AD972A757'
2DC183F740EE76F27B78EB39C8AD972A757:6421042

This is k-anonymity: only five hex characters (20 bits) leave the machine, one of 1,048,576 buckets. On October 12, 2026 this bucket returned about 1,924 suffixes, matched locally; the API needs no key (Have I Been Pwned n.d.). The same day, the password Summer2026 with an exclamation mark appended passed a four-character-type rule yet showed 45 breach hits, while quarry-teal-kayak-moss-41 showed zero: the case against composition rules in two lookups. SHA-1 is only a lookup key here; storage is at T-34.

Enterprises run two layers. At set or change time, the NIST blocklist applies; Entra Password Protection implements it with normalization (0 to o, @ to a), edit-distance-1 fuzzy matching, a 5-point minimum score, and up to 1,000 custom terms (Microsoft n.d.-c). Continuously, Entra ID Protection’s “Leaked credentials” detection (leakedCredentials) matches leak data against current password hashes and is always high risk (Microsoft 2026). The first layer is a NIST SHALL; the second goes beyond NIST. On a hit, force a reset and revoke sessions.

Account auditing and the policy report

The remaining two items are about the accounts and the policy itself rather than any single password. In a classic domain, both start from PowerShell:

PS C:\> Get-ADDefaultDomainPasswordPolicy        # trimmed; ComplexityEnabled is this domain's value
ComplexityEnabled           : True
MaxPasswordAge              : 42.00:00:00
MinPasswordAge              : 1.00:00:00
MinPasswordLength           : 7
PasswordHistoryCount        : 24

PS C:\> Search-ADAccount -PasswordNeverExpires -UsersOnly | Format-Table Name,ObjectClass -A
PS C:\> Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly

Account auditing is the last two commands plus the -LockedOut and -AccountDisabled switches: review every inactive, never-expiring, locked, or disabled account (Microsoft n.d.-b). “Policy report” has no CompTIA definition, so this is interpretation: most likely a report of the effective password policy and compliance with it, like the first command’s output or Entra’s Authentication methods activity report. Recertifying permissions is a different control, access review, covered at T-12.

What you need to know for SY0-801

• Passkey: a discoverable FIDO credential, one key pair per site, with an origin-bound signature; that binding makes it phishing-resistant.
• Security key: a hardware device that can hold device-bound passkeys; most passkeys live in phone, OS, or credential-manager stores.
• Synced passkeys (BE set) top out at AAL2; device-bound, non-exportable keys can meet AAL3.
• HOTP counts events, TOTP counts 30-second steps, and both are phishable; SY0-801 lists them under the single term OTP, where SY0-701 named HOTP and TOTP.
• An SMS code is out-of-band delivery and NIST “restricted”; it is neither a hard token nor a soft token.
• Backup code: single use, “something you have” per NIST, stored offline, never in the mailbox it protects.
• Reuse is password history; Age is minimum age, which stops history cycling; Expiration is maximum age.
• Blocklist runs at password change; monitoring watches leak data continuously; account auditing reviews account state; access review recertifies permissions.
• Stem cites NIST or “reduce friction”: pick length, a breach check, MFA, and no forced rotation. Stem says credentials appeared in a breach dump: force a reset.
• Administrators or high-value targets: FIDO2 passkeys, security keys, or PKI smart cards; never SMS, an app code, or a backup code.

Check yourself

These are my own practice questions.

1. After a phishing campaign captured several administrators’ passwords and authenticator-app codes, the CISO wants MFA for privileged accounts that a lookalike sign-in page cannot relay. Which option fits best?

• A. TOTP with a 15-second time step.
• B. SMS codes with SIM-change alerts.
• C. FIDO2 passkeys on hardware security keys.
• D. Push approval with number matching.

Answer: C. The FIDO2 signature covers the RP ID hash and origin, so a relayed challenge fails. The other three rely on a code or prompt a proxy can relay.

2. An engineer’s only security key was lost overseas. The team wants recovery that an impostor on a help-desk call cannot trigger. Which control should have been in place?

• A. Security questions on the account.
• B. Single-use backup codes issued at enrollment and stored offline.
• C. A temporary password emailed to the corporate mailbox.
• D. A longer minimum password age.

Answer: B. Pre-issued backup codes let the owner recover without an identity reset. NIST bars security questions, and an emailed password fails if the mailbox is the target.

3. A team is aligning a web application’s single-factor password policy with NIST SP 800-63B-4. Which policy fits?

• A. Eight-character minimum, required symbol and digit, 90-day expiration.
• B. Fifteen-character minimum, breach-list check at set or change, no periodic expiration.
• C. Twelve-character minimum, security-question reset, 60-day expiration.
• D. Sixty-four-character maximum with truncation of anything longer.

Answer: B. NIST requires 15 characters for a sole-factor password plus a blocklist check, and forbids the others’ composition rules, expiration, security questions, and truncation.

This is T-11 of the Security+ 801 Countdown: one change from SY0-701 to SY0-801 every morning until the new exam launches on November 17, 2026. Tomorrow, T-10: Automation Goes Scenario and AI Joins the SOC Toolkit. New here? Start with T-38: The Blueprint Was Reweighted and Trimmed to 27 Objectives.

References

CISA (Cybersecurity and Infrastructure Security Agency). 2022. Implementing Phishing-Resistant MFA. Fact sheet, October 2022.

CompTIA. 2023. CompTIA Security+ SY0-701 Certification Exam Objectives. Version 5.0.

CompTIA. 2025. CompTIA Security+ SY0-801 V8 Certification Exam Objectives. Document Version 2.0.

FIDO Alliance. 2026. Client to Authenticator Protocol (CTAP), Version 2.3. Proposed Standard, February 26, 2026.

Google. n.d. “Key Uri Format.” Google Authenticator wiki, GitHub. Accessed October 12, 2026.

Have I Been Pwned. n.d. “API Documentation.” Have I Been Pwned. Accessed October 12, 2026.

Jakkal, Vasu, and Joy Chik. 2025. “Pushing Passkeys Forward: Microsoft’s Latest Updates for Simpler, Safer Sign-ins.” Microsoft Security Blog, May 1, 2025.

M’Raihi, D., M. Bellare, F. Hoornaert, D. Naccache, and O. Ranen. 2005. HOTP: An HMAC-Based One-Time Password Algorithm. RFC 4226.

M’Raihi, D., S. Machani, M. Pei, and J. Rydell. 2011. TOTP: Time-Based One-Time Password Algorithm. RFC 6238.

Microsoft. 2026. “What Are Risk Detections?” Microsoft Learn, April 22, 2026.

Microsoft. n.d.-a. “Authentication Methods Activity.” Microsoft Learn. Accessed October 12, 2026.

Microsoft. n.d.-b. “Search-ADAccount.” Microsoft Learn. Accessed October 12, 2026. See also Set-ADDefaultDomainPasswordPolicy.

Microsoft. n.d.-c. “Password Protection in Microsoft Entra ID.” Microsoft Learn. Accessed October 12, 2026.

Microsoft. n.d.-d. “Minimum Password Age.” Microsoft Learn. Accessed October 12, 2026.

NIST (National Institute of Standards and Technology). 2025. Digital Identity Guidelines: Authentication and Authenticator Management. NIST Special Publication 800-63B-4.

W3C (World Wide Web Consortium). 2026. Web Authentication: An API for Accessing Public Key Credentials, Level 3. W3C Recommendation, August 25, 2026.