SIP trunking is supposed to be the practical upgrade path from aging telecom gear to modern VoIP (Voice over Internet Protocol) services. You get elastic capacity, simpler procurement, and features that would take an entire year of project work on legacy systems. The trade-off is that SIP is software plumbing, and software plumbing can be abused. Fraudsters do not need your business plan. They only need a foothold, a misconfiguration, or a permissive routing rule that turns “internet phone service” into “an open line to billable destinations.”
Toll bypass is the classic risk: calls that should never be allowed get routed through your SIP environment, your carrier account gets charged, and you are left playing financial detective after the fact. Preventing that outcome is not a single setting, it is a chain of controls that make fraudulent calls hard to originate, hard to route, and easy to detect early.
What makes SIP trunks a fraud target
SIP trunks connect your communications stack to a service provider over IP. The call setup information is exchanged in clear text unless you deliberately secure it, and the signaling logic tends to be flexible because it needs to support lots of carriers, number formats, and routing scenarios.
From a fraud perspective, SIP gives attackers several levers:
- They can attempt to register as if they were a legitimate endpoint. They can send crafted INVITE requests to trick your system into starting an outbound call. They can exploit weak authentication, permissive access controls, or overly broad dialing plans. They can reuse stolen credentials, including from compromised devices that were once allowed to talk SIP.
I have seen real incidents where the “root cause” was not a dramatic hack, it was a convenience. A broad IP allow list that included a remote vendor network. A dial plan that permitted emergency patterns for testing, then never removed. A phone system that accepted requests from the wrong source interface. Once an attacker finds one reliable path, they automate, and bills ramp quickly.
A quick grounding in the moving parts
Before you harden anything, you want to know where the decisions are made.
A typical SIP trunking environment includes:
- Your SIP edge component, often a session border controller (SBC) or a managed firewall doing SIP-aware filtering. Your PBX or hosted call control system, which uses routing rules to decide where calls go. The SIP trunk credentials and registration behavior that establish trust between you and the provider. Carrier-side controls, which you cannot fully see, but you can align with through correct configuration and good operational data.
Where toll bypass happens is usually at the boundaries between those components. For example, your SBC might allow outbound requests from internal IPs, but your PBX might not enforce destination restrictions properly. Or your carrier might allow certain call types, but your internal dialing rules might not match what the billing account supports. Security requires consistent enforcement across the chain.
Fraud and toll bypass patterns you should expect
Most fraudulent traffic is not sophisticated. It is persistent, automated, and focused on destinations that are expensive or monetize quickly.
In practice, you will encounter patterns like:
- Unauthorized outbound calling from a device that should not be able to place calls. This can look like “normal” call setup but targets high-cost routes. Registration storms or repeated failed REGISTER attempts, which can indicate credential guessing or probing. INVITE requests that show unfamiliar user agents or unusual header structures, especially when they originate from unexpected networks. Calls that appear from your system but do not match any legitimate extension usage pattern (for example, the “from” identity does not correspond to an internal user).
One subtle trap: some attackers do not aim to break your SIP stack. They aim to use your stack’s logic. If your dial plan allows generic outbound routes, they can hide inside “valid-looking” calls while changing the destination number.
Build a threat model that matches your risk
There is a temptation to treat SIP security as a generic “enable TLS” checklist. That helps, but it misses the point. You want a threat model that fits how your calls actually flow.
Start by asking, in plain terms: what is allowed to talk SIP to what, and from where?
For most organizations, the highest risk pathways are:
- From the internet to your SIP edge, if any direct connectivity exists. From remote workers and vendors into the call control plane, if they have VPN access. From internal networks where unknown or unmanaged devices can reach your PBX or SBC. From the PBX to the trunk, where destination routing is decided.
When that last link is weak, toll bypass becomes easy. Attackers only need to get requests accepted somewhere close to the PBX routing engine.
The controls that matter most
SIP security is not one control, it is layered protection. If one control fails, the next control should still stop the money leak or at least slow it down enough for you to respond.
Here are the most effective categories of mitigation I have seen work in the real world:
Strict network access controls at the edge
Only allow SIP traffic from the provider’s known IPs to the trunk interface. Only allow SIP from your internal systems to the PBX side. Any “temporary” exposure tends to become permanent, so treat changes as audited events.Strong authentication and registration enforcement
Require authentication for inbound requests where applicable, and ensure trunk registration is tied to credentials you control. Avoid configurations where the system will accept unauthenticated or weakly verified signaling.TLS for signaling, and sane certificate validation
Encrypt signaling so credentials and identities are not casually exposed. Make sure certificate validation is not disabled “for troubleshooting.” In a couple of environments, I have watched teams toggle verification off and then forget, which undermines the whole purpose of TLS.Destination restrictions and dial plan alignment
Enforce policies on what numbers and number ranges can be dialed over the trunk. The best setup has both: PBX-level dialing rules and SBC or routing-layer checks. Relying on only one layer is where bypasses slip through.Monitoring that spots fraud patterns early
You need alerts on call spikes, unusual destination ranges, and traffic from unexpected sources. If you only look at bills at month end, you are buying the attacker’s success in delayed form.Those five categories cover the practical core. You can implement them with different tooling depending on whether you run a traditional SBC, a cloud SBC, or provider-managed security.
Secure signaling: TLS and what “secure enough” means
Using TLS for SIP signaling matters because it prevents casual interception and reduces the ability to tamper with signaling in transit. But TLS does not automatically secure everything.
A common real-world misstep is making TLS “encrypt only” while leaving acceptance rules too permissive. An attacker might not read traffic, but if they can still inject signaling that passes your acceptance checks, they can still cause bad calls.
Make sure these are aligned:
- Your trunk should only accept SIP from the provider over the expected transport (often TLS on TCP 5061, though exact ports vary). Your SBC should not expose a “trust anything” mode. If the system has different security zones, keep the trunk zone separate from any “internal” zone. Certificate validation should be consistent. If you pin certificates or validate subject names, do it carefully so renewals do not become an outage event. A break in TLS validation can cause failovers that quietly change routing behavior.
If your provider supports mutual TLS, that can add another layer of trust. If it is not available, you should lean harder on IP allow lists and authentication policies.
The dial plan is your money firewall
People tend to focus on authentication and encryption, then forget about destination logic. Toll bypass usually wins because the destination is accepted, even when the source is not legitimate.
A dial plan should do two jobs at once:
- Convert dialed numbers into the canonical formats your trunk expects, with validation rules. Enforce what destinations are permitted, given your business contract and risk tolerance.
In the safest setups, outbound routing checks the destination number ranges at the point where you actually place the call. That can be at the SBC layer, at the PBX routing layer, or both. The key is that a single misrouted request does not automatically translate into a billable outbound call.
Two practical details that prevent headaches:
- Normalize numbers before applying restrictions. If your system treats “011” prefix dialing inconsistently, attackers can sometimes find a route that slips through your rule matching. Treat emergency and test routes as controlled exceptions. If you ever added “temporary” routes for lab testing, remove them or enforce stronger conditions, like only from specific test extensions and networks.
Rate limiting and call admission control
Fraud attacks often rely on volume. Even if each call is only slightly off pattern, mass calls create a paper trail that you might catch early if you have admission control.
Rate limiting can be applied at multiple places: edge, SBC, or PBX. The goal is not to block legitimate spikes like an executive conference or a contact center campaign, it is to constrain behavior that does not match your patterns.
A good approach is to base thresholds on internal usage. For example, compare trunk-level outbound VoIP phone comparison attempts against normal baselines by time of day. If you see a sudden shift, you can increase friction: reduce allowed call attempts per source, deny destinations outside allowed ranges, or force additional verification if your platform supports it.
Be careful with blanket throttles. If your business has legitimate high volume, overly aggressive limits can cause call failures and customer complaints. This is where a short incident runbook and quick tuning matter as much as the initial configuration.
Source identity: don’t trust what you don’t verify
SIP signaling includes headers that identify who is calling. Attackers can spoof many of these fields if you accept unauthenticated requests or trust those fields for routing.
Instead of trusting “from” identity blindly, use verified identity anchored in authentication, source IP, and established registration. In other words: a call should only be routable if it maps to an authenticated internal entity or a known endpoint behind a trusted path.
If you have direct inbound SIP endpoints (for example, a vendor or a remote site), scope them tightly. Give them only the access they need. A vendor that requires inbound DID calls should not automatically be allowed to originate outbound calls to arbitrary destinations.
What to monitor so you catch fraud before the bill
Monitoring needs to be fast enough to act, not just accurate enough to investigate.
You want visibility into:
- Call attempt volume by trunk and by source network. Destination number ranges and country codes, especially patterns associated with expensive termination. Registration health and authentication failure rates. SIP signaling anomalies such as unexpected user agents, missing required headers, or traffic from unexpected interfaces.
In one environment I worked with, the earliest signal was not successful fraud calls, it was failed authentication followed by a sudden increase in outbound call attempts targeting a single geographic region. Blocking that region at the routing layer stopped the money leak before it became a monthly invoice issue.
You also need operational ownership. Monitoring is only useful if someone can respond quickly, whether that means tightening allow lists, disabling a trunk route, or escalating to the provider.
A short, practical hardening checklist
Use this as a working draft for what to verify across your environment. It is deliberately compact because teams often get overwhelmed and skip the parts that actually stop toll bypass.
- Confirm your SBC or edge allows inbound SIP only from expected provider IPs, and only on the needed transports and ports. Ensure trunk registration and authentication are required and actively enforced, not optional or “best effort.” Validate that TLS is enabled for SIP signaling and certificate checks are not disabled long term. Review your outbound dial plan rules for destination restrictions, number normalization, and any test or emergency exceptions. Ensure monitoring alerts exist for outbound spikes, unusual destination ranges, and authentication failures, with an agreed response path.
If you can check those items with confidence, you have closed most of the Voice over Internet Protocol common toll bypass doors.
Incident response: what you do in the first hour matters
When fraud hits, you often cannot wait for a full forensic report. You need containment steps that are reversible, controlled, and documented.
A useful philosophy is to separate “stop the bleeding” from “fix the root cause.” Stop the bleeding first, then harden for the next attempt.
Here is a simple triage flow that works well in many environments:
- Identify whether the surge is coming from your internal networks, your remote access path, or directly from the provider trunk interface. Temporarily restrict outbound destinations and tighten routing rules for the trunk route(s) involved, focusing on the suspicious number ranges. Reduce signaling exposure by tightening IP allow lists or disabling nonessential SIP endpoints until you confirm which path is compromised. Correlate authentication failures and registration changes with the time fraud began, so you can find how the attacker got in or how trust was misapplied. Notify your provider quickly if the calls are clearly terminating through the carrier, so they can help trace sessions and confirm billing impact.
The biggest mistake I have seen is rushing to wipe configs without understanding how the calls were being admitted. You want containment measures that stop calls while preserving evidence.
Common edge cases that surprise teams
Even careful teams run into tricky scenarios. These are the edge cases that frequently turn “we enabled TLS and authentication” into “we still got hit.”
NAT and remote access side effects
If you rely on remote VPN or NATed connections to reach SIP systems, source IP allow lists can break. People then widen rules to “make it work.” That widening is often what reopens the toll bypass path. The solution is usually better segmentation: VPN with per-user access controls, or a proxy design that keeps SIP traffic within a controlled trust boundary.
Multiple trunks and inconsistent policy
Organizations sometimes manage dial plan rules per trunk, but the security controls are shared or inconsistent. If one trunk allows a destination range “for a special partner,” an attacker might find that route by selecting DID or extension behavior that maps to that partner’s policy.
“Internal” devices that are not actually trusted
A lab workstation, a mismanaged VoIP adapter, or a vendor gateway might have SIP credentials because it needed features during rollout. Later, nobody remembers those credentials are still valid. Then the attacker only needs one compromised device. Tightening segmentation and credential lifecycle management prevents a lot of silent risk.
Working with your provider: align on what they can enforce
Your provider matters because the trunk is their domain at termination time. You cannot control their entire network, but you can align configuration and processes so they become a strong partner rather than a passive billing endpoint.
Ask for clarity on what they support, but also request specifics you can act on, such as:
- Whether they support IP-based source filtering on the trunk side. How they handle unauthorized SIP traffic and whether they expose those logs to customers. Whether they offer advanced call screening or destination-level controls.
Even without “security features” branded by the vendor, providers often have operational levers like blocking certain routes quickly when fraud is reported. The faster you can provide them evidence and call metadata, the faster they can help.
Credential hygiene: the boring part that prevents real losses
SIP credentials are not glamorous, but they are the kind of weakness that attackers love. If a credential leaks, TLS does not help much. If a username/password pair lives for years, eventually it will be used somewhere it should not.
Practical credential hygiene includes:
- Unique credentials per endpoint where possible, not shared logins. Regular review of who can administer SIP components and where secrets are stored. Immediate rotation when you suspect compromise or when a device is decommissioned. Documented ownership for trunk credentials, so they do not become “nobody’s responsibility” over time.
I have seen organizations lose more money from a stale credential than from a misconfigured dial plan, because credentials make bypasses repeatable.
Why “it hasn’t happened yet” is not a strategy
It is easy to postpone SIP security work because it is rarely visible. You do not see toll bypass until bills arrive or until customers complain about calls you never authorized.
But toll bypass is mechanical once someone finds the path. The longer you leave permissive routing or weak admission controls in place, the more likely it is that the first incident will be the one that finally makes the numbers painful.
A security program for SIP trunking is not about paranoia. It is about reducing the number of ways an attacker can turn your calling platform into their routing machine, then ensuring your monitoring catches anomalies quickly enough that you can stop losses while the activity is still ongoing.
If you want a single mental model, think of SIP trunking security as protecting three things at once: who is allowed to signal, what destinations are allowed, and how fast you can respond when behavior deviates. Get those three right, and fraud attempts can still happen, but they stop being profitable.