# Cleartext: full text Generated 2026-10-20. Owned by [OWNER ENTITY]; financial interests: https://glide-cleartext.pages.dev/about/ownership-and-funding/ # Are synced passkeys phishing-resistant? > **Short answer:** Yes. A passkey is bound to the website it was created for, so the browser won’t offer it to a look-alike phishing site, and there is no code to read out. NIST SP 800-63B-4 accepts synced passkeys at AAL2. The new risk moves to the account that syncs them, which needs strong protection of its own. - URL: https://glide-cleartext.pages.dev/q/are-synced-passkeys-phishing-resistant/ - Last verified: 2026-09-05 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## Why passkeys resist phishing A passkey is a key pair. The website stores the public key; the private key stays with the user. When the user signs in, the browser checks the site’s domain and only offers the passkey registered for that exact domain.[^3] A phishing page on a look-alike domain never receives a credential it could replay, and there is no code for an attacker to ask the user to read out.[^1] ## What syncing changes Synced passkeys are copied across the user’s devices through a provider such as Apple, Google or a password manager. That fixes the biggest usability problem of device-bound credentials, losing the device, but it moves part of the risk to the sync account. If an attacker takes over that account, they may be able to restore the user’s passkeys to a device they control. ## How NIST treats them NIST’s 800-63-4 guidelines accept synced passkeys at authentication assurance level 2 (AAL2), the level most consumer and banking logins target.[^1][^2] High-assurance use cases that require AAL3 still call for hardware-bound keys. Compare the two: [synced vs device-bound passkeys](https://glide-cleartext.pages.dev/compare/synced-vs-device-bound-passkeys/). ## What this means for you ### Banks & credit unions Synced passkeys meet the assurance level most retail banking logins target, and they are the easiest phishing-resistant option to roll out to customers. Keep device-bound keys for staff with administrative access. ### Fintechs & payment firms Offer passkeys as the default for returning users. Watch account recovery closely, because that is where passkey deployments get attacked. ### Developers & identity teams Use the WebAuthn API and let the platform handle syncing. Don’t fall back to SMS codes in recovery, or you reintroduce the weakness passkeys removed. ## Follow-up questions **What is the difference between a synced and a device-bound passkey?** A synced passkey is backed up and copied across a user’s devices by a provider such as Apple, Google or a password manager. A device-bound passkey never leaves the hardware it was created on, such as a security key. **Can a phishing site trick a passkey?** No. The browser only offers a passkey to the domain it was registered for, so a look-alike domain gets nothing to relay. ## Sources [^1]: NIST cites phishing resistance of synced passkeys in digital identity guidelines update. FIDO Alliance. https://fidoalliance.org/nist-cites-phishing-resistance-of-synced-passkeys-in-digital-identity-guidelines-update/ (secondary) [^2]: SP 800-63B-4: Authentication and Authenticator Management. NIST. https://pages.nist.gov/800-63-4/sp800-63b.html [^3]: Web Authentication: An API for accessing Public Key Credentials. W3C. https://www.w3.org/TR/webauthn/ ## Related questions - [What is phishing-resistant MFA?](https://glide-cleartext.pages.dev/q/what-is-phishing-resistant-mfa/) - [Is SMS OTP still allowed under NIST SP 800-63-4?](https://glide-cleartext.pages.dev/q/is-sms-otp-still-allowed-under-nist-800-63-4/) - [How do banks stop OTP bots?](https://glide-cleartext.pages.dev/q/how-do-banks-stop-otp-bots/) ## Cite Cleartext. “Are synced passkeys phishing-resistant?” Last verified 2026-09-05 (rev. 1). https://glide-cleartext.pages.dev/q/are-synced-passkeys-phishing-resistant/ ## Changelog - 2026-09-05: First published. --- # Did the UAE ban SMS OTP for banking? > **Short answer:** Yes, in effect. The Central Bank of the UAE directed licensed financial institutions to phase out one-time passcodes sent by SMS and email, starting in July 2025 with a deadline of March 31, 2026. Banks moved customers to verification inside their own mobile apps on devices the bank had registered. - URL: https://glide-cleartext.pages.dev/q/did-the-uae-ban-sms-otp-for-banking/ - Last verified: 2026-09-23 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## What the UAE required The Central Bank of the UAE told licensed financial institutions to stop relying on one-time passcodes sent by SMS or email to authenticate customers. The phase-out began in July 2025, with a deadline of March 31, 2026.[^1][^2] ## What replaced the codes Banks moved customers to verification inside their own mobile apps: the customer confirms a login or payment in the app on a device the bank has already registered, instead of typing a code from a text message.[^1] ## Why it matters outside the Gulf Most regulators describe outcomes and leave the method to banks. Here the regulator named the method to retire and set a date.[^3] - **A defined deadline** forced the migration to the top of bank roadmaps. - **Email went with SMS,** because both can be phished or intercepted. - **The replacement was already in customers’ hands:** moving approval into the bank’s own app avoided a new device or login habit. ## What this means for you ### Banks & credit unions The UAE is a finished case study: a named method, a fixed date and a replacement customers already had. The timeline was months, not years. ### Fintechs & payment firms If you serve UAE customers through a partner bank, expect the partner to require app-based or other non-code verification for your flows too. ### Developers & identity teams In-app approval needs a device-registration step you trust. The strength of the whole scheme depends on how that registration is protected. ## Follow-up questions **Did the UAE rule include email codes?** Yes. SMS and email one-time passcodes were phased out together. ## Sources [^1]: UAE banks cancel OTPs, switching to in-app verification. The Paypers. https://thepaypers.com/fraud-and-fincrime/news/uae-banks-cancel-otps-switching-to-in-app-verification (secondary) [^2]: UAE central bank tells FIs to drop SMS OTP authentication. BankInfoSecurity. https://www.bankinfosecurity.com/uae-central-bank-tells-fis-to-drop-sms-otp-authentication-a-28589 (secondary) [^3]: Countries phasing out SMS OTPs for online banking security. Gulf News. https://gulfnews.com/business/banking/countries-phasing-out-sms-otps-for-online-banking-security-1.500209725 (secondary) ## Related questions - [Which countries are banning SMS OTP for banking?](https://glide-cleartext.pages.dev/q/which-countries-are-banning-sms-otp/) - [Is email OTP safer than SMS OTP?](https://glide-cleartext.pages.dev/q/is-email-otp-safer-than-sms/) - [Has any US regulator banned SMS OTP?](https://glide-cleartext.pages.dev/q/has-any-us-regulator-banned-sms-otp/) ## Cite Cleartext. “Did the UAE ban SMS OTP for banking?” Last verified 2026-09-23 (rev. 1). https://glide-cleartext.pages.dev/q/did-the-uae-ban-sms-otp-for-banking/ ## Changelog - 2026-09-23: First published. --- # Do US banks have to follow NIST SP 800-63? > **Short answer:** Not directly. NIST SP 800-63 is written for US federal agencies, and no banking regulator has adopted it as a rule for banks. In practice examiners, auditors and security teams use it as the benchmark for authentication strength, while the FFIEC’s 2021 guidance asks banks to match controls to risk rather than prescribing methods. - URL: https://glide-cleartext.pages.dev/q/do-us-banks-have-to-follow-nist-800-63/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## Who the guidelines bind The Digital Identity Guidelines set requirements for US federal agencies that authenticate people to government systems.[^1] Banks are supervised by banking regulators, and the Federal Financial Institutions Examination Council (FFIEC) coordinates the examination standards those regulators use.[^2] ## What the FFIEC expects instead The FFIEC’s August 2021 guidance, *Authentication and Access to Financial Institution Services and Systems*, is written in terms of risk, not methods.[^2] It asks institutions to assess the threats to each customer and employee access path and to apply controls that match. It does not name SMS codes, passkeys or any other technology as required or forbidden. ## Why NIST still matters to banks When an examiner, auditor or board asks how strong a login is, NIST’s authentication assurance levels are the common yardstick. NIST also moves first: its classification of SMS codes as restricted is the most-cited US reference point in arguments about retiring them.[^1] See [is SMS OTP still allowed under NIST 800-63-4?](https://glide-cleartext.pages.dev/q/is-sms-otp-still-allowed-under-nist-800-63-4/). ## What this means for you ### Banks & credit unions Expect to be asked how your authentication compares with NIST even though you aren’t bound by it. Mapping each login and step-up flow to an assurance level (AAL1–AAL3) gives examiners a common vocabulary. ### Fintechs & payment firms If you partner with a bank, its vendor-risk team will likely use NIST terms in due diligence. Having your own mapping ready shortens that process. ### Developers & identity teams Use NIST’s assurance levels as the design target for each flow. They translate into concrete requirements, such as which authenticator types are acceptable at AAL2. ## Follow-up questions **What does the FFIEC 2021 guidance replace?** It superseded the FFIEC’s 2005 guidance on authentication in internet banking and its 2011 supplement. ## Sources [^1]: SP 800-63-4: Digital Identity Guidelines. NIST. https://pages.nist.gov/800-63-4/ [^2]: Authentication and Access to Financial Institution Services and Systems. FFIEC, 2021-08-11. https://www.ffiec.gov/news/press-releases/2021/pr-08-11 ## Related questions - [Is SMS OTP still allowed under NIST SP 800-63-4?](https://glide-cleartext.pages.dev/q/is-sms-otp-still-allowed-under-nist-800-63-4/) - [Has any US regulator banned SMS OTP?](https://glide-cleartext.pages.dev/q/has-any-us-regulator-banned-sms-otp/) - [What does “restricted authenticator” mean in NIST SP 800-63B-4?](https://glide-cleartext.pages.dev/q/what-does-restricted-authenticator-mean-in-nist-800-63b/) ## Cite Cleartext. “Do US banks have to follow NIST SP 800-63?” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/q/do-us-banks-have-to-follow-nist-800-63/ ## Changelog - 2026-09-24: First published. --- # Has any US regulator banned SMS OTP? > **Short answer:** No. As of this answer’s verification date, no US regulator has ordered banks or apps to stop using SMS one-time passcodes. NIST classifies them as restricted, the FCC’s 2023 rules make SIM swaps harder at carriers, and FFIEC guidance is risk-based. The bans so far are elsewhere, in markets such as the UAE and the Philippines. - URL: https://glide-cleartext.pages.dev/q/has-any-us-regulator-banned-sms-otp/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## The three US levers | Body | What it did | Binding on banks? | |---|---|---| | NIST | Classified SMS and voice OTP as restricted authenticators in SP 800-63B-4[^1] | No; written for federal agencies | | FCC | Required wireless carriers to authenticate customers before SIM changes and port-outs (FCC 23-95)[^2] | No; applies to carriers | | FFIEC | Issued authentication guidance framed around risk, not named methods (2021)[^3] | Supervisory guidance | Table: US federal actions that bear on SMS one-time passcodes. ## Where bans have happened Regulators outside the US have been direct. The Central Bank of the UAE set a deadline of March 31, 2026 for banks to stop using SMS and email codes,[^4] and the Philippines barred them for high-risk transactions from June 25, 2026.[^5] The full list, with sources, is in [which countries are banning SMS OTP](https://glide-cleartext.pages.dev/q/which-countries-are-banning-sms-otp/) and the [regulation tracker](https://glide-cleartext.pages.dev/regulations/). ## What would change this answer A rule from a US banking regulator that names SMS codes, or a future NIST revision that removes them from the permitted list. Cleartext re-verifies this answer whenever either body publishes new authentication guidance. ## What this means for you ### Banks & credit unions The absence of a ban is not a safe harbor. NIST’s conditions, examiner expectations and fraud losses create pressure without a rule; plan the migration on your own timeline rather than a regulator’s. ### Fintechs & payment firms If you operate in the UAE, the Philippines, Singapore or Malaysia as well as the US, design for the strictest market. A single authentication stack is cheaper than one per jurisdiction. ### Developers & identity teams Build SMS so it can be switched off per flow and per market with configuration, not a release. Regulators abroad have given banks months, not years. ## Follow-up questions **Will the US follow the UAE and ban SMS codes?** No US regulator has signaled a ban. US banking regulators rarely name a technology, so pressure is more likely to come through guidance, examinations and fraud-liability rules than a direct prohibition. ## Sources [^1]: SP 800-63B-4: Authentication and Authenticator Management. NIST. https://pages.nist.gov/800-63-4/sp800-63b.html [^2]: Protecting Consumers from SIM Swap and Port-Out Fraud. Federal Register, 2023-12-08. https://www.federalregister.gov/documents/2023/12/08/2023-26338/protecting-consumers-from-sim-swap-and-port-out-fraud [^3]: Authentication and Access to Financial Institution Services and Systems. FFIEC, 2021-08-11. https://www.ffiec.gov/news/press-releases/2021/pr-08-11 [^4]: UAE banks cancel OTPs, switching to in-app verification. The Paypers. https://thepaypers.com/fraud-and-fincrime/news/uae-banks-cancel-otps-switching-to-in-app-verification (secondary) [^5]: No more SMS, email OTPs for high-risk financial transactions starting June 25. GMA News. https://www.gmanetwork.com/news/money/economy/992561/no-more-sms-email-otps-for-high-risk-financial-transactions-starting-june-25/story/ (secondary) ## Related questions - [Which countries are banning SMS OTP for banking?](https://glide-cleartext.pages.dev/q/which-countries-are-banning-sms-otp/) - [Is SMS OTP still allowed under NIST SP 800-63-4?](https://glide-cleartext.pages.dev/q/is-sms-otp-still-allowed-under-nist-800-63-4/) - [What does the FCC SIM swap rule require?](https://glide-cleartext.pages.dev/q/what-does-the-fcc-sim-swap-rule-require/) - [Do US banks have to follow NIST SP 800-63?](https://glide-cleartext.pages.dev/q/do-us-banks-have-to-follow-nist-800-63/) ## Cite Cleartext. “Has any US regulator banned SMS OTP?” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/q/has-any-us-regulator-banned-sms-otp/ ## Changelog - 2026-09-24: First published. --- # How can banks defend against SIM swap fraud? > **Short answer:** Stop treating an SMS code as proof of identity for high-risk actions such as password resets, new payees and contact-detail changes. Check whether the customer’s SIM changed recently before trusting the number, offer phishing-resistant sign-in such as passkeys, and send alerts about sensitive changes to a channel the attacker doesn’t control. - URL: https://glide-cleartext.pages.dev/q/how-can-banks-defend-against-sim-swap-fraud/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## Where SIM swaps cash out A SIM swap is a means to an end. The losses happen in the flows that trust the phone number: password and account recovery, adding a new payee, raising a transfer limit, and changing the email or phone number on file. Those are the flows to harden first. ## Controls, strongest first | Control | What it stops | Limits | |---|---|---| | Passkeys or device-bound credentials | The phone number stops being the key to the account | Recovery must not fall back to SMS | | SIM-change signal from the carrier | Flags a number whose SIM changed recently, before you trust it | A risk signal, not an authenticator; coverage depends on the carrier | | Cooling-off period after a new SIM or device | Buys time for the real customer to notice | Adds friction for legitimate changes | | Alerts on a second channel | Tells the victim about changes the attacker made | Alerts can be missed or ignored | Table: Cleartext’s summary of common controls. Carrier network APIs standardized by the CAMARA project include a SIM Swap API that reports whether a number’s SIM changed recently.[^2] ## What the carrier side now covers Since the FCC’s 2023 order, US carriers must authenticate customers before a SIM change or port-out and notify them of the request.[^1] That reduces the attack rate but doesn’t remove the exposure: NIST still classifies SMS codes as restricted because the channel itself can be redirected or phished.[^3] ## What this means for you ### Banks & credit unions Start with account recovery and new-payee setup, where SIM-swap fraud tends to cash out. Those two flows justify the most friction and the strongest authenticators. ### Fintechs & payment firms A SIM-change signal is cheap to add to a risk engine and catches the most common pattern: a new SIM, then a login from a new device, then a withdrawal. ### Developers & identity teams Record when each user’s phone number was last verified and when the carrier last reported a SIM change. Both belong in the decision to accept an SMS code. ## Follow-up questions **Don’t the FCC rules solve this?** They make SIM swaps harder at US carriers, but a bank that treats an SMS code as proof of identity is still exposed to insiders, to carrier account takeover and to phishing of the code itself. ## Sources [^1]: Protecting Consumers from SIM Swap and Port-Out Fraud. Federal Register, 2023-12-08. https://www.federalregister.gov/documents/2023/12/08/2023-26338/protecting-consumers-from-sim-swap-and-port-out-fraud [^2]: CAMARA project. Linux Foundation. https://camaraproject.org/ [^3]: SP 800-63B-4: Authentication and Authenticator Management. NIST. https://pages.nist.gov/800-63-4/sp800-63b.html ## Related questions - [What is a SIM swap attack?](https://glide-cleartext.pages.dev/q/what-is-a-sim-swap-attack/) - [What is carrier-based authentication?](https://glide-cleartext.pages.dev/q/what-is-carrier-based-authentication/) - [Are synced passkeys phishing-resistant?](https://glide-cleartext.pages.dev/q/are-synced-passkeys-phishing-resistant/) - [How do banks stop OTP bots?](https://glide-cleartext.pages.dev/q/how-do-banks-stop-otp-bots/) ## Cite Cleartext. “How can banks defend against SIM swap fraud?” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/q/how-can-banks-defend-against-sim-swap-fraud/ ## Changelog - 2026-09-24: First published. --- # How do banks stop OTP bots? > **Short answer:** Remove the code the bot asks for: passkeys, in-app approval on a registered device and network-based checks leave the customer nothing to read out. Where a code remains, say in the message exactly what it approves and that the bank will never ask for it, and treat a new-device login during an inbound call as a fraud signal. - URL: https://glide-cleartext.pages.dev/q/how-do-banks-stop-otp-bots/ - Last verified: 2026-09-01 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## Remove the code An OTP bot only works if there is a code to ask for. Passkeys, in-app approval on a registered device and network-based verification leave the customer nothing to read out.[^1] Phishing-resistant methods also defeat the fake-website version of the same attack.[^2] ## If a code is unavoidable - **Put context in the message:** say what the code approves (“to add payee J. Smith”) and that the bank will never ask for it. - **Watch the timing:** a login from a new device while the customer is on an inbound call is a strong fraud signal. - **Shorten the window:** the shorter a code is valid, the less time a bot has to relay it. ## Where to start Start with the flows where a relayed code does the most damage: new-device login, new payees and limit increases. For a full program, see [migrate a bank off SMS OTP](https://glide-cleartext.pages.dev/checklists/migrate-a-bank-off-sms-otp/). ## What this means for you ### Banks & credit unions Prioritize the flows the bots target: login from a new device, adding a payee and raising limits. Those are where removing the code has the biggest effect. ### Fintechs & payment firms In-app approval on a device you registered earlier is often the fastest replacement to ship, because customers already have your app. ### Developers & identity teams Make code messages specific: the action, the payee or amount, and a warning. “Your code to add payee J. Smith is 481 223. We will never call you to ask for it.” ## Follow-up questions **Does customer education stop OTP bots?** It helps at the margin, but the calls are timed to arrive with a real code and sound official. Removing the code is more reliable than asking customers to spot the scam. ## Sources [^1]: One-time passcodes are gateway for financial fraud attacks. BankInfoSecurity, 2026-04-03. https://www.bankinfosecurity.com/one-time-passcodes-are-gateway-for-financial-fraud-attacks-a-31341 (secondary) [^2]: Implementing Phishing-Resistant MFA (fact sheet). CISA, 2022-10. https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf ## Related questions - [What is an OTP bot?](https://glide-cleartext.pages.dev/q/what-is-an-otp-bot/) - [What is phishing-resistant MFA?](https://glide-cleartext.pages.dev/q/what-is-phishing-resistant-mfa/) - [Are synced passkeys phishing-resistant?](https://glide-cleartext.pages.dev/q/are-synced-passkeys-phishing-resistant/) - [How can banks defend against SIM swap fraud?](https://glide-cleartext.pages.dev/q/how-can-banks-defend-against-sim-swap-fraud/) ## Cite Cleartext. “How do banks stop OTP bots?” Last verified 2026-09-01 (rev. 1). https://glide-cleartext.pages.dev/q/how-do-banks-stop-otp-bots/ ## Changelog - 2026-09-01: First published. --- # How do I know if I’ve been SIM swapped? > **Short answer:** The clearest sign is that your phone suddenly loses service where coverage is normally fine, and calls and texts stop arriving. Other signs are a carrier notice about a SIM change or number transfer you didn’t request, and password-reset or new-login alerts from accounts you didn’t touch. Contact your carrier from another phone immediately. - URL: https://glide-cleartext.pages.dev/q/how-do-i-know-if-i-have-been-sim-swapped/ - Last verified: 2026-09-10 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## Signs to look for - **Sudden loss of service:** no bars, no calls and no texts where your phone normally works. Your SIM stops working when the number is moved to someone else’s. - **A carrier notice you didn’t expect:** a message or email about a SIM change, a new eSIM, or a request to transfer your number to another carrier. - **Security alerts from other accounts:** password-reset emails, “new sign-in” notices or one-time passcodes you didn’t request. ## Why carrier notices are the early warning The FCC’s 2023 rules require US wireless carriers to notify customers promptly when a SIM change or port-out is requested on their account.[^1] That notice may be the first thing you see, so read carrier messages about account changes rather than dismissing them. ## What to do first Call your carrier from another phone to stop the transfer and recover your number, then secure your email account, because that is where password resets for everything else land. In the US, the FTC’s IdentityTheft.gov builds a recovery plan and report.[^2] Step by step: [respond to a SIM swap](https://glide-cleartext.pages.dev/checklists/respond-to-a-sim-swap/). ## What this means for you ### Banks & credit unions A customer reporting a sudden loss of phone service may be describing a SIM swap in progress. Route those calls to fraud, not general support, and review recent logins, payee additions and contact-detail changes. ### Fintechs & payment firms Give users a fast way to freeze their account from a second device or by email. The first minutes after a SIM swap are when funds move. ### Developers & identity teams Send security alerts to more than one channel. If the only alert for a password reset goes by SMS, a SIM-swapped user never sees it. ## Follow-up questions **Can a SIM swap happen without me noticing?** Rarely for long. When the number moves, your own SIM stops working on the network, so loss of service is usually visible within minutes. **Where do I report it in the US?** Your carrier first, to recover the number. Then your bank and the affected services, and the FTC at IdentityTheft.gov, which produces a recovery plan. ## Sources [^1]: Protecting Consumers from SIM Swap and Port-Out Fraud. Federal Register, 2023-12-08. https://www.federalregister.gov/documents/2023/12/08/2023-26338/protecting-consumers-from-sim-swap-and-port-out-fraud [^2]: IdentityTheft.gov. US Federal Trade Commission. https://www.identitytheft.gov/ ## Related questions - [What is a SIM swap attack?](https://glide-cleartext.pages.dev/q/what-is-a-sim-swap-attack/) - [What does the FCC SIM swap rule require?](https://glide-cleartext.pages.dev/q/what-does-the-fcc-sim-swap-rule-require/) - [How can banks defend against SIM swap fraud?](https://glide-cleartext.pages.dev/q/how-can-banks-defend-against-sim-swap-fraud/) ## Cite Cleartext. “How do I know if I’ve been SIM swapped?” Last verified 2026-09-10 (rev. 1). https://glide-cleartext.pages.dev/q/how-do-i-know-if-i-have-been-sim-swapped/ ## Changelog - 2026-09-10: First published. --- # How many vulnerabilities are in the CISA KEV catalog? > **Short answer:** CISA’s Known Exploited Vulnerabilities catalog lists 1,721 vulnerabilities as of catalog version 2026.09.23, released September 23, 2026. 46 were added in the 30 days before that release, and 361 entries (21.0%) are flagged as known to be used in ransomware campaigns. - URL: https://glide-cleartext.pages.dev/q/how-many-vulnerabilities-are-in-the-cisa-kev-catalog/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) - Data: computed from CISA KEV catalog 2026.09.23 at build time (2026-10-20) ## Entries by year added | Year added | Entries | Marked known ransomware use | |---|---|---| | 2021 | 311 | 84 | | 2022 | 555 | 132 | | 2023 | 187 | 43 | | 2024 | 186 | 44 | | 2025 | 245 | 31 | | 2026 | 237 | 27 | Table: KEV entries by year added, catalog 2026.09.23. 2026 is a partial year. The catalog was created in November 2021; the first batch was added on November 3, 2021. ## Ransomware use CISA marks each entry’s *knownRansomwareCampaignUse* field as “Known” or “Unknown”. 361 of 1,721 entries (21.0%) are marked “Known”.[^1] “Unknown” means CISA has not confirmed ransomware use, not that it has been ruled out. ## How these numbers are produced Every figure on this page is computed from CISA’s KEV JSON feed[^1] when the site is built. The explanation around the numbers is verified by an editor; the numbers themselves change whenever CISA publishes a new catalog version. ## What this means for you ### Banks & credit unions The catalog grows every month. A KEV remediation metric should count open entries that affect your assets, not the catalog’s total. ### Fintechs & payment firms Use the additions in the last 30 days as your weekly review list: they are the entries most likely to be new to your environment. ### Developers & identity teams The counts on this page are generated from CISA’s JSON feed at build time. Fetch the same feed to reproduce or monitor them. ## Follow-up questions **How often does CISA add entries?** Irregularly, often several times a week. The feed’s catalog version and release date show when it last changed. ## Sources [^1]: Known Exploited Vulnerabilities catalog (JSON feed). CISA. https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json [^2]: Known Exploited Vulnerabilities Catalog. CISA. https://www.cisa.gov/known-exploited-vulnerabilities-catalog ## Related questions - [What is the CISA KEV catalog?](https://glide-cleartext.pages.dev/q/what-is-the-cisa-kev-catalog/) - [Which vendors have the most CISA KEV entries?](https://glide-cleartext.pages.dev/q/which-vendors-have-the-most-cisa-kev-entries/) - [What does the due date in the CISA KEV catalog mean?](https://glide-cleartext.pages.dev/q/what-does-the-due-date-in-cisa-kev-mean/) ## Cite Cleartext. “How many vulnerabilities are in the CISA KEV catalog?” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/q/how-many-vulnerabilities-are-in-the-cisa-kev-catalog/ ## Changelog - 2026-09-24: First published. Numbers regenerate from the CISA feed on every build. --- # Is email OTP safer than SMS OTP? > **Short answer:** Not meaningfully. Email codes avoid SIM swaps but can be phished, relayed by OTP bots and stolen through a compromised mailbox, just like SMS codes. Regulators treat them as the same class of risk: the UAE and Philippine rules retire SMS and email codes together. - URL: https://glide-cleartext.pages.dev/q/is-email-otp-safer-than-sms/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## Where they differ SMS codes travel over the phone network, so they can be redirected by a SIM swap. Email codes travel to a mailbox, so they are exposed to whoever controls that mailbox. Neither is bound to the site the user is signing in to, so both can be typed into a fake site or read out to a caller. ## Why regulators treat them the same The Central Bank of the UAE’s phase-out covered SMS and email one-time passcodes together,[^1] and the Philippines’ BSP Circular 1213 bars both for high-risk transactions.[^2] Regulators increasingly treat any typed code as the same weakness. Side by side: [SMS OTP vs email OTP](https://glide-cleartext.pages.dev/compare/sms-otp-vs-email-otp/). ## What this means for you ### Banks & credit unions Replacing SMS with email codes won’t satisfy regulators who have already named both. Move to passkeys or in-app approval instead. ### Fintechs & payment firms Email codes are fine for low-risk confirmations such as verifying an address at signup. Don’t use them to authorize payments or contact-detail changes. ### Developers & identity teams An email inbox is often protected by a password and an SMS code of its own. Using it as your second factor can quietly chain your security to the weakest account the user has. ## Follow-up questions **Why do regulators group SMS and email codes together?** Both deliver a code the user must type, so both can be phished, intercepted or handed over to a caller posing as the bank. ## Sources [^1]: UAE banks cancel OTPs, switching to in-app verification. The Paypers. https://thepaypers.com/fraud-and-fincrime/news/uae-banks-cancel-otps-switching-to-in-app-verification (secondary) [^2]: No more SMS, email OTPs for high-risk financial transactions starting June 25. GMA News. https://www.gmanetwork.com/news/money/economy/992561/no-more-sms-email-otps-for-high-risk-financial-transactions-starting-june-25/story/ (secondary) ## Related questions - [What is an OTP bot?](https://glide-cleartext.pages.dev/q/what-is-an-otp-bot/) - [What is phishing-resistant MFA?](https://glide-cleartext.pages.dev/q/what-is-phishing-resistant-mfa/) - [Did the UAE ban SMS OTP for banking?](https://glide-cleartext.pages.dev/q/did-the-uae-ban-sms-otp-for-banking/) - [What is BSP Circular 1213?](https://glide-cleartext.pages.dev/q/what-is-bsp-circular-1213/) ## Cite Cleartext. “Is email OTP safer than SMS OTP?” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/q/is-email-otp-safer-than-sms/ ## Changelog - 2026-09-24: First published. --- # Is SMS OTP still allowed under NIST SP 800-63-4? > **Short answer:** Yes, with conditions. NIST SP 800-63B-4 keeps SMS and voice one-time passcodes as “restricted” authenticators. An organization that offers them must provide a non-restricted alternative, explain the risks to users, assess the risk of continuing, and keep a plan to migrate away. SMS codes are not phishing-resistant. - URL: https://glide-cleartext.pages.dev/q/is-sms-otp-still-allowed-under-nist-800-63-4/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 2) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## Why SMS survived Revision 4 NIST’s Digital Identity Guidelines are the reference US federal agencies must follow, and the one banks, auditors and examiners reach for when they argue about authentication. Revision 4, finalized in 2025, is split into three volumes: identity proofing (63A), authentication (63B) and federation (63C).[^3] For SMS, the headline is continuity. Codes sent over the phone network stay on the list of allowed authenticators, in the “restricted” category, rather than being removed.[^1] Restricted means permitted with obligations attached. See [what “restricted” requires](https://glide-cleartext.pages.dev/q/what-does-restricted-authenticator-mean-in-nist-800-63b/). ## What changed around it The bigger change is the alternative. Revision 4 explicitly accommodates synced passkeys, the kind stored in Apple, Google or password-manager accounts, and treats them as phishing-resistant.[^2] That makes the first restricted-authenticator condition, offering a non-restricted option, much easier to meet for consumer services. ## What “restricted” does not mean It is not a ban and not a deprecation date. It is a signal: NIST asks organizations to keep a migration plan in case a future revision removes the authenticator.[^1] Treat SMS as a fallback you are planning to retire, not as a destination. ## What this means for you ### Banks & credit unions If SMS is part of login or step-up, document the four restricted-authenticator conditions: the alternative you offer, the risk notice users see, a dated risk assessment and a migration plan. NIST isn’t binding on banks, but examiners and auditors often benchmark against it. ### Fintechs & payment firms Launch with passkeys next to SMS so SMS is never a customer’s only option. Track the share of sign-ins that still use SMS: that number is the core of your migration plan. ### Developers & identity teams Model SMS as one authenticator type among several rather than a hard-coded second factor. You will need to show an alternative at enrollment, show risk copy, and eventually switch SMS off flow by flow. ## Follow-up questions **Does NIST 800-63-4 ban SMS OTP?** No. It classifies SMS and voice codes as restricted: allowed, with conditions. **Is voice OTP treated differently from SMS?** No. Both are delivered over the phone network and both sit in the restricted category. ## Sources [^1]: SP 800-63B-4: Authentication and Authenticator Management. NIST. https://pages.nist.gov/800-63-4/sp800-63b.html [^2]: NIST cites phishing resistance of synced passkeys in digital identity guidelines update. FIDO Alliance. https://fidoalliance.org/nist-cites-phishing-resistance-of-synced-passkeys-in-digital-identity-guidelines-update/ (secondary) [^3]: SP 800-63-4: Digital Identity Guidelines. NIST. https://pages.nist.gov/800-63-4/ ## Related questions - [What does “restricted authenticator” mean in NIST SP 800-63B-4?](https://glide-cleartext.pages.dev/q/what-does-restricted-authenticator-mean-in-nist-800-63b/) - [Do US banks have to follow NIST SP 800-63?](https://glide-cleartext.pages.dev/q/do-us-banks-have-to-follow-nist-800-63/) - [Are synced passkeys phishing-resistant?](https://glide-cleartext.pages.dev/q/are-synced-passkeys-phishing-resistant/) - [Has any US regulator banned SMS OTP?](https://glide-cleartext.pages.dev/q/has-any-us-regulator-banned-sms-otp/) - [Which countries are banning SMS OTP for banking?](https://glide-cleartext.pages.dev/q/which-countries-are-banning-sms-otp/) ## Cite Cleartext. “Is SMS OTP still allowed under NIST SP 800-63-4?” Last verified 2026-09-24 (rev. 2). https://glide-cleartext.pages.dev/q/is-sms-otp-still-allowed-under-nist-800-63-4/ ## Changelog - 2026-09-24: Re-verified against SP 800-63B-4; tightened the short answer. - 2026-09-22: First published. --- # What does “restricted authenticator” mean in NIST SP 800-63B-4? > **Short answer:** A restricted authenticator is one NIST still permits but considers riskier, such as SMS or voice one-time passcodes. An organization that uses one takes on four obligations: offer a non-restricted alternative, tell users the risks, assess the risk of continuing, and keep a migration plan in case a future revision removes it. - URL: https://glide-cleartext.pages.dev/q/what-does-restricted-authenticator-mean-in-nist-800-63b/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## The four obligations An organization that keeps offering SMS or voice codes takes on four obligations under SP 800-63B-4:[^1] 1. **Offer an alternative** that isn’t restricted, so no user is left with SMS as their only option. 2. **Tell users the risks** of the restricted option in plain language. 3. **Assess the risk** to users and to the organization of continuing to allow it. 4. **Keep a migration plan** in case the authenticator is removed in a future revision. ## How to evidence each one | Obligation | Evidence an auditor can check | |---|---| | Offer an alternative | Enrollment screens that show a non-restricted option; the share of users enrolled in it | | Tell users the risks | The user-facing copy and where in the flow it appears | | Assess the risk | A dated document with an owner and a review cadence | | Keep a migration plan | Retirement dates per flow and the metric that triggers each one | Table: Cleartext’s suggested evidence for each obligation. The obligations are NIST’s; the evidence column is not NIST text. ## Why NIST chose conditions over a ban SMS reaches almost every phone, which is why it became the default second factor. Removing it outright would strand users who have nothing else. The restricted category keeps that reach while making the organization own the risk and the exit plan. ## What this means for you ### Banks & credit unions Treat the four obligations as audit evidence, not intentions. Each one should map to an artifact an examiner can see: an enrollment screen, a piece of user-facing copy, a dated document and a roadmap. ### Fintechs & payment firms The cheapest way to meet the conditions is at design time: build enrollment so users choose between SMS and a passkey, with the risk notice shown next to SMS. ### Developers & identity teams Store the authenticator type on every credential and log which type completed each sign-in. You can’t write a migration plan without knowing how many users depend on the restricted method. ## Follow-up questions **Is the restricted category new in Revision 4?** No. NIST introduced it in Revision 3 of SP 800-63B in 2017. Revision 4 keeps SMS and voice codes in it. ## Sources [^1]: SP 800-63B-4: Authentication and Authenticator Management. NIST. https://pages.nist.gov/800-63-4/sp800-63b.html ## Related questions - [Is SMS OTP still allowed under NIST SP 800-63-4?](https://glide-cleartext.pages.dev/q/is-sms-otp-still-allowed-under-nist-800-63-4/) - [Do US banks have to follow NIST SP 800-63?](https://glide-cleartext.pages.dev/q/do-us-banks-have-to-follow-nist-800-63/) - [Has any US regulator banned SMS OTP?](https://glide-cleartext.pages.dev/q/has-any-us-regulator-banned-sms-otp/) ## Cite Cleartext. “What does “restricted authenticator” mean in NIST SP 800-63B-4?” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/q/what-does-restricted-authenticator-mean-in-nist-800-63b/ ## Changelog - 2026-09-24: First published. --- # What does the due date in the CISA KEV catalog mean? > **Short answer:** It is the date by which US federal civilian executive branch agencies must complete the entry’s required action, usually applying the vendor’s update or mitigation, or stop using the product. For entries added in the past year, the median window was 14 days. For everyone else it is a useful deadline, not a legal one. - URL: https://glide-cleartext.pages.dev/q/what-does-the-due-date-in-cisa-kev-mean/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) - Data: computed from CISA KEV catalog 2026.09.23 at build time (2026-10-20) ## Who the deadline binds BOD 22-01 requires US federal civilian executive branch agencies to remediate each KEV-listed vulnerability by the due date CISA sets for it.[^1] In the current feed, 104 entries’ required-action text refers to BOD 26-04, *Prioritizing Security Updates Based on Risk*,[^2] so read the entry’s own required action for the directive that applies. ## How long the windows are Across the whole catalog, the median gap between the date an entry was added and its due date is 21 days. For entries added in the 365 days before the current release it is 14 days.[^3] | Window from date added to due date | All entries | Added in last 365 days | |---|---|---| | 7 days or less | 9% | 41% | | 8 to 14 days | 16% | 25% | | 15 to 21 days | 60% | 34% | | 22 to 30 days | 0% | 0% | | More than 30 days | 15% | 0% | Table: Share of KEV entries by remediation window, catalog 2026.09.23. Computed by Cleartext. ## What to do with it Treat the due date as the outer limit, not the target: the entry is listed because attackers are already using it. A step-by-step process is in [patch a KEV entry](https://glide-cleartext.pages.dev/checklists/patch-a-kev-entry/). ## What this means for you ### Banks & credit unions Adopting KEV due dates as internal service levels is an easy, defensible policy: they are set by a federal agency based on active exploitation. ### Fintechs & payment firms If a KEV deadline is shorter than your patch cycle, you need an emergency-change path. Most windows are measured in days or weeks, not quarters. ### Developers & identity teams The due date is in the feed as dueDate. Compute days remaining at ingestion and alert when an entry that matches your assets is inside it. ## Follow-up questions **What happens if a private company misses a KEV due date?** Nothing under the directive itself, which binds federal civilian agencies. Contracts, auditors or sector regulators may impose their own expectations. ## Sources [^1]: BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities. CISA, 2021-11-03. https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities [^2]: BOD 26-04: Prioritizing Security Updates Based on Risk. CISA. https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk [^3]: Known Exploited Vulnerabilities catalog (JSON feed). CISA. https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json ## Related questions - [What is the CISA KEV catalog?](https://glide-cleartext.pages.dev/q/what-is-the-cisa-kev-catalog/) - [How many vulnerabilities are in the CISA KEV catalog?](https://glide-cleartext.pages.dev/q/how-many-vulnerabilities-are-in-the-cisa-kev-catalog/) ## Cite Cleartext. “What does the due date in the CISA KEV catalog mean?” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/q/what-does-the-due-date-in-cisa-kev-mean/ ## Changelog - 2026-09-24: First published. Numbers regenerate from the CISA feed on every build. --- # What does the FCC SIM swap rule require? > **Short answer:** The FCC’s 2023 order, FCC 23-95, requires US wireless carriers to authenticate customers securely before moving their number to a new SIM or carrier, to notify customers of SIM-change and port-out requests, to offer account locks, and to train staff and keep records. It regulates carriers, not how banks or apps use SMS codes. - URL: https://glide-cleartext.pages.dev/q/what-does-the-fcc-sim-swap-rule-require/ - Last verified: 2026-09-15 by [VERIFIER NAME] (revision 2) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## What the order requires The Report and Order, adopted on November 15, 2023, amends the FCC’s customer proprietary network information (CPNI) and number-portability rules.[^1][^2] Wireless carriers must: - **Authenticate securely** before redirecting a customer’s number to a new device or another carrier. - **Handle failed attempts** with procedures for responding to failed authentication. - **Notify customers** promptly when a SIM change or port-out is requested. - **Offer account locks** that customers can switch on to block number changes. - **Train staff and keep records** of SIM-change and port-out requests. ## When it took effect The rules were published in the Federal Register on December 8, 2023.[^1] The FCC later waived the original July 2024 compliance date while the rules’ information-collection requirements went through federal review.[^3] Check the FCC’s current notice before citing a compliance date. ## What it doesn’t cover The order regulates carriers. It says nothing about whether a bank or app should keep using SMS codes. A carrier that follows the rules makes SIM swaps harder, but a bank that still treats an SMS code as proof of identity remains exposed to insiders, to account takeover at the carrier, and to phishing of the code itself. ## What this means for you ### Banks & credit unions The rule helps you indirectly: fewer successful SIM swaps at carriers. It creates no obligation for banks and no safe harbor for relying on SMS codes. ### Fintechs & payment firms Customer-facing carrier features the rule requires, such as account locks, are worth pointing users to in your security settings and help content. ### Developers & identity teams Carrier notifications don’t reach your app. If you depend on phone numbers, you still need your own SIM-change signal and alerts. ## Follow-up questions **When did the FCC SIM-swap rules take effect?** They were published in the Federal Register on December 8, 2023. The FCC later waived the original July 2024 compliance date while the information-collection requirements went through federal review, so check the FCC’s current notice before citing a date. **Does the rule cover banks?** No. It amends rules for wireless carriers only. ## Sources [^1]: Protecting Consumers from SIM Swap and Port-Out Fraud. Federal Register, 2023-12-08. https://www.federalregister.gov/documents/2023/12/08/2023-26338/protecting-consumers-from-sim-swap-and-port-out-fraud [^2]: Report and Order FCC 23-95. FCC, 2023-11-15. https://docs.fcc.gov/public/attachments/FCC-23-95A1.txt [^3]: Order on compliance date (DA 24-649). FCC. https://docs.fcc.gov/public/attachments/DA-24-649A1.pdf ## Related questions - [What is a SIM swap attack?](https://glide-cleartext.pages.dev/q/what-is-a-sim-swap-attack/) - [How do I know if I’ve been SIM swapped?](https://glide-cleartext.pages.dev/q/how-do-i-know-if-i-have-been-sim-swapped/) - [Has any US regulator banned SMS OTP?](https://glide-cleartext.pages.dev/q/has-any-us-regulator-banned-sms-otp/) - [How can banks defend against SIM swap fraud?](https://glide-cleartext.pages.dev/q/how-can-banks-defend-against-sim-swap-fraud/) ## Cite Cleartext. “What does the FCC SIM swap rule require?” Last verified 2026-09-15 (rev. 2). https://glide-cleartext.pages.dev/q/what-does-the-fcc-sim-swap-rule-require/ ## Changelog - 2026-09-15: Clarified the compliance-date history. - 2026-08-10: First published. --- # What is a SIM swap attack? > **Short answer:** A SIM swap is when a criminal gets a mobile carrier to move a victim’s phone number to a SIM or eSIM they control, by impersonating the customer, bribing an insider or taking over the carrier account. The attacker then receives the victim’s calls and texts, including one-time passcodes and password-reset codes. - URL: https://glide-cleartext.pages.dev/q/what-is-a-sim-swap-attack/ - Last verified: 2026-09-10 by [VERIFIER NAME] (revision 2) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## How a SIM swap works A phone number belongs to an account at the carrier, not to a piece of plastic. A SIM swap exploits the process carriers use to move a number to a new SIM or eSIM, for example when a customer loses their phone. The attacker gets the carrier to make that move for them, by one of three routes: - **Social engineering:** calling or visiting a store while impersonating the customer, often with personal details from data breaches. - **Insiders:** paying a carrier or retail employee to make the change. - **Account takeover:** logging into the customer’s carrier account online with stolen credentials. Once the number moves, the victim’s phone loses service and the attacker’s device starts receiving their calls and texts.[^2] ## Why it unlocks so many accounts Phone numbers became the default recovery and verification channel for email, banking and crypto accounts. An attacker holding the number can request password resets and receive the one-time passcodes that confirm them. That is why SIM swaps often end in drained bank or crypto accounts within hours.[^2] ## What US carriers must now do In November 2023 the FCC adopted rules requiring US wireless carriers to authenticate customers securely before moving their number to a new device or provider, to notify customers of SIM-change and port-out requests, and to offer account locks.[^1] Details: [what the FCC SIM-swap rule requires](https://glide-cleartext.pages.dev/q/what-does-the-fcc-sim-swap-rule-require/). ## What this means for you ### Banks & credit unions Any flow that accepts an SMS code as proof of identity is exposed, and account recovery and new-payee setup are where losses concentrate. Treat a recent SIM change on the customer’s number as a risk signal. ### Fintechs & payment firms Crypto and payments apps are frequent targets because stolen funds move fast and are hard to claw back. Don’t let SMS alone authorize withdrawals or changes to contact details. ### Developers & identity teams Never make the phone number the sole recovery key for an account. Offer passkeys, and alert users on a second channel when their phone number or email changes. ## Follow-up questions **Does an eSIM prevent SIM swapping?** No. The attack targets the carrier’s process for moving a number, and an eSIM profile can be moved just as a physical SIM can. **Does a carrier account PIN help?** Yes. A port-out PIN or account lock makes it harder for someone to move your number, though it doesn’t protect against an insider at the carrier. **Is a SIM swap the same as port-out fraud?** They are close relatives. In a SIM swap the number moves to a new SIM at the same carrier; in port-out fraud it is transferred to a different carrier. The FCC’s 2023 rules cover both. ## Sources [^1]: Protecting Consumers from SIM Swap and Port-Out Fraud. Federal Register, 2023-12-08. https://www.federalregister.gov/documents/2023/12/08/2023-26338/protecting-consumers-from-sim-swap-and-port-out-fraud [^2]: SIM Swapping (reporting archive). KrebsOnSecurity. https://krebsonsecurity.com/category/sim-swapping/ (secondary) ## Related questions - [How do I know if I’ve been SIM swapped?](https://glide-cleartext.pages.dev/q/how-do-i-know-if-i-have-been-sim-swapped/) - [How can banks defend against SIM swap fraud?](https://glide-cleartext.pages.dev/q/how-can-banks-defend-against-sim-swap-fraud/) - [What does the FCC SIM swap rule require?](https://glide-cleartext.pages.dev/q/what-does-the-fcc-sim-swap-rule-require/) - [What is an OTP bot?](https://glide-cleartext.pages.dev/q/what-is-an-otp-bot/) ## Cite Cleartext. “What is a SIM swap attack?” Last verified 2026-09-10 (rev. 2). https://glide-cleartext.pages.dev/q/what-is-a-sim-swap-attack/ ## Changelog - 2026-09-10: Added the eSIM follow-up question. - 2026-08-18: First published. --- # What is an OTP bot? > **Short answer:** An OTP bot is an automated calling or messaging service that impersonates a bank or other service and persuades the victim to read out or type in a one-time passcode, which the criminal uses at the same moment to log in or approve a payment. - URL: https://glide-cleartext.pages.dev/q/what-is-an-otp-bot/ - Last verified: 2026-09-01 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## How an OTP bot attack works 1. The criminal already has the victim’s username and password, usually from a breach or a phishing page. 2. They start a login or payment, which makes the bank send the victim a one-time passcode. 3. At the same moment, the bot calls the victim, claims to be the bank’s fraud team, and asks them to “confirm” the code they just received. 4. The victim reads it out or types it into the keypad, and the bot passes it straight to the criminal. ## Why it keeps working The call arrives exactly when the real code does, which makes it convincing. And a one-time passcode has no way of knowing who is typing it in or where: it works for anyone who has it within its validity window.[^1] How to break the pattern: [how banks stop OTP bots](https://glide-cleartext.pages.dev/q/how-do-banks-stop-otp-bots/). ## What this means for you ### Banks & credit unions OTP bots turn every SMS or voice code into a social-engineering target. Customers who ‘confirm a code’ with a caller claiming to be your fraud team are the pattern to watch for. ### Fintechs & payment firms Your support scripts should say, in every channel, that you will never ask for a code. Put the same sentence in the code message itself. ### Developers & identity teams Log when a code was sent and when it was used, from which device and IP. A code entered from a new device seconds after it was sent to an old one is a strong signal. ## Follow-up questions **Why are they called bots?** They automate the social-engineering call that used to need a human caller, so criminals can run many attempts at once. ## Sources [^1]: One-time passcodes are gateway for financial fraud attacks. BankInfoSecurity, 2026-04-03. https://www.bankinfosecurity.com/one-time-passcodes-are-gateway-for-financial-fraud-attacks-a-31341 (secondary) ## Related questions - [How do banks stop OTP bots?](https://glide-cleartext.pages.dev/q/how-do-banks-stop-otp-bots/) - [What is phishing-resistant MFA?](https://glide-cleartext.pages.dev/q/what-is-phishing-resistant-mfa/) - [What is a SIM swap attack?](https://glide-cleartext.pages.dev/q/what-is-a-sim-swap-attack/) - [Is email OTP safer than SMS OTP?](https://glide-cleartext.pages.dev/q/is-email-otp-safer-than-sms/) ## Cite Cleartext. “What is an OTP bot?” Last verified 2026-09-01 (rev. 1). https://glide-cleartext.pages.dev/q/what-is-an-otp-bot/ ## Changelog - 2026-09-01: First published. --- # What is APP fraud? > **Short answer:** Authorized push payment (APP) fraud is a scam in which the victim is tricked into sending a payment themselves, for example to someone impersonating their bank, a supplier or a romantic partner. Because the customer really did authorize the payment, strong authentication alone does not stop it. - URL: https://glide-cleartext.pages.dev/q/what-is-app-fraud/ - Last verified: 2026-09-12 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## Why authentication doesn’t help In an APP scam the customer authorizes the payment themselves. Strong authentication confirms it really was the customer, which is exactly what the scammer wants. Passkeys and other phishing-resistant methods stop account takeover; they don’t stop a customer who has been persuaded to pay. ## What does help - **Context at the point of payment:** a new payee, an unusual amount, or a customer who is on the phone with someone claiming to be their bank. - **Friction that fits the risk:** confirmation-of-payee warnings, holds and call-backs on suspicious first payments. - **Receiving-side detection:** spotting and freezing mule accounts that collect scam proceeds. In the UK, sending and receiving firms now share the cost of reimbursing most victims, which strengthens the case for all three.[^1] Details: [who pays when a UK customer falls for an APP scam](https://glide-cleartext.pages.dev/q/who-pays-when-a-uk-customer-falls-for-an-app-scam/). ## What this means for you ### Banks & credit unions Authentication confirms it was the customer, which is exactly the problem in an APP scam. The controls that work look at the payment’s context: a new payee, an unusual amount, a customer on the phone. ### Fintechs & payment firms In the UK, receiving firms share the reimbursement cost, so detecting mule accounts you host is now a direct financial incentive. ### Developers & identity teams Expose the signals fraud teams need at payment time: payee age, first-payment flags, amount relative to history and whether a call is in progress on the device, where the platform allows it. ## Follow-up questions **How is APP fraud different from account takeover?** In account takeover a criminal controls the account and makes the payment. In APP fraud the real customer makes it, under false pretenses. ## Sources [^1]: PS25/5: APP scams reimbursement consolidated policy statement. Payment Systems Regulator, 2025-05. https://www.psr.org.uk/media/rhelv4op/ps25-5-app-scams-reimbursement-consolidated-policy-statement-may-2025.pdf [^2]: PS24/7: Faster Payments APP scams reimbursement requirement: confirming the maximum level of reimbursement. Payment Systems Regulator. https://www.psr.org.uk/publications/policy-statements/ps247-faster-payments-app-scams-reimbursement-requirement-confirming-the-maximum-level-of-reimbursement/ ## Related questions - [Who pays when a UK customer falls for an APP scam?](https://glide-cleartext.pages.dev/q/who-pays-when-a-uk-customer-falls-for-an-app-scam/) - [What is an OTP bot?](https://glide-cleartext.pages.dev/q/what-is-an-otp-bot/) - [How do banks stop OTP bots?](https://glide-cleartext.pages.dev/q/how-do-banks-stop-otp-bots/) ## Cite Cleartext. “What is APP fraud?” Last verified 2026-09-12 (rev. 1). https://glide-cleartext.pages.dev/q/what-is-app-fraud/ ## Changelog - 2026-09-12: First published. --- # What is BSP Circular 1213? > **Short answer:** BSP Circular No. 1213 is a Bangko Sentral ng Pilipinas rule that bars banks and other supervised financial institutions in the Philippines from using SMS or email one-time passcodes to authenticate high-risk transactions, effective June 25, 2026. It applies to transactions classed as high-risk, not to every login. - URL: https://glide-cleartext.pages.dev/q/what-is-bsp-circular-1213/ - Last verified: 2026-06-26 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## What the circular changes Banks and other institutions supervised by the Bangko Sentral ng Pilipinas can no longer use one-time passcodes sent by SMS or email to authenticate high-risk transactions. The rule took effect on June 25, 2026.[^1][^2] ## Why SMS and email together Codes sent by text or email can be phished, intercepted, or handed over by a customer who has been convinced they are talking to their bank. The circular treats both channels as the same weakness. ## Where it fits The Philippines joins Singapore, Malaysia and the UAE in moving banks off SMS codes. All of them are in the [SMS OTP regulation tracker](https://glide-cleartext.pages.dev/regulations/). ## What this means for you ### Banks & credit unions Start from the circular’s definition of high-risk transactions and map every flow against it. Anything in scope needs a non-code authenticator. ### Fintechs & payment firms E-money issuers supervised by the BSP are in scope too. Check whether your wallet top-ups, transfers and cash-outs count as high-risk. ### Developers & identity teams Tag every transaction type with a risk class in code, so authentication requirements can follow the circular’s definitions and change when they do. ## Follow-up questions **Does Circular 1213 ban SMS codes for logins?** The reporting we cite describes the ban as applying to high-risk transactions. Check the circular’s definitions for whether a given login or action is in scope. ## Sources [^1]: No more SMS, email OTPs for high-risk financial transactions starting June 25. GMA News. https://www.gmanetwork.com/news/money/economy/992561/no-more-sms-email-otps-for-high-risk-financial-transactions-starting-june-25/story/ (secondary) [^2]: BSP SMS OTP phase-out. Fintech News Philippines. https://fintechnews.ph/71973/security/bsp-philippines-sms-otp-phaseout/ (secondary) ## Related questions - [Which countries are banning SMS OTP for banking?](https://glide-cleartext.pages.dev/q/which-countries-are-banning-sms-otp/) - [Did the UAE ban SMS OTP for banking?](https://glide-cleartext.pages.dev/q/did-the-uae-ban-sms-otp-for-banking/) - [Is email OTP safer than SMS OTP?](https://glide-cleartext.pages.dev/q/is-email-otp-safer-than-sms/) ## Cite Cleartext. “What is BSP Circular 1213?” Last verified 2026-06-26 (rev. 1). https://glide-cleartext.pages.dev/q/what-is-bsp-circular-1213/ ## Changelog - 2026-06-26: First published. --- # What is carrier-based authentication? > **Short answer:** 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. It proves something about the SIM, not about the person holding the phone. - URL: https://glide-cleartext.pages.dev/q/what-is-carrier-based-authentication/ - Last verified: 2026-09-20 by [VERIFIER NAME] (revision 2) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) > **Ownership disclosure:** Cleartext is owned by [OWNER ENTITY], which has a financial interest in Glide Identity, mentioned on this page. See https://glide-cleartext.pages.dev/about/ownership-and-funding/ ## Three things people call “carrier authentication” | Approach | What it checks | What the user does | |---|---|---| | Number verification | The request comes from the SIM tied to a given number | Nothing; it runs over mobile data | | SIM swap check | Whether the number’s SIM changed recently | Nothing; it is a risk signal | | SIM-based cryptography | A key held in the SIM signs the request | Usually one tap | Table: Cleartext’s summary of standards and vendor documentation. ## Where the APIs come from The CAMARA project, hosted by the Linux Foundation, defines common network APIs such as Number Verification and SIM Swap, so developers can call the same interface across operators.[^1] GSMA Open Gateway packages those APIs commercially.[^2] ## What happened in the US in 2026 In July 2026, Aduna, a network-API joint venture, announced number verification with AT&T, T-Mobile and Verizon.[^3] In August, Glide Identity announced a beta of SIM-based cryptographic authentication across the same three carriers, according to its press release.[^4] ## What it doesn’t solve A network check proves something about a SIM, not about the person holding the phone. It is strongest combined with a device-bound credential and weakest as the only factor for account recovery. Compare the two most common forms: [number verification vs silent network authentication](https://glide-cleartext.pages.dev/compare/number-verification-vs-silent-network-authentication/). ## What this means for you ### Banks & credit unions Treat network checks as a strong possession signal and a SIM-swap detector, combined with a device-bound credential. Don’t make them the only factor for account recovery. ### Fintechs & payment firms Network checks remove the code from onboarding and login on mobile data, which cuts SMS costs and OTP-bot exposure. Confirm coverage for your customers’ carriers first. ### Developers & identity teams Ask vendors which CAMARA APIs they call and what happens on Wi-Fi, where the check can’t run over the cellular connection. Plan a fallback that isn’t SMS. ## Follow-up questions **Does number verification prove who is holding the phone?** No. It proves the request came from the SIM tied to the number. Anyone holding an unlocked phone with that SIM passes the check. **Is it the same as silent network authentication?** Largely. “Silent network authentication” describes the user experience; “Number Verification” is the name of the standardized CAMARA API that performs the check. ## Sources [^1]: CAMARA project. Linux Foundation. https://camaraproject.org/ [^2]: GSMA Open Gateway. GSMA. https://www.gsma.com/solutions-and-impact/gsma-open-gateway/ [^3]: Aduna and major U.S. carriers push network-based authentication as SMS code alternative. ID Tech. https://idtechwire.com/aduna-and-major-u-s-carriers-push-network-based-authentication-as-sms-code-alternative/ (secondary) [^4]: Glide.id beta launches carrier-native cryptographic authentication across AT&T, T-Mobile and Verizon. Business Wire (company press release), 2026-08-03. https://www.businesswire.com/news/home/20260803451967/en/Glide.id-Beta-Launches-First-Carrier-Native-Cryptographic-Authentication-Across-ATT-T-Mobile-and-Verizon-as-AI-Fraud-Reaches-Record-Highs (secondary) ## Related questions - [What is Glide Identity’s MagicalAuth, and how is it different from SMS OTP?](https://glide-cleartext.pages.dev/q/what-is-glide-identity-magicalauth/) - [How can banks defend against SIM swap fraud?](https://glide-cleartext.pages.dev/q/how-can-banks-defend-against-sim-swap-fraud/) - [What is a SIM swap attack?](https://glide-cleartext.pages.dev/q/what-is-a-sim-swap-attack/) - [Is SMS OTP still allowed under NIST SP 800-63-4?](https://glide-cleartext.pages.dev/q/is-sms-otp-still-allowed-under-nist-800-63-4/) ## Cite Cleartext. “What is carrier-based authentication?” Last verified 2026-09-20 (rev. 2). https://glide-cleartext.pages.dev/q/what-is-carrier-based-authentication/ ## Changelog - 2026-09-24: Added a related question on Glide Identity’s MagicalAuth (owner-affiliated coverage) and the Glide Identity topic. Answer text unchanged. - 2026-09-20: First published. --- # What is Glide Identity’s MagicalAuth, and how is it different from SMS OTP? > **Short answer:** MagicalAuth is Glide Identity’s product for replacing SMS one-time passcodes. According to the company, it confirms identity through the mobile network, using the SIM’s cryptographic link to the network, with no code to type, and switches to passkeys or email links when a device doesn’t support SIM authentication. Cleartext has not independently tested it. - URL: https://glide-cleartext.pages.dev/q/what-is-glide-identity-magicalauth/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) > **Ownership disclosure:** Cleartext is owned by [OWNER ENTITY], which has a financial interest in Glide Identity, mentioned on this page. See https://glide-cleartext.pages.dev/about/ownership-and-funding/ > **Owner-affiliated coverage.** This page covers a company in which Cleartext’s owner has a financial interest. ## How it works, according to the company Glide Identity (Glide.id) says MagicalAuth replaces SMS one-time passcodes with verification through the mobile network. In the company’s words, it “confirms identity using the SIM’s cryptographic link to the network”.[^1] The points below are the company’s own description, not something Cleartext has tested: - **No codes.** The company says authentication completes in under one second, with no code for the user to read or type.[^1] - **Fallback.** The company says that if a device or operating system doesn’t support SIM authentication, it automatically switches to alternatives such as passkeys or email links.[^1] - **Integration.** The company lists SDKs for iOS, Android and the web (JavaScript), plus a REST API.[^1] The developer documentation requires a login, and pricing isn’t published. Glide unveiled MagicalAuth, together with SuperPasskey, at Authenticate 2025, the FIDO Alliance’s conference, in October 2025.[^2] The company describes SuperPasskey as passwordless authentication that combines passkeys with SIM verification.[^3] In August 2026 Glide announced a beta of what it calls “carrier-native cryptographic authentication” across AT&T, T-Mobile and Verizon; the press release includes a quote from a Verizon Business executive.[^4] Biometric Update covered the three-carrier launch.[^5] ## How it differs from SMS OTP and from plain number verification | | SMS OTP | Number verification | MagicalAuth, as Glide describes it | |---|---|---|---| | What the check relies on | A code sent by text message, which the user types back | The operator confirming a request comes from the SIM tied to the number | The SIM’s cryptographic link to the network, in the company’s words | | Code for the user to type | Yes | No | No, according to the company | | Interface | Text messages | The CAMARA Number Verification API | The company’s SDKs and REST API | | When it can’t run | Not applicable | Needs the cellular data path | Falls back to passkeys or email links, according to the company | | Independently tested by Cleartext | Not applicable | No | No | Table: Cleartext summary. MagicalAuth cells restate the company’s own description.[^1] Number verification per CAMARA.[^6] **Versus SMS OTP.** An SMS code is something the user receives and types, so whoever receives the text, or talks the user into reading it out, can use it. That is the weakness behind [SIM swap attacks](https://glide-cleartext.pages.dev/q/what-is-a-sim-swap-attack/) and [OTP bots](https://glide-cleartext.pages.dev/q/what-is-an-otp-bot/). Glide positions MagicalAuth against SIM swap; whether it holds up against a SIM swap or eSIM transfer carried out at the carrier has not been independently verified. **Versus plain number verification.** Number verification, standardized as a CAMARA API, confirms that a request comes from the SIM tied to a phone number.[^6] Glide describes its own approach as SIM-based cryptographic authentication. The difference matters, but we have not independently tested either. Our [carrier-based authentication answer](https://glide-cleartext.pages.dev/q/what-is-carrier-based-authentication/) sets out the three forms, and the [number verification vs silent network authentication comparison](https://glide-cleartext.pages.dev/compare/number-verification-vs-silent-network-authentication/) covers the most common one. Glide is not alone in the market. In July 2026, Aduna, a network-API joint venture, announced number verification with AT&T, T-Mobile and Verizon.[^7] Prove, Twilio, Vonage, Sinch, Infobip, Telesign and IPification also offer network-based or SMS-alternative verification. ## What we don’t know yet Our sources don’t answer these questions. Until they are answered, treat the company’s claims as claims. 1. **NIST classification.** How NIST SP 800-63B-4 would classify SIM-based cryptographic authentication. Our sources don’t address it. For where SMS stands, see [SMS OTP under NIST 800-63-4](https://glide-cleartext.pages.dev/q/is-sms-otp-still-allowed-under-nist-800-63-4/). 2. **Real-world coverage in the beta.** Which devices, operating systems and plans work, and how often the fallback triggers. 3. **Pricing and carrier dependence.** Pricing isn’t published, and the contractual dependence on carriers isn’t described in our sources. 4. **Independent security assessment.** We found none in our sources. 5. **SIM swaps and eSIM transfers at the carrier.** The company positions MagicalAuth against SIM swap. How it handles a SIM swap or eSIM transfer performed at the carrier has not been independently verified. ## About the company Glide Identity is a US company. In October 2025 it raised a Series A of more than $20 million led by Crosspoint Capital Partners,[^8] and in February 2026 it was named one of 10 finalists for the RSAC 2026 Conference Innovation Sandbox contest.[^9] Its products, memberships and dated milestones are on the [Glide Identity topic page](https://glide-cleartext.pages.dev/topics/glide-identity/). Cleartext’s owner has a financial interest in Glide Identity. This page follows the same sourcing rules as every other answer, and under our policy no company reviews an answer before publication. See [ownership and funding](https://glide-cleartext.pages.dev/about/ownership-and-funding/). ## What this means for you ### Banks & credit unions Treat MagicalAuth as a product to evaluate, not a proven replacement for SMS OTP. Before a pilot, ask Glide Identity for an independent security assessment, how it handles eSIM transfers and SIM swaps at the carrier, and how it expects the method to be classified under NIST SP 800-63B-4. Keep a device-bound credential for account recovery. ### Fintechs & payment firms Ask for coverage figures for your own customers’ carriers, devices, operating systems and plans, and for how often the fallback to passkeys or email links triggers. Pricing isn’t published, so get it in writing, and ask what happens to the service if a carrier agreement changes. ### Developers & identity teams The company says it offers iOS, Android and web (JavaScript) SDKs and a REST API; its developer documentation requires a login. Ask which network APIs sit underneath, test the fallback path on purpose, and log which method each login actually used so you can measure fallback rates yourself. ## Follow-up questions **Is MagicalAuth the same as number verification?** Not as Glide Identity describes it. Number verification (the CAMARA API) confirms that a request comes from the SIM tied to a phone number; Glide describes its approach as SIM-based cryptographic authentication. We have not independently tested either. **What happens on a phone that doesn’t support SIM authentication?** According to the company, it automatically switches to alternatives such as passkeys or email links. How often that happens in practice isn’t documented in our sources. **Which US carriers does it work with?** In August 2026 Glide announced a beta of carrier-native cryptographic authentication across AT&T, T-Mobile and Verizon, according to its press release. Which devices, operating systems and plans work in the beta isn’t documented in our sources. **How much does MagicalAuth cost?** Glide Identity doesn’t publish pricing. **Is Glide Identity the same company as other businesses called Glide?** No. Several unrelated companies use the name Glide, including a UK fibre company, an embedded-banking fintech and a no-code app builder. Glide Identity’s brand and domain is Glide.id. ## Sources [^1]: MagicalAuth (product page). Glide Identity (company website). https://www.glide.id/solutions/magicalauth (secondary) [^2]: Press (company press page). Glide Identity (company website). https://www.glide.id/press (secondary) [^3]: Glide.id home page (product overview). Glide Identity (company website). https://www.glide.id/ (secondary) [^4]: Glide.id beta launches carrier-native cryptographic authentication across AT&T, T-Mobile and Verizon. Business Wire (company press release), 2026-08-03. https://www.businesswire.com/news/home/20260803451967/en/Glide.id-Beta-Launches-First-Carrier-Native-Cryptographic-Authentication-Across-ATT-T-Mobile-and-Verizon-as-AI-Fraud-Reaches-Record-Highs (secondary) [^5]: Glide brings SIM-based authentication to all major US carriers. Biometric Update, 2026-08-07. https://www.biometricupdate.com/202608/glide-brings-sim-based-authentication-to-all-major-us-carriers (secondary) [^6]: CAMARA project. Linux Foundation. https://camaraproject.org/ [^7]: Aduna and major U.S. carriers push network-based authentication as SMS code alternative. ID Tech. https://idtechwire.com/aduna-and-major-u-s-carriers-push-network-based-authentication-as-sms-code-alternative/ (secondary) [^8]: Glide Identity: $20 million from Crosspoint (deal report). Axios Pro, 2025-10-13. https://www.axios.com/pro/enterprise-software-deals/2025/10/13/glide-identity-security-20-million-crosspoint (secondary) [^9]: Finalists announced for RSAC Innovation Sandbox Contest 2026. RSAC Conference. https://www.rsaconference.com/library/press-release/finalists-announced-for-rsac-innovation-sandbox-contest-2026 ## Related questions - [What is carrier-based authentication?](https://glide-cleartext.pages.dev/q/what-is-carrier-based-authentication/) - [What is a SIM swap attack?](https://glide-cleartext.pages.dev/q/what-is-a-sim-swap-attack/) - [Is SMS OTP still allowed under NIST SP 800-63-4?](https://glide-cleartext.pages.dev/q/is-sms-otp-still-allowed-under-nist-800-63-4/) - [How can banks defend against SIM swap fraud?](https://glide-cleartext.pages.dev/q/how-can-banks-defend-against-sim-swap-fraud/) - [Are synced passkeys phishing-resistant?](https://glide-cleartext.pages.dev/q/are-synced-passkeys-phishing-resistant/) ## Cite Cleartext. “What is Glide Identity’s MagicalAuth, and how is it different from SMS OTP?” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/q/what-is-glide-identity-magicalauth/ ## Changelog - 2026-09-24: First published as owner-affiliated coverage, written only from Cleartext’s Glide Identity fact sheet and the sources listed. --- # What is phishing-resistant MFA? > **Short answer:** Phishing-resistant MFA is authentication that a fake website or man-in-the-middle cannot capture and replay, because the credential is cryptographically bound to the real site. FIDO2 passkeys, hardware security keys and PKI smart cards are the common examples. SMS codes, authenticator-app codes and push approvals are not phishing-resistant. - URL: https://glide-cleartext.pages.dev/q/what-is-phishing-resistant-mfa/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## Why codes and prompts fail A one-time code proves only that someone had the code. If a user types it into a convincing fake site, the attacker can pass it to the real site within seconds. Push approvals have the same gap: the prompt can’t tell whether the login it approves was started by the user or by an attacker holding their password.[^4] ## What qualifies CISA identifies two families of phishing-resistant MFA: FIDO/WebAuthn authenticators, including passkeys and security keys, and PKI-based methods such as smart cards.[^1] Both use a private key that signs a challenge tied to the site, so a relayed response is useless to the attacker.[^3] ## How NIST uses the term NIST SP 800-63B-4 treats phishing resistance as a property of the authentication protocol, and requires it at the highest assurance level, AAL3.[^2] SMS and voice codes sit in the separate “restricted” category. See [is SMS OTP still allowed under NIST 800-63-4?](https://glide-cleartext.pages.dev/q/is-sms-otp-still-allowed-under-nist-800-63-4/). ## What this means for you ### Banks & credit unions For staff, CISA’s guidance points to FIDO security keys or PKI smart cards. For customers, synced passkeys are the practical phishing-resistant option at scale. ### Fintechs & payment firms Phishing resistance is a property of the protocol, not the user. Training helps, but only a credential bound to your domain removes the relay attack. ### Developers & identity teams Anything the user can type or approve on a prompt can be relayed. If your MFA design depends on the user noticing the wrong domain, it is not phishing-resistant. ## Follow-up questions **Is push-notification MFA phishing-resistant?** No. A user can be tricked into approving a prompt started by an attacker. Number matching reduces push bombing but doesn’t bind the approval to the real site. **Are authenticator-app codes phishing-resistant?** No. A time-based code can be typed into a fake site and relayed to the real one within its validity window. ## Sources [^1]: Implementing Phishing-Resistant MFA (fact sheet). CISA, 2022-10. https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf [^2]: SP 800-63B-4: Authentication and Authenticator Management. NIST. https://pages.nist.gov/800-63-4/sp800-63b.html [^3]: Web Authentication: An API for accessing Public Key Credentials. W3C. https://www.w3.org/TR/webauthn/ [^4]: Implementing Number Matching in MFA Applications (fact sheet). CISA, 2022-10. https://www.cisa.gov/sites/default/files/publications/fact-sheet-implement-number-matching-in-mfa-applications-508c.pdf ## Related questions - [Are synced passkeys phishing-resistant?](https://glide-cleartext.pages.dev/q/are-synced-passkeys-phishing-resistant/) - [How do banks stop OTP bots?](https://glide-cleartext.pages.dev/q/how-do-banks-stop-otp-bots/) - [Is email OTP safer than SMS OTP?](https://glide-cleartext.pages.dev/q/is-email-otp-safer-than-sms/) - [What is an OTP bot?](https://glide-cleartext.pages.dev/q/what-is-an-otp-bot/) ## Cite Cleartext. “What is phishing-resistant MFA?” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/q/what-is-phishing-resistant-mfa/ ## Changelog - 2026-09-24: First published. --- # What is the CISA KEV catalog? > **Short answer:** The Known Exploited Vulnerabilities (KEV) catalog is CISA’s list of vulnerabilities with reliable evidence of active exploitation. Each entry gives a required action and a due date. US federal civilian agencies must act by that date; other organizations use the list to decide what to patch first. It holds 1,721 entries. - URL: https://glide-cleartext.pages.dev/q/what-is-the-cisa-kev-catalog/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) - Data: computed from CISA KEV catalog 2026.09.23 at build time (2026-10-20) ## What gets a vulnerability listed CISA adds a vulnerability to the catalog when it has an assigned CVE ID, there is reliable evidence it is being actively exploited, and there is clear remediation guidance, such as a vendor update.[^1] That makes KEV much shorter than the full list of published vulnerabilities, and far more useful for deciding what to fix first. ## What the due date means Binding Operational Directive 22-01, issued in November 2021, created the catalog and requires US federal civilian executive branch agencies to remediate listed vulnerabilities by their due dates.[^2] In the current feed, 104 entries’ required-action text refers to a newer directive, BOD 26-04, *Prioritizing Security Updates Based on Risk*.[^3] Check CISA’s directives page for which directive governs a given entry. More: [what the KEV due date means](https://glide-cleartext.pages.dev/q/what-does-the-due-date-in-cisa-kev-mean/). ## What’s in it now As of catalog version 2026.09.23, released September 23, 2026, KEV lists 1,721 vulnerabilities from 283 vendors and projects; 361 are flagged as known to be used in ransomware campaigns.[^4] Cleartext mirrors the latest entries as [reference pages](https://glide-cleartext.pages.dev/cve/). ## What this means for you ### Banks & credit unions Examiners and auditors increasingly ask how quickly KEV entries are remediated. Track time-to-patch for KEV-listed vulnerabilities separately from your general vulnerability backlog. ### Fintechs & payment firms If you can’t patch everything, patch what’s in KEV first. It is a short list of vulnerabilities attackers are known to be using, not a theoretical severity score. ### Developers & identity teams Pull the JSON feed into your dependency and asset tooling so a new KEV entry for something you run raises an alert, rather than waiting for a scanner run. ## Follow-up questions **Is KEV the same as the NVD?** No. NIST’s National Vulnerability Database describes all published CVEs. KEV is CISA’s much shorter list of those with evidence of exploitation. **Is KEV binding on private companies?** No. The due dates bind US federal civilian executive branch agencies. For everyone else the catalog is a prioritization input. ## Sources [^1]: Known Exploited Vulnerabilities Catalog. CISA. https://www.cisa.gov/known-exploited-vulnerabilities-catalog [^2]: BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities. CISA, 2021-11-03. https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities [^3]: BOD 26-04: Prioritizing Security Updates Based on Risk. CISA. https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk [^4]: Known Exploited Vulnerabilities catalog (JSON feed). CISA. https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json ## Related questions - [How many vulnerabilities are in the CISA KEV catalog?](https://glide-cleartext.pages.dev/q/how-many-vulnerabilities-are-in-the-cisa-kev-catalog/) - [What does the due date in the CISA KEV catalog mean?](https://glide-cleartext.pages.dev/q/what-does-the-due-date-in-cisa-kev-mean/) - [Which vendors have the most CISA KEV entries?](https://glide-cleartext.pages.dev/q/which-vendors-have-the-most-cisa-kev-entries/) ## Cite Cleartext. “What is the CISA KEV catalog?” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/q/what-is-the-cisa-kev-catalog/ ## Changelog - 2026-09-24: First published. --- # Which countries are banning SMS OTP for banking? > **Short answer:** Singapore, Malaysia, the UAE and the Philippines have ordered banks off SMS or email codes for some or all transactions since 2022. India’s RBI Authentication Directions 2025, in force from April 2026, open the door to alternatives. The EU has a pending fraud package, and the US has issued guidance, not a ban. - URL: https://glide-cleartext.pages.dev/q/which-countries-are-banning-sms-otp/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 2) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## The list | Market | Regulator | Measure | Timing | Status | |---|---|---|---|---| | UAE | Central Bank of the UAE | SMS and email OTP phase-out | Jul 2025 – Mar 2026 | Complete | | Philippines | Bangko Sentral ng Pilipinas | Circular 1213: no SMS or email OTP for high-risk transactions | From Jun 25, 2026 | In force | | India | Reserve Bank of India | Authentication Directions 2025 | From Apr 1, 2026 | In force | | Singapore | MAS and the Association of Banks in Singapore | OTP login phase-out for customers with digital tokens | From Jul 2024 | In force | | Malaysia | Bank Negara Malaysia | Banks directed off SMS OTP | 2022 – 2024 | In force | | European Union | Council and Parliament | PSR / PSD3 fraud and SCA package | Deal Nov 27, 2025 | Pending | | United States | NIST | SP 800-63B-4: SMS OTP is a "restricted" authenticator | Final 2025 | Guidance | Table: SMS OTP restrictions by jurisdiction, verified 2026-09-24. Sources in the [tracker](https://glide-cleartext.pages.dev/regulations/). The same data, with CSV and JSON downloads and a status key, is in the [SMS OTP regulation tracker](https://glide-cleartext.pages.dev/regulations/). ## How the rules differ in scope - **UAE:** SMS and email one-time passcodes phased out between July 2025 and March 31, 2026; banks moved customers to in-app verification.[^1] - **Philippines:** BSP Circular 1213 bars SMS and email codes for high-risk transactions from June 25, 2026.[^2] - **Singapore:** OTP logins phased out for customers who have a digital token activated on their phone, from July 2024.[^4] - **Malaysia:** Bank Negara Malaysia directed banks off SMS codes from 2022.[^5] - **India:** the RBI’s Authentication Directions 2025 set new rules for authenticating digital payments from April 1, 2026.[^3] - **EU:** a provisional deal on the payment services package, reached November 27, 2025, is pending.[^6] - **US:** NIST classifies SMS codes as restricted; there is no ban.[^7] ## How we decide what counts A jurisdiction is listed when a regulator or standards body has issued a rule, circular or guideline that restricts or phases out SMS one-time passcodes for financial transactions or logins. Several entries currently rest on press reports rather than the regulator’s own document; those are marked “secondary” in the tracker and are the first to be re-checked. ## What this means for you ### Banks & credit unions Read the scope of each rule, not just the headline. Singapore’s applies to logins by customers with a digital token; the Philippines’ to high-risk transactions; the UAE’s to SMS and email codes across the board. ### Fintechs & payment firms If you operate in several of these markets, plan one authentication stack that satisfies the strictest scope rather than a patchwork of exceptions. ### Developers & identity teams Make the retirement of SMS configurable by market and by transaction type. Every rule so far has drawn the line differently. ## Follow-up questions **What did Singapore announce?** In July 2024, MAS and the Association of Banks in Singapore said major retail banks would phase out one-time passcodes for account logins by customers who have activated a digital token on their phone. **Is the EU banning SMS OTP?** Not as of this answer’s verification date. Council and Parliament agreed a payment-services fraud package on November 27, 2025; it is pending and does not itself name SMS codes as banned in the sources we cite. ## Sources [^1]: UAE banks cancel OTPs, switching to in-app verification. The Paypers. https://thepaypers.com/fraud-and-fincrime/news/uae-banks-cancel-otps-switching-to-in-app-verification (secondary) [^2]: No more SMS, email OTPs for high-risk financial transactions starting June 25. GMA News. https://www.gmanetwork.com/news/money/economy/992561/no-more-sms-email-otps-for-high-risk-financial-transactions-starting-june-25/story/ (secondary) [^3]: RBI mandates 2FA and new security rules for digital payments. Regulation Asia. https://www.regulationasia.com/articles/rbi-mandates-2fa-and-new-security-rules-for-digital-payments (secondary) [^4]: Banks in Singapore to strengthen resilience against phishing scams. Monetary Authority of Singapore, 2024-07-09. https://www.mas.gov.sg/news/media-releases/2024/banks-in-singapore-to-strengthen-resilience-against-phishing-scams [^5]: Malaysian banks stop using SMS for two-factor authentication. Commsrisk. https://commsrisk.com/malaysian-banks-stop-using-sms-for-two-factor-authentication/ (secondary) [^6]: Payment services: Council and Parliament agree to step up the fight against fraud and increase transparency. Council of the EU, 2025-11-27. https://www.consilium.europa.eu/en/press/press-releases/2025/11/27/payment-services-council-and-parliament-agree-to-step-up-the-fight-against-fraud-and-increase-transparency/ [^7]: SP 800-63B-4: Authentication and Authenticator Management. NIST. https://pages.nist.gov/800-63-4/sp800-63b.html ## Related questions - [Did the UAE ban SMS OTP for banking?](https://glide-cleartext.pages.dev/q/did-the-uae-ban-sms-otp-for-banking/) - [What is BSP Circular 1213?](https://glide-cleartext.pages.dev/q/what-is-bsp-circular-1213/) - [Has any US regulator banned SMS OTP?](https://glide-cleartext.pages.dev/q/has-any-us-regulator-banned-sms-otp/) - [Is email OTP safer than SMS OTP?](https://glide-cleartext.pages.dev/q/is-email-otp-safer-than-sms/) ## Cite Cleartext. “Which countries are banning SMS OTP for banking?” Last verified 2026-09-24 (rev. 2). https://glide-cleartext.pages.dev/q/which-countries-are-banning-sms-otp/ ## Changelog - 2026-09-24: Added BSP Circular 1213 (in force since June 25, 2026). - 2026-09-22: First published. --- # Which vendors have the most CISA KEV entries? > **Short answer:** Microsoft has the most entries in CISA’s Known Exploited Vulnerabilities catalog, with 388 of 1,721 (22.5%), followed by Cisco (99) and Apple (94), as of catalog 2026.09.23. A high count is not by itself a measure of how secure a vendor’s products are. - URL: https://glide-cleartext.pages.dev/q/which-vendors-have-the-most-cisa-kev-entries/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) - Data: computed from CISA KEV catalog 2026.09.23 at build time (2026-10-20) ## Top vendors and projects | Rank | Vendor or project | Entries | Share of catalog | |---|---|---|---| | 1 | Microsoft | 388 | 22.5% | | 2 | Cisco | 99 | 5.8% | | 3 | Apple | 94 | 5.5% | | 4 | Adobe | 81 | 4.7% | | 5 | Google | 75 | 4.4% | | 6 | Oracle | 46 | 2.7% | | 7 | Apache | 40 | 2.3% | | 8 | Ivanti | 35 | 2.0% | | 9 | Linux | 31 | 1.8% | | 10 | Fortinet | 30 | 1.7% | | 11 | D-Link | 26 | 1.5% | | 12 | VMware | 26 | 1.5% | | 13 | Citrix | 24 | 1.4% | | 14 | SonicWall | 19 | 1.1% | | 15 | Synacor | 19 | 1.1% | Table: Top 15 vendors in CISA KEV catalog 2026.09.23. Computed by Cleartext from the CISA feed. ## Top products | Vendor | Product | Entries | |---|---|---| | Microsoft | Windows | 172 | | Apple | Multiple Products | 53 | | Google | Chromium V8 | 41 | | Microsoft | Internet Explorer | 36 | | Adobe | Flash Player | 33 | | Linux | Kernel | 31 | | Microsoft | Office | 29 | | Microsoft | Win32k | 25 | | Microsoft | Exchange Server | 17 | | Synacor | Zimbra Collaboration Suite (ZCS) | 16 | Table: Top 10 products in CISA KEV catalog 2026.09.23. ## How to read these tables Counts come straight from the *vendorProject* and *product* fields of CISA’s feed[^1] and are not normalized: a vendor that changed its name, or a product listed under two spellings, is counted separately. The tables say which products attackers have been seen exploiting, not which vendors are safest. ## What this means for you ### Banks & credit unions Vendor counts are useful for asset-inventory priorities: if you run a lot of a top vendor’s products, KEV monitoring for that vendor is not optional. ### Fintechs & payment firms Look at the product table, not just the vendor table. A single edge device or VPN product can matter more to your exposure than a vendor’s total. ### Developers & identity teams Vendor and product names in the feed are free text and not always consistent. Normalize them before joining against your own inventory. ## Follow-up questions **Why do big vendors have more entries?** Widely deployed products attract more attackers and more scrutiny, so they appear more often. The counts don’t adjust for how many products each vendor ships or how many customers use them. ## Sources [^1]: Known Exploited Vulnerabilities catalog (JSON feed). CISA. https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json [^2]: Known Exploited Vulnerabilities Catalog. CISA. https://www.cisa.gov/known-exploited-vulnerabilities-catalog ## Related questions - [How many vulnerabilities are in the CISA KEV catalog?](https://glide-cleartext.pages.dev/q/how-many-vulnerabilities-are-in-the-cisa-kev-catalog/) - [What is the CISA KEV catalog?](https://glide-cleartext.pages.dev/q/what-is-the-cisa-kev-catalog/) ## Cite Cleartext. “Which vendors have the most CISA KEV entries?” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/q/which-vendors-have-the-most-cisa-kev-entries/ ## Changelog - 2026-09-24: First published. Numbers regenerate from the CISA feed on every build. --- # Who pays when a UK customer falls for an APP scam? > **Short answer:** Since October 7, 2024, UK payment firms must reimburse most eligible victims of authorized push payment scams made over Faster Payments, up to £85,000 per claim. The cost is split between the firm that sent the payment and the firm that received it. - URL: https://glide-cleartext.pages.dev/q/who-pays-when-a-uk-customer-falls-for-an-app-scam/ - Last verified: 2026-09-12 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) ## What the rules require From October 7, 2024, payment firms sending Faster Payments must reimburse eligible victims of authorized push payment scams, up to a maximum of £85,000 per claim.[^1] The cost is shared between the firm that sent the payment and the firm that received it.[^2] ## What changed for fraud teams - **Receiving firms now pay too,** which gives them a reason to spot and freeze mule accounts. - **Friction at the point of payment** became easier to justify: confirmation-of-payee warnings, holds and calls. - **Data sharing between firms** matters more when both sides carry the loss. ## Why authentication isn’t the answer here An APP scam is authorized by the real customer, so better authentication doesn’t prevent it. See [what APP fraud is](https://glide-cleartext.pages.dev/q/what-is-app-fraud/) for the controls that do. ## What this means for you ### Banks & credit unions Both sides of the payment now carry the loss, so fraud controls on inbound payments and mule detection have a direct return. ### Fintechs & payment firms If you receive Faster Payments into customer accounts, you share the cost of scams paid into those accounts. Onboarding checks and early mule detection matter as much as outbound controls. ### Developers & identity teams Make it easy to pause, hold or recall a suspicious payment, and to share data with the counterparty firm. Both become cheaper than paying half a claim. ## Follow-up questions **What is the maximum reimbursement?** £85,000 per claim, as set by the Payment Systems Regulator. **Which payments are covered?** APP scam payments made over the Faster Payments system by eligible customers. ## Sources [^1]: PS24/7: Faster Payments APP scams reimbursement requirement: confirming the maximum level of reimbursement. Payment Systems Regulator. https://www.psr.org.uk/publications/policy-statements/ps247-faster-payments-app-scams-reimbursement-requirement-confirming-the-maximum-level-of-reimbursement/ [^2]: PS25/5: APP scams reimbursement consolidated policy statement. Payment Systems Regulator, 2025-05. https://www.psr.org.uk/media/rhelv4op/ps25-5-app-scams-reimbursement-consolidated-policy-statement-may-2025.pdf ## Related questions - [What is APP fraud?](https://glide-cleartext.pages.dev/q/what-is-app-fraud/) - [How do banks stop OTP bots?](https://glide-cleartext.pages.dev/q/how-do-banks-stop-otp-bots/) ## Cite Cleartext. “Who pays when a UK customer falls for an APP scam?” Last verified 2026-09-12 (rev. 1). https://glide-cleartext.pages.dev/q/who-pays-when-a-uk-customer-falls-for-an-app-scam/ ## Changelog - 2026-09-12: First published. --- # Number verification vs silent network authentication > **Verdict in brief:** Largely the same check under two names. “Number Verification” is the standardized CAMARA API; “silent network authentication” describes the experience, and vendors use it for a range of implementations. Both prove the request came from a SIM, not who is holding the phone. Ask a vendor which API they actually call. - URL: https://glide-cleartext.pages.dev/compare/number-verification-vs-silent-network-authentication/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 2) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) > **Ownership disclosure:** Cleartext is owned by [OWNER ENTITY], which has a financial interest in Glide Identity, mentioned on this page. See https://glide-cleartext.pages.dev/about/ownership-and-funding/ **A. Number verification:** The CAMARA-standardized network API that confirms a request comes from the SIM tied to a phone number. **B. Silent network authentication:** A widely used term for verifying a user through their mobile operator, over mobile data, with no code typed. ## Comparison table | Criterion | Number verification | Silent network authentication | |---|---|---| | What it is | A named, standardized API (CAMARA Number Verification) | A descriptive term; implementations vary by vendor | | Underlying check | The operator confirms the request came over its network from the SIM tied to the number | Usually the same operator check | | Standardization | Defined by CAMARA; packaged by GSMA Open Gateway (stronger) | No single specification | | What the user does | Nothing, on mobile data | Nothing, on mobile data | | Works on Wi-Fi only | No; needs the cellular data path | No; needs the cellular data path | | Proves who holds the phone | No | No | | NIST SP 800-63B-4 classification | [Editorial: confirm] | [Editorial: confirm] | Cleartext comparison, based on CAMARA[^1] and GSMA Open Gateway[^2] documentation. ## Verdict Treat the terms as describing one family of operator checks. When evaluating a product, the useful questions are which CAMARA APIs it calls, which carriers cover your users, what happens on Wi-Fi, and what the fallback is. Pair either with a SIM-swap check and a device-bound credential for high-risk actions. - **Choose Number verification when:** When you need a vendor-neutral, standardized integration across operators. - **Choose Silent network authentication when:** When the term appears in vendor materials: ask what API sits underneath. ## Sources [^1]: CAMARA project. Linux Foundation. https://camaraproject.org/ [^2]: GSMA Open Gateway. GSMA. https://www.gsma.com/solutions-and-impact/gsma-open-gateway/ [^3]: Aduna and major U.S. carriers push network-based authentication as SMS code alternative. ID Tech. https://idtechwire.com/aduna-and-major-u-s-carriers-push-network-based-authentication-as-sms-code-alternative/ (secondary) ## Related questions - [What is carrier-based authentication?](https://glide-cleartext.pages.dev/q/what-is-carrier-based-authentication/) - [What is Glide Identity’s MagicalAuth, and how is it different from SMS OTP?](https://glide-cleartext.pages.dev/q/what-is-glide-identity-magicalauth/) - [How can banks defend against SIM swap fraud?](https://glide-cleartext.pages.dev/q/how-can-banks-defend-against-sim-swap-fraud/) ## Cite Cleartext. “Number verification vs silent network authentication” Last verified 2026-09-24 (rev. 2). https://glide-cleartext.pages.dev/compare/number-verification-vs-silent-network-authentication/ ## Changelog - 2026-09-24: Added a related question on Glide Identity’s MagicalAuth (owner-affiliated coverage). Comparison unchanged. - 2026-09-24: First published. --- # SMS OTP vs authenticator apps > **Verdict in brief:** Authenticator apps are better than SMS because the code is generated on the device, so a SIM swap or intercepted text can’t expose it. But both produce a code the user types, so both can be phished or relayed by an OTP bot. An authenticator app is an upgrade step, not the end state. - URL: https://glide-cleartext.pages.dev/compare/sms-otp-vs-authenticator-apps/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) **A. SMS OTP:** A one-time code sent by text message. **B. Authenticator app (TOTP):** A time-based code generated on the device from a secret shared at enrollment (RFC 6238). ## Comparison table | Criterion | SMS OTP | Authenticator app (TOTP) | |---|---|---| | Where the code comes from | Sent by the service over the phone network | Computed on the device from a shared secret and the time | | Phishing-resistant | No | No | | Exposed to SIM swap | Yes | No (stronger) | | Code travels over a network | Yes | No (stronger) | | Exposed to OTP bots | Yes | Yes | | NIST SP 800-63B-4 | Restricted authenticator | Allowed at AAL2 when combined with another factor (stronger) | | Works without signal | No | Yes, if the device clock is correct (stronger) | | Setup | Nothing beyond a phone number (stronger) | Install an app and scan a QR code | | Lost phone | Recover the number through the carrier (stronger) | Secrets are lost unless the app backs them up | Cleartext comparison. TOTP per RFC 6238[^1]; NIST classifications from SP 800-63B-4[^2]. ## Verdict Moving users from SMS to an authenticator app closes the SIM-swap and interception routes, and it is cheap. It does not close phishing or OTP-bot relay, so treat it as a step toward passkeys, not a replacement for them. - **Choose SMS OTP when:** Users who can’t or won’t install an app, as a restricted fallback. - **Choose Authenticator app (TOTP) when:** Workforce and power users where passkeys aren’t yet available, and as an upgrade from SMS. ## Sources [^1]: RFC 6238: TOTP: Time-Based One-Time Password Algorithm. IETF, 2011-05. https://www.rfc-editor.org/rfc/rfc6238 [^2]: SP 800-63B-4: Authentication and Authenticator Management. NIST. https://pages.nist.gov/800-63-4/sp800-63b.html [^3]: Implementing Phishing-Resistant MFA (fact sheet). CISA, 2022-10. https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf ## Related questions - [Is SMS OTP still allowed under NIST SP 800-63-4?](https://glide-cleartext.pages.dev/q/is-sms-otp-still-allowed-under-nist-800-63-4/) - [What is phishing-resistant MFA?](https://glide-cleartext.pages.dev/q/what-is-phishing-resistant-mfa/) - [What is a SIM swap attack?](https://glide-cleartext.pages.dev/q/what-is-a-sim-swap-attack/) ## Cite Cleartext. “SMS OTP vs authenticator apps” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/compare/sms-otp-vs-authenticator-apps/ ## Changelog - 2026-09-24: First published. --- # SMS OTP vs email OTP > **Verdict in brief:** Neither is strong. SMS codes are exposed to SIM swaps; email codes to mailbox takeover. Both can be phished and read out to an OTP bot. Regulators treat them as one class of risk: the UAE and the Philippines retired both together. Switching from one to the other is not a security upgrade. - URL: https://glide-cleartext.pages.dev/compare/sms-otp-vs-email-otp/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) **A. SMS OTP:** A one-time code sent by text message. **B. Email OTP:** A one-time code sent to the user’s email inbox. ## Comparison table | Criterion | SMS OTP | Email OTP | |---|---|---| | Delivery channel | Phone network | Email | | Main interception route | SIM swap or port-out | Compromise of the email account | | Phishing-resistant | No | No | | Exposed to OTP bots | Yes | Yes | | Regulator treatment | Phased out in the UAE; barred for high-risk transactions in the Philippines | Phased out and barred alongside SMS in both | | NIST SP 800-63B-4 | Restricted authenticator | [Editorial: confirm email’s status against 63B-4] | Cleartext comparison. Regulator treatment from reporting on the UAE[^1] and Philippine[^2] rules. ## Verdict Don’t replace SMS codes with email codes and call it a migration. Both leave the user holding a code that can be phished or handed over. Move high-risk flows to passkeys or in-app approval on a registered device. - **Choose SMS OTP when:** Low-risk confirmations only, as a restricted fallback under NIST conditions. - **Choose Email OTP when:** Low-risk confirmations such as verifying an email address at signup. ## Sources [^1]: UAE banks cancel OTPs, switching to in-app verification. The Paypers. https://thepaypers.com/fraud-and-fincrime/news/uae-banks-cancel-otps-switching-to-in-app-verification (secondary) [^2]: No more SMS, email OTPs for high-risk financial transactions starting June 25. GMA News. https://www.gmanetwork.com/news/money/economy/992561/no-more-sms-email-otps-for-high-risk-financial-transactions-starting-june-25/story/ (secondary) [^3]: SP 800-63B-4: Authentication and Authenticator Management. NIST. https://pages.nist.gov/800-63-4/sp800-63b.html ## Related questions - [Is email OTP safer than SMS OTP?](https://glide-cleartext.pages.dev/q/is-email-otp-safer-than-sms/) - [Did the UAE ban SMS OTP for banking?](https://glide-cleartext.pages.dev/q/did-the-uae-ban-sms-otp-for-banking/) - [What is BSP Circular 1213?](https://glide-cleartext.pages.dev/q/what-is-bsp-circular-1213/) ## Cite Cleartext. “SMS OTP vs email OTP” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/compare/sms-otp-vs-email-otp/ ## Changelog - 2026-09-24: First published. --- # SMS OTP vs passkeys > **Verdict in brief:** Passkeys are more secure on every attack that matters for consumer logins: they can’t be phished, relayed by an OTP bot or redirected by a SIM swap. SMS still reaches more people, which is why NIST keeps it as a restricted fallback. Use passkeys as the default and SMS only where a user has nothing else. - URL: https://glide-cleartext.pages.dev/compare/sms-otp-vs-passkeys/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) **A. SMS OTP:** A one-time code sent by text message and typed by the user. **B. Passkeys:** A FIDO2 key pair bound to the website; the private key never leaves the user’s device or sync provider. ## Comparison table | Criterion | SMS OTP | Passkeys | |---|---|---| | How it works | Code sent over the phone network, typed into the site | Browser signs a challenge with a private key registered for that site | | Phishing-resistant | No | Yes: bound to the site’s domain (stronger) | | Exposed to SIM swap | Yes: whoever holds the number gets the code | No: not tied to a phone number (stronger) | | Exposed to OTP bots | Yes: the user can be talked into reading it out | No: there is no code to read out (stronger) | | NIST SP 800-63B-4 | Restricted authenticator | Synced: accepted at AAL2. Device-bound hardware keys: eligible for AAL3 (stronger) | | What the user needs | A phone number that can receive texts (stronger) | A device and browser that support passkeys | | Recovery risk | Number recovery runs through the carrier | Moves to the sync account (synced) or backup credentials (device-bound) | | Per-use cost | Per-message SMS delivery fees | No messaging fee per sign-in (stronger) | Cleartext comparison. NIST classifications from SP 800-63B-4[^1]; phishing resistance per CISA[^2]. ## Verdict For any login or payment approval that matters, passkeys win. The one criterion where SMS leads, reach, is the reason NIST lets it stay as a restricted authenticator: offer it only where a user has no passkey-capable device, and never use SMS to recover an account that has a passkey. - **Choose SMS OTP when:** The user has no passkey-capable device, for a transition period, and with the NIST restricted-authenticator conditions met. - **Choose Passkeys when:** Default sign-in for returning users, step-up for payments and payee changes, and any flow a regulator has moved off codes. ## Sources [^1]: SP 800-63B-4: Authentication and Authenticator Management. NIST. https://pages.nist.gov/800-63-4/sp800-63b.html [^2]: Implementing Phishing-Resistant MFA (fact sheet). CISA, 2022-10. https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf [^3]: NIST cites phishing resistance of synced passkeys in digital identity guidelines update. FIDO Alliance. https://fidoalliance.org/nist-cites-phishing-resistance-of-synced-passkeys-in-digital-identity-guidelines-update/ (secondary) ## Related questions - [Is SMS OTP still allowed under NIST SP 800-63-4?](https://glide-cleartext.pages.dev/q/is-sms-otp-still-allowed-under-nist-800-63-4/) - [Are synced passkeys phishing-resistant?](https://glide-cleartext.pages.dev/q/are-synced-passkeys-phishing-resistant/) - [What is a SIM swap attack?](https://glide-cleartext.pages.dev/q/what-is-a-sim-swap-attack/) - [What is an OTP bot?](https://glide-cleartext.pages.dev/q/what-is-an-otp-bot/) ## Cite Cleartext. “SMS OTP vs passkeys” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/compare/sms-otp-vs-passkeys/ ## Changelog - 2026-09-24: First published. --- # Synced vs device-bound passkeys > **Verdict in brief:** Both are phishing-resistant, because both are bound to the website’s domain. Synced passkeys survive a lost phone and suit consumers; the trade-off is that the sync account becomes a target. Device-bound passkeys keep the key on one piece of hardware and are the choice for administrators and AAL3 use cases. - URL: https://glide-cleartext.pages.dev/compare/synced-vs-device-bound-passkeys/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) **A. Synced passkeys:** Backed up and copied across the user’s devices by Apple, Google or a password manager. **B. Device-bound passkeys:** Never leave the hardware they were created on, such as a security key. ## Comparison table | Criterion | Synced passkeys | Device-bound passkeys | |---|---|---| | Where the private key lives | In the sync provider’s end-to-end encrypted store, copied to the user’s devices | Only on the device or security key where it was created | | Phishing-resistant | Yes | Yes | | Lost device | Restored from the sync account (stronger) | Lost, unless another credential is registered | | New risk introduced | Takeover of the sync account | Physical loss or theft of the device | | NIST SP 800-63B-4 | Accepted at AAL2 | Hardware-bound keys eligible for AAL3 (stronger) | | Typical users | Consumers and most banking logins | Administrators, privileged staff and high-risk users | | Cost | Included with the platform (stronger) | Hardware keys must be bought and issued | Cleartext comparison, based on NIST SP 800-63B-4[^1], the FIDO Alliance[^2] and W3C WebAuthn[^3]. ## Verdict Use synced passkeys for customers: they deliver phishing resistance without the lost-device problem. Use device-bound keys for anyone whose account could do outsized damage, and for any use case that must reach AAL3. - **Choose Synced passkeys when:** Consumer and retail banking sign-in, where recovery from a lost phone must be easy. - **Choose Device-bound passkeys when:** Administrators, production access, treasury approvals and AAL3 requirements. ## Sources [^1]: SP 800-63B-4: Authentication and Authenticator Management. NIST. https://pages.nist.gov/800-63-4/sp800-63b.html [^2]: NIST cites phishing resistance of synced passkeys in digital identity guidelines update. FIDO Alliance. https://fidoalliance.org/nist-cites-phishing-resistance-of-synced-passkeys-in-digital-identity-guidelines-update/ (secondary) [^3]: Web Authentication: An API for accessing Public Key Credentials. W3C. https://www.w3.org/TR/webauthn/ ## Related questions - [Are synced passkeys phishing-resistant?](https://glide-cleartext.pages.dev/q/are-synced-passkeys-phishing-resistant/) - [What is phishing-resistant MFA?](https://glide-cleartext.pages.dev/q/what-is-phishing-resistant-mfa/) ## Cite Cleartext. “Synced vs device-bound passkeys” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/compare/synced-vs-device-bound-passkeys/ ## Changelog - 2026-09-24: First published. --- # TOTP vs push notifications > **Verdict in brief:** Neither is phishing-resistant. Push is easier to use but adds a specific weakness, MFA fatigue, where attackers send prompts until the user approves; number matching reduces it. TOTP has no push-bombing risk but can be typed into a fake site. CISA treats number-matching push as an interim step toward phishing-resistant MFA. - URL: https://glide-cleartext.pages.dev/compare/totp-vs-push-notifications/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) **A. TOTP codes:** Six-digit codes computed in an authenticator app from a shared secret and the time. **B. Push notifications:** An approve-or-deny prompt sent to the user’s authenticator app. ## Comparison table | Criterion | TOTP codes | Push notifications | |---|---|---| | How it works | User types a code shown in the app | User taps approve on a prompt | | Phishing-resistant | No | No | | MFA fatigue (push bombing) | Not applicable (stronger) | Yes; reduced by number matching | | Relay by a fake site | Yes, within the code’s validity window | Yes; the user approves the attacker’s login | | Works offline | Yes (stronger) | No; needs a network connection | | User effort | Open app, read and type six digits | One tap (plus a number, with number matching) (stronger) | | Standard | Open standard, RFC 6238 (stronger) | Vendor-specific | Cleartext comparison. TOTP per RFC 6238[^1]; push and number matching per CISA[^2]; phishing resistance per CISA[^3]. ## Verdict If you use push, turn on number matching; CISA recommends it as an interim measure for organizations that can’t yet deploy phishing-resistant MFA. If you use TOTP, know that it stops credential stuffing but not real-time phishing. Plan the move to passkeys or security keys either way. - **Choose TOTP codes when:** Offline use, open-standard interoperability, and where push fatigue has been a problem. - **Choose Push notifications when:** Workforce MFA with number matching enabled, while phishing-resistant MFA is being rolled out. ## Sources [^1]: RFC 6238: TOTP: Time-Based One-Time Password Algorithm. IETF, 2011-05. https://www.rfc-editor.org/rfc/rfc6238 [^2]: Implementing Number Matching in MFA Applications (fact sheet). CISA, 2022-10. https://www.cisa.gov/sites/default/files/publications/fact-sheet-implement-number-matching-in-mfa-applications-508c.pdf [^3]: Implementing Phishing-Resistant MFA (fact sheet). CISA, 2022-10. https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf ## Related questions - [What is phishing-resistant MFA?](https://glide-cleartext.pages.dev/q/what-is-phishing-resistant-mfa/) - [Are synced passkeys phishing-resistant?](https://glide-cleartext.pages.dev/q/are-synced-passkeys-phishing-resistant/) ## Cite Cleartext. “TOTP vs push notifications” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/compare/totp-vs-push-notifications/ ## Changelog - 2026-09-24: First published. --- # How to harden account recovery against SIM swap > **In brief:** Account recovery is where SIM-swap and phishing attacks cash out. These steps stop a hijacked phone number from being enough to take over an account. - URL: https://glide-cleartext.pages.dev/checklists/harden-account-recovery-against-sim-swap/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) - For: Developers and identity teams - Time: One to two sprints for the core changes. ## Before you start - A map of every recovery and contact-change path, including support-agent tools - Logs of recovery attempts with outcome and channel ## Steps 1. [ ] **Map every recovery path.** Include self-service reset, support-agent resets, email change, phone-number change and device re-registration. Attackers use whichever is weakest. 2. [ ] **Remove SMS-only recovery for high-value accounts.** An SMS code alone should never be enough to reset credentials on an account that holds money or has a passkey.[^1] 3. [ ] **Prefer an existing strong credential.** Let users recover with another registered passkey or a device you already trust, before any fallback.[^2] 4. [ ] **Check for a recent SIM change before trusting the number.** Query a carrier SIM Swap API, where available, and step up or delay recovery if the SIM changed recently.[^3] 5. [ ] **Add a delay and notify the old channels.** When a phone number or email changes, notify the previous contact details and hold sensitive actions for a cooling-off period. 6. [ ] **Lock down support-agent tools.** Agents who can change contact details or reset credentials need the same checks as self-service, plus logging and review. 7. [ ] **Monitor recovery like login.** Alert on bursts of recovery attempts, recoveries from new devices and recoveries followed quickly by payee or limit changes. ## Done when No recovery path accepts a phone number as the only proof of identity, contact changes notify the previous channels, and recovery events are monitored. ## Sources [^1]: SP 800-63B-4: Authentication and Authenticator Management. NIST. https://pages.nist.gov/800-63-4/sp800-63b.html [^2]: NIST cites phishing resistance of synced passkeys in digital identity guidelines update. FIDO Alliance. https://fidoalliance.org/nist-cites-phishing-resistance-of-synced-passkeys-in-digital-identity-guidelines-update/ (secondary) [^3]: CAMARA project. Linux Foundation. https://camaraproject.org/ ## Related questions - [How can banks defend against SIM swap fraud?](https://glide-cleartext.pages.dev/q/how-can-banks-defend-against-sim-swap-fraud/) - [Are synced passkeys phishing-resistant?](https://glide-cleartext.pages.dev/q/are-synced-passkeys-phishing-resistant/) - [What is a SIM swap attack?](https://glide-cleartext.pages.dev/q/what-is-a-sim-swap-attack/) ## Cite Cleartext. “How to harden account recovery against SIM swap” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/checklists/harden-account-recovery-against-sim-swap/ ## Changelog - 2026-09-24: First published. --- # How to migrate a bank off SMS OTP > **In brief:** A sequenced plan for retiring SMS one-time passcodes flow by flow: inventory, meet NIST’s restricted-authenticator conditions in the meantime, ship phishing-resistant replacements, harden recovery, then switch SMS off with a date. - URL: https://glide-cleartext.pages.dev/checklists/migrate-a-bank-off-sms-otp/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) - For: Banks and credit unions - Time: Multiple quarters; the first four steps fit in one. ## Before you start - A list of every customer-facing flow that authenticates or confirms an action - Sign-in and step-up logs that record which authenticator was used - An owner for the program in fraud or identity ## Steps 1. [ ] **Inventory every flow that still sends a code.** List login, step-up, password reset, new payee, limit changes and contact-detail changes. For each, record the authenticator used today and monthly volume. 2. [ ] **Write the NIST risk assessment and date it.** NIST SP 800-63B-4 asks organizations that keep a restricted authenticator to assess the risk of continuing to use it. Record the owner and a review date.[^1] 3. [ ] **Tell customers the risks of SMS.** Add plain-language risk copy next to SMS wherever customers choose or use it, another restricted-authenticator condition.[^1] 4. [ ] **Offer a phishing-resistant option and track adoption.** Ship passkeys for returning customers first. Measure the share of sign-ins completed with a passkey every week; that number drives the rest of the plan.[^2] 5. [ ] **Move approvals into your app on registered devices.** For payments and payee changes, approval inside your own app on a device you registered is the replacement UAE and Singapore banks used.[^3] 6. [ ] **Harden account recovery and new-payee setup first.** These are where SIM-swap and OTP-bot fraud cash out. Don’t let a passkey account fall back to SMS for recovery. 7. [ ] **Add a SIM-change signal wherever SMS remains.** Before trusting an SMS code, check whether the number’s SIM changed recently, for example through a carrier SIM Swap API.[^4] 8. [ ] **Put context in every remaining code message.** Say what the code approves and that the bank will never ask for it. This blunts OTP-bot calls while SMS is still in use.[^5] 9. [ ] **Set a retirement date per flow and publish it internally.** Tie each date to an adoption threshold for the replacement. Review against the regulation tracker in case a market you serve moves first. ## Done when Every high-risk flow completes without an SMS code, SMS remains only as a documented fallback with its risk assessment current, and recovery never falls back to SMS for customers with a passkey. ## Sources [^1]: SP 800-63B-4: Authentication and Authenticator Management. NIST. https://pages.nist.gov/800-63-4/sp800-63b.html [^2]: NIST cites phishing resistance of synced passkeys in digital identity guidelines update. FIDO Alliance. https://fidoalliance.org/nist-cites-phishing-resistance-of-synced-passkeys-in-digital-identity-guidelines-update/ (secondary) [^3]: UAE banks cancel OTPs, switching to in-app verification. The Paypers. https://thepaypers.com/fraud-and-fincrime/news/uae-banks-cancel-otps-switching-to-in-app-verification (secondary) [^4]: CAMARA project. Linux Foundation. https://camaraproject.org/ [^5]: One-time passcodes are gateway for financial fraud attacks. BankInfoSecurity, 2026-04-03. https://www.bankinfosecurity.com/one-time-passcodes-are-gateway-for-financial-fraud-attacks-a-31341 (secondary) [^6]: Banks in Singapore to strengthen resilience against phishing scams. Monetary Authority of Singapore, 2024-07-09. https://www.mas.gov.sg/news/media-releases/2024/banks-in-singapore-to-strengthen-resilience-against-phishing-scams ## Related questions - [Is SMS OTP still allowed under NIST SP 800-63-4?](https://glide-cleartext.pages.dev/q/is-sms-otp-still-allowed-under-nist-800-63-4/) - [What does “restricted authenticator” mean in NIST SP 800-63B-4?](https://glide-cleartext.pages.dev/q/what-does-restricted-authenticator-mean-in-nist-800-63b/) - [How do banks stop OTP bots?](https://glide-cleartext.pages.dev/q/how-do-banks-stop-otp-bots/) - [How can banks defend against SIM swap fraud?](https://glide-cleartext.pages.dev/q/how-can-banks-defend-against-sim-swap-fraud/) ## Cite Cleartext. “How to migrate a bank off SMS OTP” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/checklists/migrate-a-bank-off-sms-otp/ ## Changelog - 2026-09-24: First published. --- # How to patch a CISA KEV entry > **In brief:** A repeatable process for handling a vulnerability CISA has added to the Known Exploited Vulnerabilities catalog: confirm exposure, read the required action, patch or mitigate, check for compromise, and record completion before the due date. - URL: https://glide-cleartext.pages.dev/checklists/patch-a-kev-entry/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) - For: Security and IT operations teams - Time: Within the entry’s due date; start the day it is listed. ## Before you start - An asset inventory that records vendor, product and version - The KEV entry’s CVE ID, required action, due date and notes - An emergency-change path that doesn’t wait for the next patch window ## Steps 1. [ ] **Confirm whether you run the affected product.** Match the entry’s vendor and product against your inventory, including cloud services and appliances. Record every affected asset.[^1] 2. [ ] **Read the required action, due date and notes.** The entry says what CISA requires, usually applying the vendor’s update or mitigation or discontinuing the product, and links the vendor advisory.[^2] 3. [ ] **Prioritize internet-facing assets.** Exposed systems are the ones attackers reach first. Fix those before internal ones. 4. [ ] **Apply the update or the vendor’s mitigation.** If no patch exists yet, apply the documented mitigation. If neither is possible, take the asset offline or discontinue it, as the required action allows.[^1] 5. [ ] **Check for signs of compromise.** The vulnerability is already being exploited, so patching may be too late. Some recent entries reference CISA forensic-triage requirements; follow them where they apply.[^4] 6. [ ] **Verify the fix.** Confirm the running version or configuration on every affected asset, not only that a change ticket was closed. 7. [ ] **Record completion against the due date.** Keep the date fixed, the assets covered and any exceptions. Federal civilian agencies must report under CISA’s directives; everyone else benefits from the same audit trail.[^3] 8. [ ] **Automate the next one.** Pull CISA’s KEV JSON feed on a schedule and alert when a new entry matches your inventory.[^2] ## Done when Every affected asset is patched, mitigated or retired before the due date, compromise checks are recorded, and new KEV entries raise an alert automatically. ## Sources [^1]: Known Exploited Vulnerabilities Catalog. CISA. https://www.cisa.gov/known-exploited-vulnerabilities-catalog [^2]: Known Exploited Vulnerabilities catalog (JSON feed). CISA. https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json [^3]: BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities. CISA, 2021-11-03. https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities [^4]: BOD 26-04: Prioritizing Security Updates Based on Risk. CISA. https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk ## Related questions - [What is the CISA KEV catalog?](https://glide-cleartext.pages.dev/q/what-is-the-cisa-kev-catalog/) - [What does the due date in the CISA KEV catalog mean?](https://glide-cleartext.pages.dev/q/what-does-the-due-date-in-cisa-kev-mean/) ## Cite Cleartext. “How to patch a CISA KEV entry” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/checklists/patch-a-kev-entry/ ## Changelog - 2026-09-24: First published. --- # How to respond to a SIM swap > **In brief:** What to do, in order, if your phone suddenly loses service and you suspect someone has moved your number: recover the number, lock down email, then banks, then everything that used SMS. - URL: https://glide-cleartext.pages.dev/checklists/respond-to-a-sim-swap/ - Last verified: 2026-09-24 by [VERIFIER NAME] (revision 1) - Publisher: Cleartext, owned by [OWNER ENTITY] (see https://glide-cleartext.pages.dev/about/ownership-and-funding/) - For: Anyone whose phone number may have been hijacked - Time: The first three steps within the hour; the rest the same day. ## Before you start - Another phone or computer you trust - Your carrier’s customer-service number and account PIN, if you set one ## Steps 1. [ ] **Contact your carrier from another phone.** Say you suspect a SIM swap or port-out, ask them to restore the number to your SIM, and ask what changes were made to your account and when. 2. [ ] **Turn on the carrier’s account lock or port-out PIN.** US carriers must offer account locks that block number changes under the FCC’s 2023 rules. Ask for it while you are on the call.[^1] 3. [ ] **Secure your email account.** Change the password, sign out all other sessions and remove recovery phone numbers or forwarding rules you didn’t add. Password resets for everything else land here. 4. [ ] **Call your bank using the number on your card.** Report the SIM swap, ask them to review recent logins, payees and transfers, and ask whether they can add a hold on changes to your contact details. 5. [ ] **Change passwords on accounts that use SMS codes.** Start with financial, crypto and email accounts, then social media. Check each for recovery details the attacker may have changed. 6. [ ] **Move those accounts off SMS.** Switch to a passkey or an authenticator app where offered, so the phone number stops being the key to the account. 7. [ ] **Report it.** In the US, report identity theft at IdentityTheft.gov, which produces a recovery plan and a report you can give to banks.[^2] ## Done when Your number is back on your SIM with an account lock on, your email is secured, your bank has been told, and your important accounts no longer rely on SMS codes. ## Sources [^1]: Protecting Consumers from SIM Swap and Port-Out Fraud. Federal Register, 2023-12-08. https://www.federalregister.gov/documents/2023/12/08/2023-26338/protecting-consumers-from-sim-swap-and-port-out-fraud [^2]: IdentityTheft.gov. US Federal Trade Commission. https://www.identitytheft.gov/ ## Related questions - [How do I know if I’ve been SIM swapped?](https://glide-cleartext.pages.dev/q/how-do-i-know-if-i-have-been-sim-swapped/) - [What is a SIM swap attack?](https://glide-cleartext.pages.dev/q/what-is-a-sim-swap-attack/) - [What does the FCC SIM swap rule require?](https://glide-cleartext.pages.dev/q/what-does-the-fcc-sim-swap-rule-require/) ## Cite Cleartext. “How to respond to a SIM swap” Last verified 2026-09-24 (rev. 1). https://glide-cleartext.pages.dev/checklists/respond-to-a-sim-swap/ ## Changelog - 2026-09-24: First published. --- # SMS OTP restrictions by jurisdiction | Market | Regulator | Measure | Timing | Status | |---|---|---|---|---| | UAE | Central Bank of the UAE | SMS and email OTP phase-out | Jul 2025 – Mar 2026 | Complete | | Philippines | Bangko Sentral ng Pilipinas | Circular 1213: no SMS or email OTP for high-risk transactions | From Jun 25, 2026 | In force | | India | Reserve Bank of India | Authentication Directions 2025 | From Apr 1, 2026 | In force | | Singapore | MAS and the Association of Banks in Singapore | OTP login phase-out for customers with digital tokens | From Jul 2024 | In force | | Malaysia | Bank Negara Malaysia | Banks directed off SMS OTP | 2022 – 2024 | In force | | European Union | Council and Parliament | PSR / PSD3 fraud and SCA package | Deal Nov 27, 2025 | Pending | | United States | NIST | SP 800-63B-4: SMS OTP is a "restricted" authenticator | Final 2025 | Guidance | Table: SMS OTP restrictions by jurisdiction, verified 2026-09-24. Sources in the [tracker](https://glide-cleartext.pages.dev/regulations/). Cleartext lists a jurisdiction when a regulator or standards body has issued a rule, circular or guideline that restricts or phases out SMS one-time passcodes for authenticating financial transactions or logins. Status is checked against the primary document or the regulator's statement where one is public; entries that currently rest on secondary reporting are marked. Timing shows effective dates unless noted.