VoIP moves telephony onto IP networks, which means voice inherits the security properties of IP: traffic can be intercepted where it is unencrypted, credentials can be stolen and replayed, and internet-facing services are scanned continuously. It also adds a financially motivated attack that most IT systems do not have: a phone account can place calls that cost real money, so compromise converts directly to revenue for the attacker.
Security for a business phone system therefore has three layers: encrypting signaling and media in transit, protecting the credentials that authorize devices and administrators, and limiting what a compromised identity could do. Storage and retention of recordings, voicemail, and call records are the data-at-rest side, covered in Call recordings, transcripts, and AI: where the data goes.
The threat model
- Eavesdropping
- Capturing unencrypted SIP signaling (who called whom, credentials in weak digest exchanges) or unencrypted RTP media (the audio itself) on any network segment the traffic crosses. Trivial on a shared network with plaintext RTP.
- Registration hijacking
- Stealing or brute-forcing SIP credentials, then registering the attacker's device as the victim's extension. Inbound calls divert to the attacker; outbound calls are placed as the victim.
- Toll fraud / IRSF
- International Revenue Share Fraud: pumping traffic from a compromised account to premium-rate or revenue-share destinations the attacker profits from, typically overnight or on weekends. Industry groups estimate losses in the billions annually; a single compromised trunk can generate thousands of dollars of charges in hours.
- Vishing and social engineering
- Using the phone channel itself as the attack: impersonating banks, vendors, or IT to extract credentials or payments, often with spoofed caller ID. The phone system is the medium rather than the target.
- Admin account takeover
- Compromising the management portal rather than a phone. The attacker can then create extensions, change routing, enable forwarding to premium numbers, and read recordings and voicemail at will.
The encryption stack
Encrypted VoIP splits into two planes. Signaling (call setup, registration, credentials) is protected by running SIP over TLS, sometimes written SIPS: the same certificate-based transport security that protects HTTPS, applied to the SIP connection between the endpoint and the provider. Media (the audio) is protected by SRTP, the Secure Real-time Transport Protocol, which encrypts and authenticates the RTP stream with keys exchanged during the TLS-protected setup.
WebRTC endpoints (browser clients and most modern apps) mandate encryption by design: media is always DTLS-SRTP, with keys negotiated peer-to-peer over the signaling channel, and there is no unencrypted mode to misconfigure. Desk phones and SIP trunks are where plaintext SIP and RTP still appear, usually as a default that was never changed.
What the encryption covers is transport to the provider: nobody on the path between the endpoint and the platform can read the signaling or listen to the media. What it does not provide is end-to-end secrecy. The provider terminates the encryption, processes the call in the clear (it must, to route, record, or transcode), and re-encrypts onward legs where possible. A call that reaches the PSTN leaves the encrypted domain entirely: legacy carrier segments have no equivalent of SRTP. VoIP encryption is best understood as securing your side of the call path, not the whole call.
Credential hygiene
- Strong, generated SIP passwords: SIP registration is scanned and brute-forced constantly from the open internet; dictionary passwords on extensions are the single most common entry point for toll fraud.
- Per-device credentials: each phone, app, and trunk should authenticate with its own identity, so one leaked credential is one revocation, not a fleet-wide reset, and logs attribute traffic to a specific device.
- Two-factor authentication on admin portals: the management plane can redirect every call and read every recording; it deserves at least the protection of the email account it is probably linked to.
- Rotation on personnel change: departing staff and terminated contractors should lose portal access and any device credentials they held, the same day.
Fraud controls
Fraud controls assume compromise will eventually happen and bound the damage. They are the difference between an incident report and an invoice.
- Outbound destination permissions: block international and premium-rate destinations by default, enabling only the countries the business actually calls. Most IRSF traffic goes to destinations the victim has never dialed.
- Rate limits: caps on concurrent calls and calls per minute per extension and per account, sized to legitimate usage.
- Spend alerts and caps: notification at unusual spend, and a hard ceiling that stops traffic rather than letting a weekend run to five figures.
- After-hours monitoring: IRSF runs at night and on weekends precisely because nobody is watching; alerting on off-hours international volume catches it early.
- Review of forwarding and routing changes: attacker-added forwards to external numbers are a common monetization path from a hijacked portal. See call forwarding.
Network posture
- Provider side: session border controllers (SBCs) front the provider's network, enforcing TLS, hiding topology, policing registration attempts, and absorbing scanning and DoS traffic before it reaches call processing.
- Customer side: cloud-hosted platforms need no inbound port-forwarding; endpoints make outbound connections. Legacy on-premises PBXs exposed to the internet via forwarded SIP ports are the classic toll-fraud victim and should sit behind a VPN or SBC instead.
- Device firmware: desk phones are small computers with web interfaces and default admin passwords. Keep firmware updated, change default credentials, and keep phone management interfaces off the public internet.
- Wi-Fi and LAN segmentation: voice VLANs or segmented SSIDs keep voice devices away from general-purpose machines that get phished.
Threats and primary controls
| Threat | What it looks like | Primary control |
|---|---|---|
| Eavesdropping | Captured SIP or RTP on a shared or hostile network segment; call audio reconstructed from packet captures | SIP over TLS for signaling, SRTP for media; WebRTC endpoints where possible (encryption is mandatory) |
| Registration hijacking | An extension registers from an unexpected address; inbound calls divert; outbound calls appear the user never placed | Strong per-device credentials, registration anomaly alerts, TLS so credentials never cross the wire in a crackable form |
| Toll fraud / IRSF | Bursts of international or premium-rate calls, typically off-hours, to destinations never previously dialed | Destination permissions (block by default), rate limits, spend caps and alerts, after-hours monitoring |
| Vishing / social engineering | Inbound calls impersonating trusted parties, often with spoofed caller ID, seeking credentials or payments | Staff verification procedures and callback-on-known-number policies; technical controls help less because the system is the medium, not the target |
| Admin account takeover | Routing changes, new extensions, or forwards nobody recognizes; recordings or voicemail accessed | 2FA on portals, least-privilege admin roles, audit logs, prompt deprovisioning |