Multifactor authentication, passwords and passkeys

Objective 4.5 is identity and access management. The previous lesson took the account itself -- provisioning, account types, federation, access models and reviews. This one takes how an account proves it is being used by its owner: the second factor, the password and its replacements, the monitoring that notices when a credential has leaked, and the privileged rights that should not exist until someone needs them.

Why this matters

MFA is the highest-value single control on this exam. It is the answer to password spraying, credential stuffing, offline cracking and most phishing that ends in a typed password (lesson 17), because it makes a stolen password insufficient on its own.

Password guidance is where the exam has moved and a lot of older study material has not. Forced composition rules and routine 90-day expiry are no longer current practice, and answering from habit costs marks. The newer items -- passkeys, backup codes, breached-credential monitoring -- reward knowing what each one actually removes from an attacker's options.

The lesson

Hard and soft tokens, one-time passwords, biometrics and backup codes

Multifactor means factors from different categories: something you know, something you have, something you are. A password plus a security question is not MFA -- both are things you know, and one phishing page or one breach gets both. Read the options for the category, not the count.

One-time passwords (OTP) are codes valid once. Two schemes matter:

• HOTP -- HMAC-based, driven by a counter that advances each time a code is generated. A code stays valid until used, which is its weakness.
• TOTP -- time-based, derived from a shared secret and the current time window, commonly 30 seconds. Codes expire on their own, which is why authenticator apps use it.

Where the code lives decides the token type:

• Soft tokens are software -- an authenticator app on a phone. No SIM to swap, works offline, cheap. Still phishable: a user can be persuaded to type the code into a fake page, which relays it in real time.
• Hard tokens are dedicated hardware: a key-fob that shows a code, a smart card, or a FIDO2 key that answers a cryptographic challenge instead of showing a code. The challenge-response kind is phishing-resistant; the code-showing kind is not.
• SMS codes are the weakest common option, defeated by SIM swapping, interception and simply asking the user to read the code out over the phone.
• Push approvals are convenient and open to MFA fatigue -- repeated prompts until one is accepted. Number matching, where the user types a number shown on the real login screen, is the mitigation.

Biometrics are something you are. Know the error rates: false acceptance rate (FAR) admits an impostor (the security failure); false rejection rate (FRR) refuses the real user (the usability failure); the crossover error rate (CER) is where they meet, and a lower CER is a better system. Tightening sensitivity lowers FAR and raises FRR. A biometric cannot be changed if compromised, which is why good implementations keep a template in secure hardware on the device and never send the biometric itself anywhere.

Backup codes are a set of single-use recovery codes issued when MFA is enrolled, for the day the phone is lost. Each works once. Treat them as credentials: stored offline or in a password manager, never in a note on the phone they back up, and regenerated (which invalidates the old set) after any are used. A recovery path weaker than the MFA it bypasses is the hole attackers look for, which is why help-desk MFA resets need proper identity proofing.

Password length, complexity, reuse, expiration and age, stated as current guidance

The exam follows the modern position, set out in NIST's digital identity guidelines (SP 800-63B), which reversed several long-standing habits because the old rules produced predictable passwords.

• Length is the dominant factor. Long passphrases beat short complex strings. Set a long minimum, allow a generous maximum (the guidance says at least 64 characters), and accept spaces and all printable characters.
• Complexity rules -- one capital, one digit, one symbol -- produce Password1! and its relatives. Current guidance says not to impose composition rules and to screen new passwords against a blocklist of breached, common and context-specific values (the company name, the product name) instead.
• Reuse is the real enemy, because credential stuffing depends on it entirely. Prevent it with SSO, a password manager and breached-password screening; keep a password history so users cannot cycle back.
• Expiration -- routine forced changes are no longer recommended. They drive predictable increments (Summer2026!, then Autumn2026!) and help-desk load without stopping anything. Force a change on evidence of compromise.
• Age -- a minimum password age stops someone changing their password several times in a row to get back to the old one past the history check. It only matters where history is enforced, and it should not block a change after a suspected compromise.

Lockout belongs here too: it stops brute force against one account and does nothing against spraying, which tries one password across many accounts and is caught in aggregate instead.

