The operations director's access review said MFA was on. Every named account on the ERP portal showed a second factor. What the review did not say was which of the common types of multi-factor authentication was in use: a six-digit text to the supervisor's phone, including for the night-shift lead who signs into a shared MES terminal where personal phones stay outside the cell.

A phishing page that looks like the portal will collect that text as readily as it collects the password. The helpdesk script for a lost phone sends a new code the same way. Enrollment counts stayed green; authenticator class never appeared.

Two factors is not one checkbox

MFA asks for two different kinds of evidence, not two copies of the same secret. In ordinary language: something the person knows, something they have, something they are. Practitioners call each of those a factor. If the word is new in this strict sense, the check is simple: a password plus a second password is still one kind of evidence.

A password plus a code on a phone is two kinds. A fingerprint that opens the phone so the phone can approve a login is usually an activation of the possession factor, not a third factor sent to the server.

The same three kinds show up in CISA's public guidance, which then says the part most reviews skip: not all combinations give the same protection.

The type of second factor is the control. "MFA enabled" is an enrollment count.

The types you actually meet

SMS, voice, and other last-resort channels

A code arrives by text or a spoken number. It proves, at best, that someone can receive traffic to a phone number. NIST treats use of the public telephone network for that purpose as a restricted authenticator: SIM swap, number porting, and signalling-path interception are ordinary enough that an organization that still accepts SMS must document the risk and offer an unrestricted alternative.

Email as the channel does not even reach that bar. It does not prove possession of a specific device.

On the plant, SMS is convenient for the supervisor who already carries a company mobile. It is useless at the MES kiosk. The night-shift lead cannot receive the text without breaking the phone-off-the-line rule, so someone else's phone becomes the second factor.

That is still MFA on the report.

Authenticator apps — TOTP and approve-push

A time-based one-time password is generated on a device that holds a shared seed, usually after a QR enrollment. The code is not riding the telephone network, which is why it beats SMS for SIM-swap. The user still types the digits into a login form. A lookalike site can relay those digits while they are valid.

Approve-push is the same possession story with less typing. A prompt appears on the phone; the user taps accept. Someone who already has the password can send a flood of those prompts until a tap happens just to make the noise stop. CISA calls that push bombing, or MFA fatigue.

The warning teams notice after a lost phone is simpler: the TOTP seed often lives on the same device used to log in, and replacing it is an enrollment problem, not a cryptography problem.

Number matching — interim, not origin-bound

Number matching asks the user to type digits shown on the login screen into the app before the push will complete. The person has to be looking at that screen. Blind approve-spam stops working.

CISA recommends it when push is what you have and phishing-resistant MFA is not on the floor yet. The same fact sheet says it is not as strong as phishing-resistant MFA. It is an interim.

A live proxy that shows the victim their own login screen still has the numbers. Matching defeats fatigue. It does not bind the approval to the real site.

Cryptographic authenticators — FIDO, passkeys, hardware keys, smart cards

The device signs a challenge tied to the real site. NIST's definition of phishing resistance is the protocol's ability to keep secrets and outputs away from an impostor verifier without depending on the user noticing the fake.

Codes you type do not qualify, because typing does not bind the output to the session. WebAuthn (the browser API behind FIDO2) binds the credential to the verified domain. Smart cards that use client-authenticated TLS bind to the channel. CISA names FIDO/WebAuthn as the widely available phishing-resistant method, with PKI smart cards as the other class.

FIDO uses passkey for any passwordless FIDO credential. Synced passkeys copy through a cloud provider. Device-bound passkeys stay on one authenticator, including a hardware security key.

Biometrics in this design activate the key locally. They are not a face-scan sent to the ERP.

Location and typing rhythm show up on some cheat sheets as extra "factors." In practice they are risk signals that can trigger a stronger prompt. They are not a second factor you can tick instead of a possession authenticator.

The ladder is the control

