Business Phone Number for 2FA: Which Sign-Ins Should Use It?

Executive Summary

Whether a code sent to a business number ever reaches a person depends on three things: how the platform classifies the line, whether the code can arrive by voice as well as text, and who or what answers when it arrives. This report turns those questions into an account-by-account worksheet for small businesses in the United States and Canada. It is platform-policy based, and it names the jurisdiction wherever a rule is national.

The first finding is that no universal rule exists. Microsoft's help page for personal accounts says VoIP numbers cannot be added for sign-in or verification codes ^[1]. Indeed says it no longer allows non-fixed VoIP numbers for account verification, OpenAI's help article says landlines, VoIP and Google Voice numbers are not supported ^[2], and Upwork says it cannot verify VoIP numbers ^[3]. Google's own "cannot be used for verification" page, by contrast, attributes the error to limits on how often a number can be used and tells the user to try a different number ^[4]. The banks and payroll providers reviewed here (RBC, Wells Fargo, Gusto and Paychex) list delivery methods without stating a line-type policy.

The second finding concerns delivery. Google's Business Profile help states that phone menu (IVR) systems will not get the code ^[5], and Twilio's help center says a voice-delivered code needs a live answer and cannot sit behind an extension or go straight to voicemail ^[6]. A number whose job is to present a menu is therefore a poor default recipient for automated verification calls.

The third finding is that the standards direction favors fewer phone dependencies. NIST SP 800-63B-4 (final, 31 July 2025) calls PSTN out-of-band codes "one restricted authenticator" and requires verifiers to make alternatives available ^[7]. It is a U.S. federal digital-identity standard, not a law binding private platforms. Google's 2019 study found an SMS code blocked 100% of automated bots, 96% of bulk phishing and 76% of targeted attacks, against 100%, 99% and 90% for on-device prompts ^[8].

The recommendation is a three-way split: an authenticator app, passkey or security key wherever offered; a carrier-issued mobile held by a named owner and a deputy where a phone is required; and the shared business number only where the platform's page accepts it and the delivery test passes. Table 2 records each choice with its backup.

Introduction and Background

Owners setting up or porting a business number usually enter it as the "verification phone" on a dozen accounts in the first week: email, domain registrar, bank, payroll, payment processor, advertising, marketplaces, hiring platforms and accounting software. The decision looks trivial, but the number serves two jobs at once: a public contact point that callers reach through a menu, and a recovery channel that must reach one accountable person at an unpredictable moment.

This report does not repeat the security argument for removing a business number from text-message sign-in, covered on the publisher's port-out and SIM-swap research page, nor one platform's code flow, covered in the WhatsApp article, nor the general calls and texts checklist. Its job is narrower: a per-account decision built on line type and on how a code physically reaches a person when the number sits behind a menu.

Scope, jurisdiction and evidence rules

Every platform statement here comes from the platform's own help page or documentation, opened on 13 November 2026. Where a page does not mention VoIP or line types, the report says so rather than inferring a policy, and bank or payroll policies are not generalized from one institution to another. NIST, CISA, the FTC and the FCC are U.S. bodies; the Canadian Centre for Cyber Security supplies the Canadian guidance. No CRTC (Canadian Radio-television and Telecommunications Commission) source could be retrieved, so no Canadian porting or SIM-change rule is asserted. NIST's guideline governs U.S. federal digital-identity systems; this report uses it as a signal about direction, never as a legal duty on a private platform.

The three questions

Before a number goes into any account, three questions decide whether it is a good fit:

• Does the platform accept this line type? Look for first-party help text, not a blog's summary.
• Can the code arrive by voice as well as text? A landline cannot natively receive SMS, and some platforms offer only SMS.
• Who physically receives it? A named person's phone, a shared voicemail box and a menu are three different answers.

Line Types and Why Platforms Treat Them Differently

Lookup vendors sell a "line type" check that platforms can run on a number at sign-up, and the categories those lookups return explain most of the rejections owners meet.

The categories in plain language

