Evaluating Glide Identity: what each desk should ask before a pilot

How to read this brief

This is a due-diligence kit, not a review. It collects what the company says, what is on the public record with a date and a source, and the questions each desk should put to the vendor before a pilot. The questions are written for Glide Identity but work for any comparable vendor. Ask every comparable vendor the same questions, and run the same pilot, before comparing.

Ask every comparable vendor the same questions, and run the same pilot, before comparing.

Several unrelated companies are also called Glide, including a UK fibre company, an embedded-banking fintech and a no-code app builder. This brief covers Glide Identity only.

The company in one paragraph

Glide Identity is a US authentication company that trades under the Glide.id brand; its older domain, glideidentity.com, redirects to glide.id. It sells alternatives to SMS one-time passcodes built on the mobile network and the SIM. In October 2025 it raised a Series A of more than $20 million led by Crosspoint Capital Partners,^[8][9] and its website lists Strategic Ventures and Amigos Venture Capital among its investors.^[2] It is a Sponsor-level member of the FIDO Alliance^[15] and is listed as a GSMA Open Gateway partner.^[16] It does not publish pricing, and its developer documentation (docs.glideidentity.com) requires a login.

What Glide says its products do

Everything in this table is the company’s own description. We have not tested any of it.

The company also says it holds ISO 27001, 27701, 42001 and 22301 certifications and FIDO certification, and that it complies with GDPR and CCPA. We have not independently verified these claims. The compliance questions below cover what to ask for.

On the record: dated milestones

On the RSAC placing, the sources differ. Glide’s own Business Wire release says “Top 10 Finalist”;^[10] its website press page describes it as “Top 2 Finalist”, which RSAC’s materials do not confirm.^[5][11] We use RSAC’s framing: one of 10 finalists.

What we don’t know

Our sources leave five questions open. Each one maps to a question set below.

• NIST classification. How NIST SP 800-63B-4 would classify SIM-based cryptographic authentication is not addressed in our sources.^[18]
• Real-world coverage in the beta. Which devices, operating systems and plans work, and how often fallback triggers.
• Pricing and carrier dependence. Pricing isn’t published, and the contractual dependence on carriers isn’t documented.
• Independent security testing. We found no independent security assessment in our sources.
• SIM swaps and eSIM transfers. The company positions its method against SIM swap; how it handles a swap or an eSIM transfer at the carrier has not been independently verified.

Questions by desk

Each set is written for Glide Identity and works unchanged for any comparable vendor. Ask for the answers in writing and keep them in the evaluation file. Our SMS OTP alternatives buyer’s guide has the eight questions to ask every vendor; these go further, desk by desk.

CISOs

1. How do you classify MagicalAuth and SuperPasskey under NIST SP 800-63B-4: authenticator type, assurance level and phishing resistance? Will you put that position in writing?
2. Which parts of the service are in beta, what are the criteria for general availability, and what changes in the contract when it arrives?
3. What is your contractual dependence on each carrier, and what happens to our customers if a carrier changes terms or leaves?
4. Which independent security assessments exist, who performed them, and can we read the reports?
5. What is your incident-notification commitment, and who do we call?
6. If we end the contract, how do our customers keep signing in, and how long does the switch take?

Fraud & risk

1. You position the method against SIM swap. Walk us through exactly what happens when a customer’s SIM is swapped at the carrier, and when an eSIM is moved to a new device. What evidence can you show?
2. What result do we receive for each attempt, including failure reasons, and can we feed it into our fraud engine?
3. When fallback triggers, which method does the customer get, who decides, and can we block email-link fallback on high-risk flows such as recovery and new payees?
4. What does the customer see and approve? How does the flow hold up when a fraudster on the phone coaches the customer through it?
5. Which of our flows (sign-in, recovery, new payee, payment step-up) do you support, and what is the fallback for each?
6. How are prepaid, business, roaming and dual-SIM customers handled?

IAM engineers

1. Which devices, operating system versions, browsers and carrier plans work in the beta today? Give us a coverage matrix, not a single percentage.
2. How do the iOS, Android and web SDKs and the REST API fit our identity provider and session model? Can we read the documentation before we sign?
3. How does SuperPasskey relate to passkeys registered to our own domain? Who holds the passkey, and does it keep working if we leave?
4. What does the web flow need from the device and the network, and what happens on a desktop browser or on Wi-Fi?
5. How does account recovery work when a customer loses the phone or changes number?
6. What are the API versioning and deprecation policy, rate limits and service levels?

Security engineers

