Voice over IP turns every phone call into network traffic, which means your voice service inherits both the reach of the internet and the risks of it. This guide looks at VoIP security as a whole system rather than a single protocol: how calls are set up, carried and terminated, where the exposure sits, and the controls that keep a voice estate safe. It complements our PBX guide, which focuses on the phone system itself, and our SIP guide, which focuses on the signalling protocol. It is written for UK organisations, follows the direction set by NCSC and NIST guidance, and does not describe anything that would help an attacker.
What VoIP security actually covers
VoIP security is the practice of protecting voice-over-IP calls and the systems that carry them from interception, fraud, disruption and unauthorised access. In practice it spans four layers: the signalling that sets up and tears down calls, the media that carries the audio, the endpoints that people use, and the network and management around them. A weakness in any one layer can undermine the others.
This is broader than securing a PBX or hardening the SIP protocol alone. A hosted VoIP service with no on-premises PBX still has endpoints, media streams, trunks and administrative access that all need protecting. Treating VoIP as one connected system, rather than a box in a comms cupboard, is the difference between assuming it is safe and knowing it is.
The VoIP attack surface
The reachable parts of a voice service are what an attacker sees first. Mapping them honestly is the foundation of every assessment.
- Signalling services (SIP and its management ports) that establish calls, often reachable from the internet for trunking or remote working.
- Media paths (RTP or SRTP) that carry the audio between endpoints and gateways.
- Endpoints: desk phones, softphones and mobile clients, plus the provisioning services that configure them.
- Trunks and session border controllers that connect the estate to carriers and the public network.
- Administrative interfaces for the platform, which are frequently the highest-value target.
- The surrounding network: how voice is segmented from data, and how remote access to any of the above is controlled.
Protecting signalling with TLS
SIP, the protocol that sets up most VoIP calls, was not secure by default. Sent in the clear it can expose call metadata, credentials and account details, and it can be tampered with in transit. The accepted control is to carry SIP over TLS, sometimes written as SIPS, so signalling is authenticated and encrypted between hops.
Where TLS is used it should follow current recommendations: modern protocol versions, strong cipher suites and validated certificates. The IETF sets out the base SIP behaviour in RFC 3261, the current TLS version in RFC 8446, and current recommendations for the secure use of TLS and DTLS in RFC 9325, which supersedes the earlier RFC 7525. Citing the current guidance matters, because obsolete TLS advice is a common finding in older deployments.
Protecting the audio with SRTP
Securing signalling does not secure the call itself. The audio is carried by the Real-time Transport Protocol, and plain RTP can be captured and replayed by anyone on the media path. The Secure Real-time Transport Protocol, defined in RFC 3711, adds encryption and integrity to the media so a captured stream is not intelligible.
For SRTP to help, the keys must be exchanged safely, which is why media encryption is normally tied to secure signalling or, in browser-based WebRTC, to DTLS-SRTP. A common real-world gap is signalling protected with TLS while the media still falls back to unencrypted RTP. An assessment checks that both are protected, not just one.
Endpoints, softphones and provisioning
Handsets and softphones are easy to overlook and easy to get wrong. Default administrative passwords, outdated firmware, and provisioning that pulls configuration over unencrypted channels are all recurring issues. Provisioning is particularly sensitive, because a configuration file can contain the credentials an endpoint uses to register.
- Change default credentials on every device and disable unused services and web interfaces.
- Keep firmware current, and include endpoints in your patch cycle rather than leaving them to age.
- Provision over encrypted channels and protect the provisioning server as a credential store.
- Treat softphones on laptops and mobiles as part of the estate, subject to the same access controls as any other client.
Hosted versus on-premises responsibilities
Where the platform runs changes who is responsible for what, but it never removes your responsibility entirely. With an on-premises PBX you own the patching, exposure and configuration. With a hosted or UCaaS service the provider secures the platform, but your organisation still owns endpoint security, user access, call-routing permissions and how the service is connected to your network. This shared-responsibility split is where assumptions cause gaps.
Our comparison of cloud and on-premises PBX security goes into the trade-offs in more detail; the key point for VoIP is to be explicit about which controls are yours and to get evidence that they are in place.
Fraud, abuse and availability
Security is not only about confidentiality. A compromised or misconfigured voice service is routinely used for toll fraud, where attackers place expensive calls the business is usually liable for, and it can be knocked offline, taking every inbound and outbound call with it. Dial-plan design, call-routing permissions and monitoring are as much a part of VoIP security as encryption.
Our dedicated explainer on PBX toll fraud covers how it happens and how to reduce the exposure. In an assessment, fraud controls are checked alongside technical exposure, because the financial risk is often the one a business feels first.
Turning assumptions into evidence
Every control above can be present, partial or missing, and the only way to know is to check the live service rather than the documentation. An authorised VoIP security assessment identifies what is reachable, tests the controls that protect signalling, media, endpoints and administration, and confirms which findings are real before reporting them. The output is evidence and a prioritised fix plan, not a list of theoretical risks.
GoldAgent runs this work only against systems you own or are explicitly authorised to test. A one-off VoIP security assessment gives you a point-in-time picture; Assure adds scheduled reassessment, operationally run and human-validated, so your evidence stays current as the estate changes. NCSC PBX best-practice guidance and NIST SP 800-58 are useful reference points for the controls a good assessment covers.
Sources
- NCSC: Private Branch Exchange (PBX) best practice
- NIST SP 800-58: Security Considerations for Voice Over IP Systems
- RFC 3261, SIP: Session Initiation Protocol
- RFC 3711: The Secure Real-time Transport Protocol (SRTP)
- RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
- RFC 9325: Recommendations for Secure Use of TLS and DTLS
Related service
VoIP Security Assessment
An attack-surface review of your VoIP platform, endpoints and remote users.
Related reading
- SRTP and media encryption for VoIP, explained
What SRTP is, why plain RTP media can be intercepted, how media encryption is keyed, and how to verify your VoIP calls are actually protected end to end.
- The complete guide to PBX security
A defensive, UK-focused guide to securing a modern PBX: external exposure, authentication, management interfaces, dial-plan design, patching, encryption, logging and independent assessment against NCSC guidance.
- SIP registration security: preventing rogue endpoints
How SIP registration works, why weak registration authentication lets attackers register rogue endpoints and drive toll fraud, and the controls that stop it.
- SIP security fundamentals: why telephony fraud starts here
What SIP exposure is, why attackers target it, and the controls that reduce the risk: a clear, defensive primer for IT and security teams.
This guide is educational and defensive. Test only systems you own or are explicitly authorised to test. See our responsible-testing policy.