Twilio's Lookup documentation, one commercial vendor's taxonomy, defines the types most relevant here. A landline generally cannot receive SMS ^[9]. A fixed VoIP (voice over internet protocol) number is a virtual number associated with a physical device ^[9]. A non-fixed VoIP number is a virtual number obtained online without requiring a physical device ^[9]. A toll-free number is one where calls are free for the calling party ^[9]. Mobile numbers, the fifth common type, are the ones that generally can receive SMS.

Bandwidth, a carrier-grade number provider, frames the same split by registration: a non-fixed VoIP number has no registered address ^[10]. It adds that some landlines are text-enabled through hosted messaging ^[10], so "landline" does not always mean "cannot text". The FCC describes interconnected VoIP services as those that let users generally make and receive calls on the regular telephone network ^[11], so a VoIP line can place ordinary calls and still be classified differently from a mobile.

Table 1 below summarizes the categories. The treatment column is deliberately labeled "varies; check help page", because platforms set their own policies.

Table 1 is a map of vocabulary, not a verdict. Each "treatment" cell cites the platform that wrote the statement and does not generalize beyond it: a line type is an input to a platform's policy, and the same number can be accepted on one site and rejected on the next.

Why one site rejects what another accepts

Platforms can look a number up. Twilio's documentation says a customer can filter out landline numbers before sending SMS messages ^[9], and Telnyx describes using lookups to flag number types such as VoIP and non-fixed during signup ^[15]. Indeed's published rule acts on the distinction: it accepts mobile, landline or fixed VoIP numbers and no longer allows non-fixed VoIP ^[16].

Rejection is not always about line type. Google's page for the "This phone number cannot be used for verification" error says Google limits how many times a number can be used for verification and suggests a number from a friend, family member or a different carrier ^[4]. It says nothing about VoIP. Many third-party summaries claim Google blocks VoIP numbers; Google's own page as opened does not, and this report does not repeat the claim.

What the owner cannot see

The reader usually cannot see how their number is classified, and classification data differs by vendor and country:

• Bandwidth: line type reflects carrier records, and porting to a new carrier can change it ^[10].
• Sinch: port-corrected data applies to the U.S. and Canada only ^[17], and its optional VoIP signal sorts each carrier into one of four likelihood categories ^[17].
• Plivo: VoIP detection is not supported outside the U.S. ^[18].

Two consequences follow. A reader told "VoIP" should ask the provider whether that means fixed or non-fixed, and Indeed's own advice for a rejected valid number is to contact the carrier to confirm the line type is configured correctly ^[16]. And a number can change category after a port, so a verification that worked before deserves re-testing. This report states no provider's classification; the answer is "ask your provider".

NIST's position is worth separating from platform practice. The change log of SP 800-63B-4 says the revision removes the prohibition on the use of VoIP phone numbers for out-of-band authentication ^[7]. The standard therefore does not require platforms to reject VoIP numbers; any rejection is a platform's own risk decision.

How a Code Actually Reaches a Person

Accepting a line type is only the first gate. The second is delivery: a six-digit code must land in front of a human who can type it within a short window. For a number that sits behind a phone menu, that is where most failures are likely to occur.

SMS, voice and the menu trap

Most platforms offer text first and voice second. Google says codes can be sent in a text message or a voice call ^[19], Twilio calls voice its primary backup to SMS ^[20], and Square, Intuit and Paychex list voice or automated-call delivery in their own help pages ^{[21] [22] [12]}. Speed is not guaranteed: Facebook's help notes that text codes can be delayed by the mobile carrier ^[23].

The menu trap is an automated voice call meeting a number configured to answer with a menu. Three first-party statements support the concern:

• Google Business Profile: the help page says that Interactive Voice Response (IVR) systems will not get the code ^[5].
• Twilio help center: a voice-delivered code requires the user to answer a live phone call, and the number cannot be behind an extension or go straight to voicemail ^[6].
• Twilio authentication channels: the Verify API challenges the answerer with a random keypad digit before reading the token ^[20], a design intended to confirm that a person rather than a machine is on the line.