1. Share your threat model. What does the design trust: the SIM, the carrier, your service, our backend?
2. How is the result delivered to our backend, and how do we verify it, bind it to our session and prevent replay?
3. Which keys are involved, where are they held and who can use them?
4. If your service or a carrier is unavailable, does the flow fail open or closed, and what do we see?
5. What logs can we export to our SIEM for detection and investigation?
6. Do you run a vulnerability disclosure program, and can we see penetration-test results with a date and a named tester?

Compliance

1. What personal data do you process (phone numbers, device and carrier data), which carriers and subprocessors receive it, where is it stored and for how long?
2. Can we see the ISO 27001, 27701, 42001 and 22301 certificates with their scope and issuing body, the details of the FIDO certification, and the basis for your GDPR and CCPA statements?
3. Will your written NIST SP 800-63B-4 position support our risk assessment, and how does the method fit the rules in the markets we serve? Check against our regulations tracker.
4. What do we need to tell customers about carrier checks, and is consent required in our markets?
5. How do you review your own marketing claims? For example, your press page and your own release describe your RSAC 2026 placing differently.
6. How accessible are the primary flow and the fallback?

Product & payments

1. Pricing isn’t published. What does it cost, in writing: per attempt or per success, fallback charges, carrier pass-through costs, minimums, and beta versus general-availability pricing?
2. For Glide-Out, which payment flows are supported, what does the customer see, and how does it relate to strong customer authentication rules in the markets we serve?
3. What does the customer see when the method fails, and what should our support scripts say?
4. Which markets outside the United States are covered today?
5. What are the contract term, data-return terms and notice period if we switch back to SMS or to another vendor?
6. Can we speak to organizations running it in production, not only in the beta?

The pilot plan

The steps below work for any SMS OTP alternative. Run the same plan for every vendor on the shortlist so the results can be compared.

01Step 1 Agree scope, success criteria and the exit in writing

Pick one or two flows, name the owner, and write down what would make you stop the pilot early. Agree data-processing terms, the pilot’s end date and how customer data is returned or deleted before any customer is enrolled. [YOUR PILOT SCOPE]

02Step 2 Get written answers to every desk’s questions

Send the six question sets above as one document and ask for written replies. At minimum, get the NIST SP 800-63B-4 position, the coverage matrix, the certificates with their scope, any independent assessment reports and pricing. Missing answers are findings too.

03Step 3 Map coverage against your own customers

Compare the vendor’s coverage matrix with your own device, operating-system and carrier mix [YOUR DATA]. Identify the customers who will always fall back, and decide whether the method is worth running for the rest.

04Step 4 Design fallback and recovery before you integrate

Decide which fallback each flow gets. Do not let high-risk flows, such as recovery and new payees, fall back to anything weaker than you accept today. If SMS stays as a fallback, the NIST SP 800-63B-4 obligations for restricted authenticators still apply.^[18] Our NIST 800-63-4 field guide lists them.

05Step 5 Test adversarially in a test environment

With test lines on each carrier, run the scenarios the vendor’s claims depend on: a SIM swap at the carrier, an eSIM transfer, a number port, a new device, a lost phone, a replayed result and a customer coached through the flow by a caller. Use an independent tester if you can. Record pass or fail for each scenario.

06Step 6 Run a limited live pilot against a control group

Enroll a limited, randomly assigned group [YOUR PILOT SIZE] and keep a control group on your current method, so any change in fraud, support contacts or completion can be attributed. Watch fallback rates daily in the first weeks.

07Step 7 Measure, decide and document

Report the measures below for both groups, write a decision memo, and file the results with your NIST risk assessment. We don’t publish benchmarks we can’t source, so the targets are yours to set.

Who owns this

Compare against

A pilot result means little without a baseline. Keep your current SMS flow as the control, and put the same questions to the other approaches in our SMS OTP alternatives buyer’s guide:

• Passkeys (FIDO2): key pairs bound to your domain; synced passkeys are accepted at AAL2.^[18]
• In-app approval on a registered device: the customer confirms in your own app.
• Carrier network checks: number verification and SIM-change signals from the mobile operator, defined in CAMARA’s APIs.^[19]
• SIM-based cryptographic authentication: the approach Glide describes for its own method.
• Authenticator app codes (TOTP): allowed at AAL2, but still a code that can be phished or read out.^[18]

Other companies offering network-based or SMS-alternative verification include Infobip, IPification, Prove, Sinch, Telesign, Twilio and Vonage (listed alphabetically). We make no claims about them here and have not compared any of them with Glide Identity. On July 8, 2026, Aduna, a network-API joint venture, announced number verification with AT&T, T-Mobile and Verizon.^[17] The buyer’s guide will list vendors by approach, alphabetically and without rankings, under our methodology.