TL;DR
In November 2023, the FCC adopted new rules requiring wireless carriers to authenticate customers before porting a number or swapping a SIM — a direct response to a wave of port-out fraud. Most IT and security leaders read that headline and assumed the problem was solved. It wasn’t. The rule targets wireless carriers specifically; the local number, toll-free number, and SIP trunk “master” number your business actually runs on still move through an older, weaker process — a signed Letter of Authorization matched against the name and address printed on your own invoice. The real opportunity isn’t waiting for regulation to close that gap. It’s treating every number your business depends on as a credential that needs its own lock.
The Status Quo Trap: “The FCC fixed this in 2023”
Ask a CIO or IT director whether their business phone numbers can be hijacked, and the answer — if they’ve seen any headlines on the subject — is usually “the FCC handled that.” It’s a reasonable assumption and the wrong one. The FCC’s Report and Order revises the Commission’s Customer Proprietary Network Information and Local Number Portability rules to require wireless providers to adopt secure methods of authenticating a customer before redirecting a customer’s phone number to a new device or provider. That’s a real, meaningful fix — for consumer wireless accounts.
It’s also why FCC complaint data looked bad enough to force the rule in the first place: complaints to the FCC about the crime have doubled, from 275 complaints in 2020 to 550 reports in 2023. Port-out fraud works the same way regardless of which number gets taken: bad actors impersonate a customer and convince the provider to port the real customer’s telephone number to a new wireless provider and a device that the bad actor controls. The new rules respond directly to that pattern — the notification requirement will provide a uniform safety measure for all port-out requests across the mobile wireless industry, which we anticipate will reduce the instances of port-out fraud.
But the rule is scoped to wireless carriers and the consumer SIM-swap pathway. Your main business DID, your toll-free sales line, and the billing telephone number anchoring your SIP trunk don’t port through that process. They port through a Letter of Authorization — and an LOA is authorized with information that, on most accounts, is sitting on the top of your own invoice.
The Tele Data Guru Framework: The Number Custody Risk Matrix
Not every number your business owns carries the same authentication standard or the same blast radius if it’s stolen. Before assuming you’re covered, score each number type against what actually protects it and what breaks if it’s gone:
| Number Type | Covered by 2023 FCC anti-fraud rule? | What authorizes a port | Business impact if hijacked |
|---|---|---|---|
| Employee mobile / wireless DID | Yes — secure authentication and port-out notification now required | Carrier PIN, account freeze, or lock requested by the subscriber | Intercepted SMS/voice one-time passcodes for banking, cloud admin, and domain registrar logins |
| Main business landline or VoIP DID | No — governed by standard LNP process, not the wireless-focused order | Signed Letter of Authorization matching the name, address, and account number on file | Main line redirected or disconnected; voicemail and call-forwarding reset by the new “owner” |
| Toll-free number | No — moves through a separate RespOrg change, not standard porting | LOA plus a new RespOrg ID submitted to the SMS/800 registry | Inbound sales/support calls silently redirected; customers never know they didn’t reach you |
| SIP trunk master billing number (BTN) | No — same LOA-based wireline process | LOA referencing the Billing Telephone Number anchoring the trunk | Entire number block at risk, not a single line — the account identity behind the trunk shifts |
Most security reviews stop at the first row. The mobile line gets a carrier PIN because someone read about SIM swapping. The other three rows — the ones actually running the business — are usually unprotected because nobody realized they were a separate attack surface with a separate, weaker standard.
The Port-Out Exposure Cost Formula
Port-Out Exposure Cost = (Hours of Number Control Lost × Revenue-at-Risk per Hour) + (Fraudulent Transactions Executed During the Hijack Window) + (Cost to Re-secure Every Account Tied to That Number)
Example: a business loses its main toll-free sales line for 36 hours while the port is reversed — call volume alone represents $4,500/hour in pipeline, so that’s $162,000 in disrupted revenue. During the window, the attacker resets two SaaS admin passwords using voice-call verification routed through the stolen number, enabling $38,000 in fraudulent transfers before the finance team catches it. Add roughly $15,000 in IT, legal, and carrier-dispute labor to regain control and re-secure every account that used that number for recovery or verification. Total exposure: north of $215,000 — for a single number that nobody on the security team realized was a credential. Account takeover losses are already climbing broadly: in 2025, more than 6 million U.S. consumers experienced an ATO attack, an 18% increase from the previous year, with losses associated with account takeover exceeding $15 billion — and business-targeted variants are part of that growth.
Commercial Realities & Vendor Pitfalls
- The LOA process wasn’t built for fraud resistance — it was built for speed. A standard Letter of Authorization is approved based on whether the submitted name, address, and account details match what the losing carrier already has on file — information that commonly appears directly on the account’s own invoice.
- Toll-free numbers don’t “port” the way everyone assumes. Toll-free numbers move through a RespOrg change in the SMS/800 toll-free registry — a separate process with a separate set of players from standard number porting through NPAC. Security teams that lock down DID porting often never touch the RespOrg side.
- Port freezes exist but default to off. The Commission’s rules adopt requirements relating to notification of customers of port-out attempts, and options to lock or freeze their accounts from port-outs — but on the wireless side, these protections are opt-in and must be explicitly requested per account, not automatically applied.
- Carriers aren’t required to make you confirm before the port completes. Notification requirements tell you a port happened — they don’t require your approval first. While recommended by the FCC, carriers are not required to have subscribers verify or acknowledge before further processing the request. By the time the alert lands, the number may already be gone.
- SMS and voice OTP tied to a business line is a single point of failure. Any account — banking, cloud console, domain registrar — that falls back to a call or text sent to the main business number inherits that number’s weaker porting standard as its real security floor, no matter how strong the password is.
Implementation Checklist
- Inventory every number your business depends on as a credential: the main DID, the toll-free line, the SIP trunk billing telephone number, and any mobile line used for account recovery or MFA.
- Request a port freeze, account PIN, or lock on each number individually — wireless, wireline, and toll-free protections are separate requests with separate carriers or RespOrgs.
- Audit which financial, cloud admin, and domain registrar accounts use SMS or voice verification tied to the main business number, and move them to app-based or hardware authentication instead.
- Document who inside your organization — or your managed telecom provider — is authorized to approve a port, and require a callback or secondary verification for any request, inbound or outbound.
- Set up real-time port-out and CPNI change alerts with your carrier, not just post-completion notifications, and route them to someone who can act within the hour.
- Re-verify every lock and alert at each carrier renewal — the same review cadence you’d apply to catching zombie lines or an evergreen contract clause.