Two further statements show the voicemail variant. Google's troubleshooting page says that a voice call carrying a verification code goes to voicemail if the user cannot answer or lacks an adequate connection ^[24]. WhatsApp's help says that, for the phone call option with voicemail enabled, its automated system will leave the code as a voicemail ^[25], and that landline extension numbers cannot be used to complete registration ^[26].

These sources do not describe every platform, but they show menus, extensions and voicemail are recognized failure points for at least three large ones, so testing before enrolment is prudent. A shared voicemail box is the sharper risk: a code left there is readable by everyone with access and by no one in particular.

The six-step code delivery test

This practical procedure, not documented behavior of any platform, answers what a help page cannot: what will happen on this specific number.

1. Text test. From a second phone, send a text to the business number and confirm who, if anyone, receives it. A number that cannot receive text cannot use SMS delivery.
2. Voice test. Call the number from a second phone and note exactly what answers: a menu, a greeting, a person, or voicemail.
3. Withheld caller ID test. Call again from a withheld number. Automated verification calls often arrive without a recognizable caller ID, and some menus or call filters treat such calls differently.
4. Menu-active test. During business hours, with the menu live, repeat the call and wait through the greeting without pressing anything. An automated caller cannot choose option 2.
5. After-hours test. Repeat after the closed greeting starts. Many menus play a closed message and offer voicemail, which means no human receives the call.
6. Owner's phone off test. Switch off the phone that would ring and repeat. If the call falls to a shared voicemail, record who can hear it.

If steps 2 to 6 do not end in a named person's live answer, the number should not receive voice codes for any account. If step 1 fails, mark it "no SMS".

An honest note on routing-first numbers

A number built to route inbound calls to team mobiles through a menu is optimized for callers, not automated systems. The publisher sells one such product, a flat-rate number with a multi-option auto attendant that rings each option's team phones, as described on its own site in November 2026; this is the publisher's self-description, not independent evidence. On that site, after-hours calls are not forwarded to mobiles; callers hear a closed message and can leave voicemail. Whether a platform accepts such a number, and whether a code call survives the menu, must be tested, not assumed. The product page does not state how its numbers are classified, so the answer is to ask the provider. For many accounts, a number of this kind is the wrong verification phone.

The Per-Account Worksheet

Table 2 below is the fillable worksheet. The first four columns are seeded from first-party help pages opened on 13 November 2026. The last column is left blank for the reader: method chosen, named owner, and backup. Cells marked "ask/verify" mean no first-party page stating the policy was opened, so no policy is claimed.

Table 2 shows a pattern: platforms that state a line-type rule are in the minority, while nearly every page lists at least one non-phone alternative, so the suggested defaults lean toward alternatives. Rows marked "ask/verify" are open tasks: ask the platform which number types it accepts before enrolling the shared business number.

What to Put Instead of the Business Number

The decision for each account is one of three options: the business number, a carrier-issued mobile held by a named person, or no phone at all. This section walks through each, with the standards signal behind the third.

Option A: the business number

The shared number is a sensible recipient only when all of these hold:

• Accepted type: the platform's page accepts the line type.
• Live human: the delivery test ends in a person, not a menu or voicemail.
• No better option: the platform offers nothing stronger.
• Accountable owner: a named person is responsible for what arrives.

A shared voicemail fails the last condition. NIST's authenticator guidance expects users to maintain their own unique authenticators ^[7] while acknowledging, with a family phone as the example, that sharing happens in practice ^[7]. The Canadian Centre for Cyber Security advises minimizing or eliminating shared accounts ^[46] and lists changing shared or group authenticators when members leave among the practices it describes ^[47].

Option B: a carrier-issued mobile held by a named person

Where a platform insists on a phone, a mobile held by a named owner solves delivery and accountability together. Google's recovery guidance reads this way: a mobile phone that gets text messages and belongs only to the user ^[27]. Apple suggests a trusted number not associated with the iPhone as an additional one ^[48]. A deputy's mobile as a second number covers one person's absence, and the Canadian Centre advises a backup factor identical in strength to the primary ^[49].

Option C: no phone at all