The published hierarchy is blunt: FIDO or PKI at the top; app or token OTP, or push with number matching, in the middle; SMS and voice last.

NIST's assurance levels put numbers on the same idea. At the level most business apps should treat as the floor (AAL2), the verifier must offer a phishing-resistant option.

At the high-assurance level (AAL3), the authenticator must be phishing-resistant and the private key must be non-exportable. Syncable authenticators are out of AAL3 because the key has to be exportable to sync.

Passkeys did not retire hardware keys.

Synced passkeys can be the right AAL2 offer for people with their own laptops. They are not the AAL3 authenticator for a privileged path.

The fair objection is CISA's own sentence: any MFA is better than none. That sentence is true as a starting enrollment, and it is the sentence that freezes programs on SMS. The same guidance ranks SMS last-resort and tells you to climb.

On this plant the ladder looks like this.

SMS on the ERP portal — last-resort. It fails the kiosk, fails a fake portal, and fails a SIM swap on the supervisor's number.

TOTP or push on the office laptops — better than SMS, still relayable. If push is what you have this quarter, turn on number matching and treat denied prompts as a password incident. CISA is explicit: the MFA check runs after the password succeeded.

The kiosk is the place the office pattern stops fitting. A personal authenticator app assumes a pocket. The cell rule forbids the pocket.

A roaming hardware key at the MES kiosk — possession that does not require a personal phone on the line. The night-shift lead taps or inserts; a PIN or biometric activates the key. That is a type the shared terminal can actually use.

Synced passkeys on the engineering laptops — origin-bound, recoverable through the provider, fine for general workforce if you accept the sync fabric. FIDO's own enterprise split says synced passkeys are insufficient where high assurance is the requirement.

Device-bound keys or smart cards for the people who can reset everyone else — helpdesk, identity admins, the ERP security role. Microsoft's phishing-resistant authentication strength is the policy shape: Windows Hello or platform credential, FIDO2 security key, multifactor certificate-based auth. Phone sign-in is not in that bucket.

Recovery is the second factor you forgot

The night-shift lead drops the hardware key in the drain. The helpdesk script still knows one recovery path: send a code to the supervisor's SMS-enrolled account, then bind a new authenticator. For the length of that call, the strong type is not in use. The restricted type is.

Backup codes in a shared drive are a look-up secret sitting in the same folder as the shift roster. "Add a new phone" by email is enrollment through a channel NIST already refuses as out-of-band authentication.

Lost-key operations are the security of a device-bound authenticator. There is no cloud restore. Someone has to prove identity another way, and that way is usually weaker than the key you just issued.

This quarter: keep number matching on remaining push, and retire SMS on admin, remote access, and ERP security roles. Before the keys arrive: write a lost-key path that is not "text the supervisor," and treat a denied push as a password incident, because that check only runs after the first factor already succeeded.

Microsoft's named list of directory roles that should already be on phishing-resistant MFA is a reasonable private-sector starting set: Global Admin, Helpdesk Admin, Authentication Admin, and the rest of the people who can mint or reset credentials.

Policy on types, not another gadget

What else to employ, once the catalog of gadgets is on the table, is mostly policy on which types a resource will accept. An authentication strength (Entra's name; other IdPs have equivalents) is not another token. It is a grant that says this app may not be satisfied by password-plus-SMS even if the tenant still allows SMS elsewhere.

Listing "passkeys enabled" is not that grant. If attestation is off, synced passkeys remain in the mix, including for people who can reset everyone else.

Pair it with step-up on a sensitive action inside the app if you have authentication context: posting a vendor, changing a payee, exporting the payroll file. The second factor on the morning login is not the same decision as the second factor on that action.

Start with privileged roles, then the shared kiosks that cannot use a personal phone, then synced passkeys for everyone else. Coverage without a named type on those first two is how the dashboard stays green.

The type you named on the kiosk, and the reset you named for when that type is gone, are the MFA program.