Passkeys, password managers and passwordless, and what each actually removes

• Password managers generate a long, unique password for every site and fill it in. They remove reuse and weak choice, and because they fill only on the matching site they also blunt some phishing. They concentrate risk in one vault, so the vault needs a strong master passphrase and MFA. On balance the exam treats them as the recommended answer.
• Passkeys are FIDO2/WebAuthn credentials: a key pair created per site, with the private key kept on the user's device or hardware key (or synced between the user's devices by their platform or password manager) and unlocked by a PIN or biometric. The site stores only the public key. That removes three things at once: there is no shared secret on the server to steal, there is nothing to type into a fake page, and the signature is bound to the real site's origin, so a look-alike domain gets no answer. That last property is what "phishing-resistant" means.
• Passwordless is the wider goal of signing in with no password at all -- a passkey, a certificate on a smart card, or a device-bound biometric unlock. It removes guessing, spraying, stuffing and cracking as attack routes against that account. It does not remove session theft after login, or a weak account-recovery process, which become the places to look.

Exam reading: if a scenario asks how to stop credential phishing outright, the answer is a passkey, FIDO2 hardware key or certificate-based authentication -- not a better code.

Compromised-credential monitoring, account auditing and the password policy report

Good policy is not evidence that accounts follow it. Three activities close the gap.

Compromised-credential monitoring checks whether the organisation's credentials have appeared in breach data. It works in two directions: new and existing passwords are compared against known-breached password lists (services such as Have I Been Pwned's password list allow this without sending the password itself), and the organisation's email domain is watched for appearances in breach dumps. Identity platforms can raise a risk signal on a leaked credential and force a reset. This is what makes "change on evidence of compromise" workable: it supplies the evidence.

Account auditing reviews the accounts themselves, not their passwords: dormant accounts that have not signed in for months, accounts that have never signed in, accounts set never to expire, accounts with no MFA enrolled, shared accounts, unexpected members of privileged groups, and service accounts allowed to log on interactively. Each is a finding with an owner and a fix.

The password policy report is what management and auditors read. It shows how far reality matches policy: MFA enrolment (and phishing-resistant enrolment), exemptions and why, old or non-expiring passwords, passwords found in breach lists during an authorised audit, and lockout and reset volumes. Its value is the trend; a report nobody acts on is not a control.

Just-in-time privilege, and the standing admin rights it replaces

The usual attack path is: compromise a user, escalate, then move laterally as an administrator. Standing privilege -- admin rights held permanently, whether needed today or not -- is what makes the middle step easy, because a privileged credential is always there to capture.

Just-in-time (JIT) privilege removes it. Administrators hold ordinary accounts. When they need elevation they request it, often with a reason or a ticket reference; it is approved (automatically for low-risk roles, by a second person for high-impact ones), granted for a fixed period, and removed automatically when the period ends. An attacker who takes over the person's everyday identity gets an ordinary user, and every elevation leaves a record of who, what, when and why.

JIT sits inside wider privileged access management:

• separate admin accounts, so privileged work never happens from the account that reads email;
• privileged credentials held centrally and rotated after use, so a person does not keep knowing a shared admin password;
• session recording and approval workflows for high-impact actions;
• break-glass accounts kept outside the JIT system for the day it fails, and alerted on whenever used (lesson 36).

When a scenario describes permanent admin rights rarely used, or escalation via an always-on admin account, the answer is JIT.

What to take into the exam

• Multifactor needs different categories; password plus security question is one factor.
• HOTP counts, TOTP uses the clock; soft and code-showing hard tokens are phishable, SMS is weakest, number matching answers MFA fatigue.
• Backup codes are single-use credentials; the recovery path must not be weaker than the MFA.
• Current password guidance: length over complexity, screen against breached lists, no routine expiry -- change on evidence of compromise.
• Passkeys remove the server-side secret and are bound to the real site's origin, which is why they resist phishing.
• Breached-credential monitoring supplies the evidence; account audits and the policy report show whether policy is real.
• JIT replaces standing admin rights with time-boxed, approved, logged elevation.