Authenticator apps, passkeys and security keys remove the number from the equation. The FIDO Alliance describes passkeys as phishing-resistant and designed with no shared secrets ^[50], and CISA states that the only widely available phishing-resistant authentication is FIDO/WebAuthn ^[51]. Google's passkey help says a passkey bypasses the second authentication step ^[28]. CISA tells businesses to aim for a phishing-resistant method ^[52], the FTC says to require multi-factor authentication for all employees, contractors and others who access the network ^[53], and the Canadian Centre strongly recommends FIDO-based solutions for online accounts ^[54]. The UK's National Cyber Security Centre adds that any type of two-step verification is better than none ^[55].

Whichever method is chosen, keep a backup. Google's backup codes work once each ^[29]; Bitwarden advises saving the recovery code immediately after enabling a two-step method ^[56]; Yubico says the most secure plan is two security keys per user ^[57].

Standards signal, not a legal duty

NIST classifies the use of the public switched telephone network (PSTN) for out-of-band authentication as the single restricted authenticator at publication ^[7]. For restricted authenticators, the standard requires the credential service provider to offer subscribers at least one alternative authenticator that is not restricted ^[7], and Sec. 3.1.3.3 says verifiers should consider risk indicators such as device swap, SIM change and number porting before using the PSTN to deliver a secret ^[7]. The final publication is dated 31 July 2025 ^[58]. For a small business, the useful reading is that the authors expect phone codes to be one option among several.

Table 3 below compares the three options against the criteria that matter for the decision, including the category of product the publisher offers.

Table 3 makes a plain point: a number optimized for routing inbound calls to a team fits the outward-facing job and fits the credential-recovery job poorly. That is a design observation, not a defect, and no verification behavior of the publisher's product is asserted here.

Recovery, Ported Numbers and Departing Staff

Recovery is where a phone-based choice is tested. When the number is lost, ported or left behind by an employee, each platform's path differs in speed and effort.

When the number is lost or changed

Documented paths vary widely:

• Google: backup codes are for when a user loses a phone or changes a number ^[29].
• Microsoft: after security information is replaced, the user must wait 30 days before signing in ^[1].
• Apple: recovery might take several days or longer ^[59].
• Stripe: the easiest route is a backup code ^[60]; without one, an owner files a request and the decision may take up to a couple of business days ^[61], with an approval link valid for 48 hours ^[61].
• Gusto: the old phone is not needed ^[36].
• Intuit: turning off two-step verification without the old number requires government identification or a notarized document ^[22].
• PayPal: after a number change, codes still go to the old number until it is updated ^[62].

For a Google Workspace super administrator, a locked-out account may need another super admin or Google Support to reset the password ^[63], and Google advises that admins enroll more than one security key ^[64]. The Canadian Centre says an organization needs a clear recovery plan for lost or compromised factors ^[54].

When the number is ported

A number port changes who controls the line, and it can change how the line is classified ^[10]. Re-verify every account first: confirm that each worksheet row still passes its delivery test on the new arrangement before the old service ends. The publisher's guidance on the paperwork is in its letter of authorization article. In the United States, the FCC adopted wireless-carrier rules on SIM changes and port-outs that include an account lock option ^[65]. The Federal Register notice gives an effective date of January 8, 2024, except for revisions with information-collection requirements ^[65], and an FCC bureau order says compliance is not required until the Office of Management and Budget completes its review ^[66]. This report did not locate the later notice announcing a compliance date, so the current status should be confirmed with the carrier. Do not assume the account-lock option is available on any given line until the carrier confirms it. The FCC's consumer page notes that banks, businesses and payment services often use texts to verify identity ^[67].

When a person leaves

If the verification phone is a person's mobile, their departure is a recovery event: update each account before their access ends, using the worksheet's owner and deputy columns. The call routing permissions article covers who can see and change a number's routing, which belongs on the offboarding list. The FTC advises, for a hacked email account, making sure the email address and phone number listed are correct ^[68]; the same check belongs in every handover.

Data Analysis and Evidence

