VoIP security refers to the practices, configurations, and controls that protect voice-over-IP communications infrastructure from unauthorized access, eavesdropping, toll fraud, service disruption, and caller ID manipulation. Unlike traditional phone systems where traffic traveled over closed copper circuits, VoIP runs over IP networks — which means it shares attack surface with every other networked application and requires deliberate security architecture rather than inheriting circuit-switched isolation.
VoIP security matters more than most organizations realize at deployment time. The attack surface is broader than traditional telephony, the threat types are different, and the consequences — fraudulent call charges, eavesdropped conversations, disrupted operations — range from expensive to severe. This guide covers the threat landscape, how attacks work, the controls that mitigate them, and how to evaluate a VoIP provider's security posture.
Why VoIP has a different attack surface than traditional telephony
Traditional PSTN telephone infrastructure ran over dedicated, physically isolated circuits. Accessing a PSTN call required physical access to the copper infrastructure or the switching equipment. The attack surface was narrow and largely geographic.
VoIP changes this fundamentally. Voice calls become data packets traversing the same IP networks used for web traffic, email, and every other networked application. This creates several exposure classes that traditional telephony simply did not have:
- Internet-exposed SIP endpoints: SIP ports (default UDP 5060, TLS 5061) are frequently left accessible from the internet, enabling automated scanning and credential attacks against any exposed device or PBX.
- Shared network paths: Voice traffic shares network infrastructure with other applications. Compromised network equipment — a misconfigured router, a captured switch — can intercept or manipulate VoIP packets.
- Software attack surface: IP phones, softphones, and VoIP platforms are software. They inherit the vulnerability classes of any networked software: unpatched firmware, weak credentials, injection vulnerabilities.
- Signaling and media separation: SIP signaling (call setup) and RTP media (the actual audio) travel separately, often on different paths. Both need separate protection. Securing signaling but leaving media unencrypted means call audio can be captured even when the signaling channel is protected.
The table below summarizes how VoIP's exposure differs from traditional telephony at each layer:
| Layer | Traditional telephony | VoIP |
|---|---|---|
| Physical access | Required to intercept | Not required — network access sufficient |
| Credential attacks | Not applicable | SIP accounts are credential-based; brute-force and credential stuffing apply |
| Traffic interception | Physical wiretap required | Packet capture on shared network path |
| Service disruption | Requires physical infrastructure damage | Network-based flood attacks can disrupt service |
| Caller ID | SS7 spoofing requires carrier-level access | SIP From header easily forged without authentication |
| Fraud | Requires physical PBX access | Remote exploitation of internet-accessible SIP accounts |
Primary VoIP threat categories
Toll fraud and unauthorized calling
Toll fraud is the most financially damaging VoIP threat category. Attackers exploit weakly secured SIP accounts or exposed PBX systems to place unauthorized international or premium-rate calls, generating charges that the account holder is liable for before the fraud is detected. A weekend attack on an unprotected system can produce charges in the thousands before anyone notices on Monday morning.
The most prevalent form is IRSF (International Revenue Share Fraud): attackers route traffic to premium-rate numbers they control in high-cost destinations, collecting the interconnect revenue while the compromised account holder faces the bill. Automated SIP scanners continuously probe internet-accessible SIP ports for weak or default credentials. A SIP account with "admin/admin" or a short numeric password is a high-risk exposure: automated SIP scanners run continuously on internet-accessible ports, and weak credentials are a well-documented attack vector.
For the full breakdown of fraud mechanics and prevention controls — including SIP port scanning, voicemail exploitation, call forwarding manipulation, cost limits, and incident response — see the dedicated VoIP toll fraud prevention guide.
Eavesdropping and media interception
VoIP calls travel as RTP (Real-time Transport Protocol) packets. Without media encryption, any attacker positioned on the network path between two endpoints can capture those packets and reconstruct the audio conversation. In practice, this means a compromised network device, a misconfigured Wi-Fi network, or an attacker on the same network segment can silently record calls.
The attack does not require compromising either endpoint — it only requires visibility of the RTP stream. This is a fundamentally different threat model from traditional wiretapping, which required physical access to the circuit. SRTP (Secure Real-time Transport Protocol) encrypts the media payload and prevents reconstructing audio even from captured packets. TLS (Transport Layer Security) encrypts the SIP signaling channel. Both are needed: encrypting signaling but leaving media unencrypted allows call audio to be captured even when the call setup is protected.
SIP scanning and credential attacks
SIP-aware scanners — tools that probe SIP ports and attempt authentication against discovered accounts — are widely available and actively used. Any internet-accessible SIP endpoint faces continuous automated probing. The attack pattern is simple: scan a range of IP addresses on UDP/5060, enumerate SIP accounts through REGISTER/INVITE attempts, then run credential brute-force against discovered accounts.
Default credentials on SIP phones and VoIP hardware are a primary entry point. Many IP phones ship with default admin passwords that organizations never change during deployment. Compromising a phone gives an attacker SIP account credentials they can then use to place unauthorized calls or access voicemail.
Denial-of-service and service disruption
VoIP services are disrupted by network-level flood attacks in ways traditional telephony is not. An attacker who floods a SIP server with malformed INVITE packets, REGISTER storms, or raw UDP traffic can exhaust processing capacity and prevent legitimate calls from being placed or received. Unlike a data server where disruption is inconvenient, a disrupted VoIP system means an organization cannot communicate — which in contact center environments directly translates to lost revenue.
Session Border Controllers (SBCs) are the primary mitigation layer for SIP-based flood attacks: they act as the demarcation point between the internet and the VoIP infrastructure, enforcing rate limits, filtering malformed SIP messages, and blocking addresses exhibiting attack patterns. Organizations running on-premises VoIP infrastructure without an SBC at the perimeter are exposed directly.
Caller ID spoofing
In SIP, the From header that carries caller ID information is user-controlled and not authenticated by default. Any party that can inject SIP traffic into the call path can set the From header to any value. This enables impersonation attacks: calls that appear to come from a bank, a government agency, a business contact, or a trusted internal number when they do not.
STIR/SHAKEN (Secure Telephone Identity Revisited / Signature-based Handling of Asserted information using toKENs) is the standards-based framework developed to address this. Originating carriers cryptographically attest to the legitimacy of the calling number, and the attestation travels with the call as a signed token. Terminating carriers can verify the signature and apply the attestation level — A (full attestation), B (partial), or C (gateway) — to inform call handling decisions.
STIR/SHAKEN implementation is now mandatory for US originating carriers by FCC order. However, it addresses spoofing at the carrier signaling layer; calls that never pass through an attesting carrier, or that originate outside the US, may carry no valid attestation. It reduces the scale of spoofing at the network level; it does not eliminate it.
Signaling and media protection controls
The controls that address eavesdropping and interception operate at two layers:
Signaling encryption (TLS): SIP signaling travels over TCP/TLS rather than unencrypted UDP/TCP. TLS protects the call setup metadata — who is calling whom, what call parameters are negotiated — from inspection and tampering on the network path. Standard SIP over UDP exposes this metadata to anyone who can see the traffic.
Media encryption (SRTP): RTP media streams travel encrypted under SRTP. The encryption key is negotiated during the SIP signaling exchange (typically via SDES or DTLS-SRTP). Without SRTP, captured RTP packets can be decoded into audio with freely available tools. With SRTP, captured packets are ciphertext.
The two must be deployed together. TLS without SRTP protects the signaling channel but leaves the audio stream unencrypted. SRTP without TLS protects the audio but leaves the key negotiation visible — an attacker who captures the SIP exchange gets the keys needed to decrypt the SRTP stream. For the detailed breakdown of how these protections work together in a UCaaS deployment, see the UCaaS security and compliance guide.
Access control and authentication
The access control layer protects against unauthorized use of VoIP accounts and administrative functions:
- SIP credential strength: SIP account passwords are the first line of defense against automated scanning attacks. Weak or default passwords are the most common vector for toll fraud and unauthorized calling. Strong, unique credentials per account, rotated periodically, substantially reduce the risk from automated brute-force attacks.
- IP allowlisting: Restricting SIP authentication to known IP address ranges means that even valid credentials are not accepted from unexpected sources. A compromised credential cannot be used from an attacker's infrastructure if the platform only accepts registrations from the allowed range.
- MFA for administrative access: Platform administrative accounts have higher blast radius than individual SIP accounts — compromising admin access means an attacker can reconfigure routing, extract credentials, and manipulate billing. MFA on admin accounts prevents most credential-based admin compromises. For a full treatment of MFA implementation in a UCaaS environment, see UCaaS security and compliance.
- Role-based access controls: Granting users and administrators only the permissions they need — rather than broad admin access to all platform functions — limits the damage a compromised account can do. Over-permissioned accounts are a consistently underaddressed risk in contact center deployments.
Network configuration for VoIP security
Network architecture is as important as application-layer controls:
VoIP network segmentation: Placing VoIP infrastructure on a dedicated VLAN or network segment, isolated from general IT traffic, limits lateral movement. An attacker who compromises a workstation on the general corporate network does not automatically gain access to the VoIP segment. Segment isolation also allows VoIP-specific security policies and monitoring to be applied without affecting other traffic.
SIP ALG (Application Layer Gateway): SIP ALG is a feature present on many consumer and business routers that attempts to rewrite SIP packet headers as traffic passes through NAT. It frequently corrupts SIP messages, causes registration failures, and introduces one-way audio problems. It also interferes with encrypted SIP (TLS) by attempting to inspect traffic it cannot read. SIP ALG should typically be disabled on routers carrying VoIP traffic. The VoIP firewall and NAT configuration guide covers SIP ALG behavior and the correct NAT traversal approach in detail.
Firewall rules for VoIP: VoIP traffic requires specific firewall treatment: SIP signaling on the appropriate ports, RTP media on the dynamic port range the platform uses, and rules that permit traffic from the provider's known IP ranges while blocking unexpected sources. Overly permissive rules — "allow all UDP" — create unnecessary exposure; rules that are too restrictive cause call quality and connectivity problems.
BYOD security boundaries: Organizations that allow personal devices for business VoIP calls introduce device-level risks: unmanaged device vulnerabilities, shared networks, and lack of enterprise endpoint controls. For BYOD security architecture in VoIP deployments, see the BYOD business phone security guide.
Monitoring and detection
Security controls prevent known attack patterns. Monitoring detects what gets through:
CDR anomaly monitoring: Call Detail Records capture the timing, destination, duration, and volume of calls. Anomalies — calls to unusual international destinations, high-volume calling outside business hours, spikes in failed authentication attempts — are the earliest visible signals of fraud or unauthorized access. A CDR-based monitoring system that alerts on threshold breaches catches toll fraud within the attack window rather than at the end of a billing cycle. For the specific CDR-based detection patterns for toll fraud, see the toll fraud prevention guide.
SIP authentication failure alerting: A burst of SIP REGISTER failures from an unfamiliar source address is the signature pattern of an automated credential attack. An alerting system that flags this pattern in near-real-time allows a response (blocking the source, increasing credential strength) before a successful login occurs.
International call controls: Pre-emptive restrictions on international calling — blocking destinations you never call, requiring approval for high-cost destinations, or setting per-account spending limits — constrain the damage from a successful account compromise. A compromised account that can only call domestic numbers produces far less fraud exposure than one with unrestricted international access.
VoIP security checklist
Core controls to verify in any VoIP deployment
- SIP signaling encrypted over TLS (not plain UDP/5060)
- Media encrypted via SRTP
- Strong, unique SIP credentials — no defaults, no short numeric passwords
- IP allowlisting on SIP registrations where feasible
- MFA enabled on all administrative accounts
- RBAC configured — users and admins have only required permissions
- International calling restricted by default; allowed only as needed
- Per-account spending limits or call volume thresholds configured
- SIP ALG disabled on routers and firewalls handling VoIP traffic
- VoIP segment isolated from general IT network (VLAN or equivalent)
- CDR anomaly monitoring or alerting in place
- SIP authentication failure alerting configured
- STIR/SHAKEN verification checked at the carrier level for inbound calls
Evaluating a VoIP provider's security posture
Selecting a VoIP provider means accepting their security architecture as part of your own. Questions to ask before committing:
- Does the platform enforce TLS and SRTP, or are they optional? TLS/SRTP that requires manual configuration or an add-on is frequently left unconfigured. Platform-default encryption is meaningfully different from theoretically-available encryption.
- Is MFA available for administrative accounts? Admin account compromise is high-consequence. MFA availability is a baseline expectation for any modern platform.
- What access controls and RBAC does the platform support? Can you grant a call center supervisor reporting access without also granting the ability to modify routing or extract credentials?
- What fraud monitoring and call controls are included? Does the platform provide CDR anomaly alerting, international call restrictions, or spending limits — and are these available in the standard tier or only in premium plans?
- What is their incident response process? If toll fraud occurs, what is the timeline and process for notification, investigation, and dispute? Understanding this before an incident is better than discovering it during one.
- Do they follow a shared responsibility model? Understand what the provider secures (their infrastructure, their platform) versus what you are responsible for (your credentials, your network, your device configuration). Conflating the two is a common source of unmitigated exposure.
For a full evaluation framework including vendor security questionnaires and compliance framework considerations (SOC 2, HIPAA BAA, GDPR), see the UCaaS security and compliance guide. For SIP trunk and business VoIP security architecture specifically, see the SIP trunking guide and the business VoIP guide.