This contributor profile is a placeholder and is kept out of search indexes until a real, verifiable bio is added.
[REVIEWER BIO: credentials and hands-on identity architecture experience.]
Expertise: Identity architecture, FIDO2, Carrier APIs
Field guide
Inventory every flow that sends a code, write the risk assessment NIST SP 800-63B-4 asks for, fix account recovery and new-payee setup first, then move customers to phishing-resistant or device-bound methods such as passkeys and in-app approval. Keep SMS only as a restricted fallback, with a dated plan to remove it.
Field guide
The durable fix is to remove the code the bot asks for, using passkeys, in-app approval on a registered device or network-based verification. While codes remain, say in every message what the code approves and that the bank will never ask for it, and treat a new-device sign-in during an inbound call as a strong fraud signal.
Field guide
Decide which passkeys you accept for which customers, offer enrollment right after a strong sign-in, make passkeys the default for returning users, and design account recovery that doesn’t fall back to an SMS code. Keep a non-SMS alternative for customers who can’t use passkeys, and a device-bound option for staff and other high-risk users.
Field guide
Map every authenticator you use to NIST’s assurance levels, identify the restricted ones (SMS and voice codes), and for each restricted authenticator document a risk assessment, user notice, a non-restricted alternative and a migration plan. Add a phishing-resistant option such as passkeys, which Revision 4 accepts at AAL2.
Field guide
Treat the account as compromised until proven otherwise: stop trusting the phone number, revoke sessions, hold new payees and contact-detail changes, and reach the customer through a channel that isn’t the hijacked number. Then help them reclaim the number from their carrier, review everything that changed during the exposure window, and re-enroll them with a method that doesn’t depend on SMS.
Buyer’s guide
Phishing-resistant MFA is authentication that a fake site or man-in-the-middle can’t capture and replay, because the credential is cryptographically bound to the real site. FIDO2 passkeys and hardware security keys are the common examples, and CISA also counts PKI-based smart cards. SMS codes, authenticator-app codes and simple push approvals are not phishing-resistant.
Buyer’s guide
The most direct signal comes from the mobile operator: a SIM swap check reports whether the SIM tied to a number changed recently, and number verification confirms a request comes from that SIM. The CAMARA project standardizes both APIs. Banks combine them with their own device and session signals, and use them before trusting a number for recovery, new payees or high-risk payments.
Buyer’s guide
There is no single best alternative for every flow. Passkeys are the most widely standardized phishing-resistant option and are accepted by NIST at AAL2. In-app approval on a registered device is what UAE and Singapore banks moved customers to. Carrier network checks are useful risk signals, and SIM-based cryptographic methods are emerging. Most organizations combine two or more.
Vendor brief
Glide Identity(owner interest: see disclosure), a US company that trades as Glide.id, says its MagicalAuth product replaces SMS codes with verification through the mobile network, and in August 2026 it announced a beta across AT&T, T-Mobile and Verizon. Before a pilot, get written answers on how the method would be classified under NIST SP 800-63B-4, when and how fallback triggers, which devices, operating systems and plans are covered, how SIM swaps and eSIM transfers are handled, what data is processed, what it costs and how you would leave. We found no independent security assessment in our sources.
Explainer
NIST SP 800-63-4 does not ban SMS one-time passcodes. It classifies SMS and voice codes as “restricted” authenticators: still allowed, but only if the organization assesses the risk, tells users about it, offers at least one non-restricted alternative, and keeps a plan to migrate away.
Explainer
Carrier-based authentication verifies a user through their mobile operator instead of sending them a code. The simplest form checks that a request comes from the SIM tied to a phone number; stronger forms use cryptographic keys held in the SIM to sign the request.
Explainer
Yes. A passkey is bound to the website it was created for, so it can’t be entered on a look-alike site. NIST’s 800-63-4 update accepts synced passkeys at AAL2. The main new risk is the account that syncs them, which needs strong protection of its own.