The quantitative evidence on phone-based verification comes from four originators: Google, Microsoft, the FIDO Alliance and NIST, plus timing figures in platform help pages. No independent benchmark compares business numbers against personal mobiles for code delivery, and none was found.

Effectiveness figures

Google's May 2019 study, conducted with New York University and the University of California, San Diego, reported that an SMS code to a recovery phone blocked 100% of automated bots, 96% of bulk phishing attacks and 76% of targeted attacks ^[8]. On-device prompts blocked 100%, 99% and 90% respectively ^[8], and users who relied exclusively on security keys had zero targeted-phishing victims in the study ^[8]. The same experiment reported that 38% of users did not have access to their phone when challenged ^[8], a figure that bears directly on lockout risk for any phone-dependent method.

Microsoft's own pages differ: a 2019 security blog says multi-factor authentication can block over 99.9 percent of account compromise attacks ^[69], while a Microsoft Learn page says more than 99.2% ^[70]. A 2023 Microsoft Research paper reports a 99.22% risk reduction across the entire population ^[71] and concludes that dedicated authenticator applications outperform SMS-based authentication ^[71]. The 99.2% figure appears to derive from that research and the 99.9% figure from the older blog, so the two look like different measurements rather than one contradicted claim; the sources do not reconcile them explicitly.

FIDO Alliance's 2025 consumer survey found that 69% of consumers reported enabling passkeys on at least one account ^[72], in a sample of 1,389 adults across several countries ^[72]. It is an industry-association survey, so it indicates adoption, not security effect.

Timing figures worth planning around

• Code validity: NIST says issued recovery codes sent by text or voice are valid for 10 minutes ^[7].
• Retry intervals: Indeed advises retrying after ten minutes, then after 24 hours ^[16].
• New number trust: Google says a newly added 2-Step Verification phone can take up to 7 days to be trusted ^[19].
• Recovery waits: Microsoft cites 30 days; Stripe, a couple of business days ^[61].
• Backup code counts: Google issues sets of 10 ^[29]; Facebook offers 10 recovery login codes ^[42].

Reading the evidence

A phone-delivered code beats no second step; CISA says any MFA is better than none ^[52], yet it also describes text or email codes as the weakest protection among the methods it ranks ^[52]. The Canadian Centre advises SMS codes only for low-risk logins ^[49], and Google and the FTC each describe text-based verification as exposed to phone-number-based attacks ^{[19] [73]}. The numbers support a ranking, not a ban: phone codes suit low-stakes accounts or cases with no alternative, and are weaker than the alternatives for payment, domain and email accounts.

Case Studies and Real-World Examples

(Hypothetical Example) An eight-person electrical contractor

A contractor with eight employees ports its main line to a number with a three-option menu. The owner, Dana, plans to use that number as the verification phone for everything. The worksheet changes the plan.

Dana runs the delivery test. Step 1 fails because the number handles calls only. The voice test reaches a greeting and a menu, and the after-hours test ends in a closed message and a voicemail that two office staff can read. Three of the six tests end in a menu, closed message or voicemail rather than a live person.

The worksheet is then filled out account by account:

• Email and domain registrar: passkeys on two security keys, one held by Dana and one by the office manager, plus offline backup codes. No phone.
• Bank and payroll: Dana's carrier mobile as the verification phone, the office manager's mobile as the deputy number, after asking each institution which line types it accepts.
• Payment processor and accounting: authenticator app, with backup codes printed and stored in the office safe.
• Google Business Profile: verification attempted from a device and number a person answers, because Google says IVR systems will not get the code ^[5].
• Hiring platform: Dana's carrier mobile, since the platform's help says non-fixed VoIP numbers are not allowed.

The business number stays public, keeps its menu and appears in no recovery field. The example is illustrative only and describes no real company.

Implications and Future Directions

Three trends are visible in the first-party sources opened for this report, none of which can be called settled.

First, platforms are moving off SMS. Microsoft's page says it will start phasing out SMS as a method of authentication and account recovery for personal accounts ^[1], and Shopify says SMS can no longer be set up as a new two-step method ^[45]. If that direction continues, a business number's role in verification will shrink, and the worksheet's phone columns will become the exception rather than the rule.

Second, standards bodies treat PSTN delivery as restricted and exclude out-of-band codes from phishing resistance: NIST says out-of-band authentication is not phishing-resistant ^[7]. It also encourages at least two separate means of authentication ^[7] and treats changing a pre-registered telephone number as binding a new authenticator ^[7], so a phone-number change is a security event in its own right.

Third, recovery is moving toward offline artefacts. NIST describes saved recovery codes as intended to be maintained offline ^[7], Shopify's codes work when other methods are unavailable ^[74], and Etsy points to backup codes when a number is not accessible ^[75].

Two uncertainties remain. Most cited pages carry no revision date, so each Table 2 row should be re-read before enrolment. And no Canadian regulatory source was reviewed, so Canadian owners should confirm carrier-side protections with their carrier.

Frequently Asked Questions (FAQs)

Can a business use a VoIP number for two-factor authentication?

It depends on the platform and the VoIP type. Microsoft's help page on Microsoft account verification ^[1], OpenAI and Upwork say VoIP numbers are not accepted ^{[2] [3]}; Indeed rejects non-fixed VoIP only; Google's verification-error page does not mention VoIP ^[4]. Check each page and ask the provider which type the number is.

Which accounts should use a business phone number for 2FA?

Few. The worksheet defaults to an authenticator app, passkey or key for email, domain, payments, advertising and accounting, and a named person's carrier mobile where a phone is required. The business number fits only where the help page accepts the line type and the delivery test ends in a live person.

What is the difference between a VoIP and a mobile number for SMS verification?

A mobile number is carrier-issued and generally receives SMS. Fixed VoIP is tied to a physical device; non-fixed VoIP is obtained online without one. Some platforms accept only mobile numbers.

Why do some sites reject VoIP numbers?

Published reasons are thin. Lookup vendors describe screening by number type at signup ^[15], and Indeed states its rule without a reason. Its advice to ask the carrier about line type ^[16] suggests classification can also be the issue.

Should a business owner's account recovery phone be the business number?

Generally no. Google recommends a mobile that belongs only to the user ^[27], and Facebook says the two-factor number cannot also reset the password ^[41].

Can a business phone number receive SMS verification codes?

Only if it supports text. Landlines generally cannot receive SMS, and Twilio Verify returns an error when SMS goes to a number that does not support it ^[76]. Ask the provider and run step 1 of the delivery test.

Is SMS or an authenticator app better for business accounts?

An authenticator app, in the sources reviewed: Microsoft Research found such apps outperform SMS ^[71], Google rates its Authenticator app more secure than SMS ^[39], and CISA ranks text or email codes weakest ^[52].

What are the risks of a shared business number for two-factor authentication?

The code goes to whoever answers or reads the voicemail, not one accountable person. NIST expects users to maintain their own authenticators ^[7], and Canadian guidance advises minimizing shared accounts ^[46].

What happens if a business loses access to its 2FA phone number?

Use a backup code if one was saved ^[29]. Without one, platforms run recovery processes with waits, such as 30 days at Microsoft or a couple of business days at Stripe ^[61].

Conclusion

A business phone number is a good public contact point and, in most cases, a mediocre verification phone. The evidence assembled here points to a simple division of labor. Platforms differ on line types, so a rule must come from each platform's own help page, not from a rule of thumb. Delivery differs from acceptance, so the number must pass a delivery test that includes its menu, its voicemail and its after-hours behavior. Accountability differs from convenience, so a named person with a deputy should receive any phone-based code.

The worksheet in Table 2 applies this: fill each row from the platform's page, run the six-step test, choose among the business number, a named mobile and no phone, and record the owner and backup. Rows without a first-party statement stay "ask/verify". Authenticator apps, passkeys and security keys are the default for the accounts that matter most, in line with NIST, CISA and the Canadian Centre for Cyber Security, none of which imposes a legal duty on a private business.

Before the next port or the next departure, re-verify every account, store backup codes offline and keep a non-phone recovery email. Where a platform insists on a phone, the owner's carrier mobile is the safer recipient.