How to Secure Your Softphone From Cyber Threats

The Communications Fraud Control Association put global telecom fraud losses at $41.82 billion in its 2025 Global Fraud Loss Survey. Very little of that came from anyone breaking encryption. It came from stolen credentials, misconfigured dial plans, and phone systems that were left reachable from the open internet with a password somebody could guess in an afternoon.

That gap is the whole subject of this guide. Softphone security is mostly not a cryptography problem. It is a configuration and ownership problem, and in a white-label deployment the ownership half is where things quietly break.

At iotum we build a white-label softphone that VoIP service providers, ITSPs and MSPs resell under their own brand, so we spend a lot of time in the middle of these conversations. A reseller asks whether the app supports SIP over TLS. It does. Then their end customer asks whether calls are “end to end encrypted,” and the honest answer takes three paragraphs instead of a checkbox. Below is the version of those three paragraphs we wish existed as a page we could send.

What Can Actually Go Wrong: The Softphone Threat Model

A softphone is a SIP user agent running on a general-purpose device. That gives it two attack surfaces a desk phone does not have (the operating system it runs on, and whatever else the user installed) and removes one it did have (a fixed cable to a fixed switch port). Each of the threats below is distinct, with its own control. Treating them as one blob called “VoIP security” is how deployments end up with encryption enabled and a $40,000 weekend call bill anyway.

• Toll fraud. An attacker gets a working SIP registration or trunk credential and places outbound calls, usually to international premium-rate numbers they control. This is the highest-dollar softphone threat by a wide margin and it does not require decrypting anything.
• Eavesdropping on unencrypted media. SIP signalling and RTP media are separate streams. If media is plain RTP, anyone on the path (a shared office network, a compromised router, a hostile hotel Wi-Fi) can capture the packets and reassemble audio with freely available tools. No exploit needed.
• SIP registration hijacking. An attacker registers an extension to their own device, either by stealing the credential or by racing legitimate REGISTER requests. Inbound calls then ring the attacker. This is the quietest failure on the list because nothing breaks; calls just stop arriving.
• Brute force and credential stuffing on port 5060. Automated scanners sweep the internet for anything answering SIP on UDP 5060 and 5061, then grind through extension and password combinations. Extensions are short and predictable, which makes them a poor secret.
• Endpoint compromise. The softphone is only as trustworthy as the laptop or phone it runs on. A device with a stale OS, no screen lock, or a malicious app has already lost the argument, and no amount of transport encryption helps.
• Man in the middle on signalling. Without TLS and proper certificate validation, an attacker who can intercept SIP can rewrite headers, redirect media, downgrade the session, or strip encryption offers before either side notices.

Two things about that list. First, the top item is financial, not confidentiality. Second, only two of the six are fixed by encryption. Any softphone security plan that stops at “we use TLS” has covered about a third of the problem.

Encrypting Signalling: SIP Over TLS, and Where TLS 1.3 Stands

SIP over TLS, sometimes written SIPS, wraps the SIP signalling channel in the same transport security that protects HTTPS. It hides who is calling whom, the extension numbers, the SIP headers, and, importantly, the credentials used to authenticate the registration. It runs on TCP 5061 by default. Plain SIP on 5060 sends all of that in the clear.

Version matters more than vendors usually admit. TLS 1.0 and 1.1 are deprecated and should not be accepted by any SIP endpoint or SBC still in service. TLS 1.2 remains acceptable when it is configured with modern cipher suites and forward secrecy. TLS 1.3 removes the older key exchanges outright, cuts the handshake to one round trip, and encrypts more of the handshake itself, which matters on mobile networks where SIP registrations re-establish constantly. NIST’s federal profile for TLS deployments requires TLS 1.2 with FIPS-based cipher suites and support for TLS 1.3 by January 1, 2024, and that is a reasonable bar to hold a softphone vendor to even when you are not selling to a federal buyer.

Ask a vendor three questions rather than one. Which TLS versions does the client offer and which does it accept? Does the client validate the server certificate chain, or will it accept a self-signed certificate if a user taps through a warning? And does it fall back to UDP 5060 when the TLS connection fails? That last one is the killer. A client that silently downgrades to plain SIP on a flaky network has given you softphone encryption that works exactly when you did not need it.

Certificate pinning goes a step further by binding the client to a specific certificate or issuing CA, so a rogue or mis-issued certificate is rejected even if it chains to a trusted root. It is worth having on mobile clients, and it is worth understanding the operational cost before you turn it on, because a pinned client stops working the day you rotate to a certificate it does not expect. Mutual TLS, where the client also presents a certificate, is the stronger version of the same idea and is more common on trunk-to-trunk and service-to-service links than on end-user seats.

Encrypting Media: SRTP, ZRTP, and What “End to End” Honestly Means

Signalling encryption protects the conversation about the call. Media encryption protects the call. They are separate, they are negotiated separately, and one can be on while the other is off. That single fact explains most of the confusion in softphone security conversations.

• SRTP. The Secure Real-time Transport Protocol encrypts and authenticates the audio and video packets themselves, using AES for confidentiality. In a SIP deployment the keys are normally exchanged in the SDP body of the signalling messages, which is why SRTP without SIP over TLS is close to useless: the keys travel in the clear alongside the encrypted media. SRTP with TLS-protected signalling is the standard, workable answer, and it is what the iotum Communicator uses.
• ZRTP. ZRTP negotiates keys in the media path itself using a Diffie-Hellman exchange, so the signalling servers never see them. It adds a Short Authentication String that the two humans read aloud to each other to detect a man in the middle. It gives you genuine end-to-end confidentiality between two endpoints, and it is rare in business softphones because it breaks the things businesses need: server-side recording, compliance archiving, transcoding, and conference mixing.
• DTLS-SRTP. The WebRTC world uses DTLS to negotiate SRTP keys directly between endpoints. If your softphone has a browser or web client, this is what is happening under it.

Now the honest part, and it is the single most misunderstood point in softphone encryption. When a business softphone is described as end to end encrypted, what is almost always true is hop-by-hop encryption: your device to the platform edge is encrypted, the platform to the PBX is encrypted, the PBX to the carrier is encrypted, and the final leg onto the PSTN is not encrypted at all because the public phone network has no mechanism for it. Media is decrypted at each hop that has to do something with it, and any call that touches a regular phone number leaves the encrypted world at the gateway.

That is not a scandal. It is how SIP telephony works, and it is what allows recording, voicemail, IVR, and lawful compliance archiving to exist. But if you are a reseller selling into healthcare or legal, say it plainly rather than repeating a marketing phrase your customer will later test. Internal call between two seats on the same platform: encrypted the whole way. Call to an outside mobile number: encrypted until it hits the PSTN gateway. Buyers respect the second answer. They lose trust fast when they discover it themselves, and a reputation for straight answers about softphone encryption is worth more to a reseller than any feature row.

Enterprise Security Features to Require From a Softphone Vendor

When resellers evaluate us against the incumbents in this market, the softphone security section of their requirements document is usually the shortest and the vaguest part. It says “enterprise grade security” and moves on. Here is a version worth actually sending, with the answers you should expect. It doubles as a checklist for choosing a softphone for business generally.

• SIP over TLS 1.2 and 1.3, with no silent downgrade. The client must refuse plain SIP rather than fall back to it, and the behaviour on failure must be documented.
• SRTP on by default, not as an option a technician remembers to tick. Ask what happens when the far end does not offer SRTP: does the call fail, or does it complete unencrypted with no indication to the user?
• Certificate validation and, on mobile, pinning. Including what happens on certificate rotation.
• SSO and MFA on the administration and provisioning portal. The portal that can re-point extensions, change dial permissions, and pull recordings is a higher-value target than any single seat. SAML or OIDC into your existing identity provider matters more than a bespoke second factor.
• Per-seat class of service for international and premium-rate dialing. Default deny, with destinations enabled on request. This one control prevents more losses than everything else on the list combined.
• Rate limiting and anomaly alerting on registration and call attempts. Both at the platform and at your session border controller.
• Encryption posture reporting. You should be able to see, per account, whether TLS and SRTP actually negotiated on live calls, because SIP security you cannot observe is SIP security you cannot prove to an auditor.
• Audit logging with export. Who logged in, from where, what they changed, which recordings they downloaded, retained long enough to satisfy your customers’ auditors.
• Remote wipe or session revocation. When a laptop walks out with an employee, you need to kill the registration and the stored credential from the console, not from the device.
• Encryption at rest for recordings, voicemail, and chat history. Plus a stated retention period you can configure per customer.
• A written incident notification commitment. How fast the platform tells you, in what channel, with what detail, so you can meet the notification window you promised your own customers.

Network-Side Hardening: Proxies, Trunks, and SBCs

Most of what people call softphone security actually lives in the network between the client and the carrier. A softphone connects to a SIP registrar and proxy, which sits in front of a PBX, which connects to one or more SIP trunks. Every one of those hops is a control point, and the ones that matter most are the ones you can reach.

Put a session border controller in front of the PBX. An SBC terminates SIP and media at a controlled edge, normalizes signalling, hides internal topology, enforces transport policy (TLS in, TLS out), and applies rate limits and access control lists. Exposing a PBX directly to the internet on 5060 is the single most common root cause of toll fraud incidents, and an SBC is the standard answer.

Allowlist where you can, rate limit where you cannot. Trunk-facing IP allowlists are straightforward because carrier IPs are static. User-facing allowlists are harder with mobile clients on cellular networks, so lean on rate limiting: cap registration attempts per second per source, cap concurrent channels per extension, and cap simultaneous international calls at the account level.

Authenticate trunks properly. This is the least glamorous line item in VoIP security and one of the highest-yield. Digest authentication plus IP allowlisting, not IP allowlisting alone. IP-only trunk authentication is the configuration that turns a single spoofed source into an open relay.

Watch SIP ALG. The Application Layer Gateway feature on many consumer and small-business routers rewrites SIP headers to help with NAT traversal. It usually helps with nothing and breaks registration, one-way audio, and dropped calls instead. It also cannot inspect SIP inside TLS, so once you encrypt signalling it is doing even less. Turn it off, and use the softphone’s own NAT traversal and keepalive mechanisms. If you are documenting this for a support team, our guide to connecting a softphone to your PBX covers the related connection failures in more detail.

Separate voice traffic where the network allows it. A VLAN for voice, QoS policy for the media ports, and no path from a guest network to the SIP edge. This is basic, and it is skipped constantly in small deployments.

Preventing Toll Fraud: The Controls That Actually Stop It

Toll fraud is the reason softphone security budgets exist at all. It is theft of call capacity. An attacker obtains a valid SIP credential or a route into your trunk, dials premium-rate numbers they own or have a revenue share on, and collects the termination fee while your carrier invoices you for the traffic. It is automated, it runs at night and over long weekends, and the bill arrives before anyone notices the pattern.

Against the $41.82 billion of global telecom fraud losses that the CFCA survey reported for 2025, the awkward truth is that the individual incidents are small and boring. A handful of extensions, a few thousand minutes to a high-cost destination, over a Saturday.

The economics of this land on the reseller specifically. In the model most of our partners run, a PBX provider or MSP licenses numbers to its own business customers and bills them by seats or sessions, which is how our revenue lead described the channel on a partner strategy call in May 2025. When fraudulent minutes are terminated, the carrier bills the reseller for wholesale traffic that no customer will pay for. The end customer is annoyed. The reseller is out real cash. So the controls below belong to you even when the softphone is somebody else’s software.

• Default-deny international dialing per seat. Most seats in most businesses never dial internationally. Enable destinations by exception, and keep premium-rate ranges off entirely unless a customer has a documented reason.
• Set a spend or minute cap at the trunk. Talk to your carrier, because this is one softphone security control the platform cannot set for you. A hard ceiling per account per day converts an unlimited loss into a bounded one, and it is the single most effective control on this list.
• Alert on velocity, not just volume. Twenty simultaneous calls to one country code from an account that averages two is a signal an hour into the incident, not on the invoice three weeks later.
• Kill the default credentials. Weak SIP passwords undo every other softphone security control on the list. Extension number as password, sequential extensions, shared passwords across a customer’s fleet. Automated scanners find these in minutes.
• Turn off unused features. Direct inward system access, unrestricted call forwarding to external numbers, and voicemail that allows outbound dialing from the menu are all classic fraud vectors that nobody in the account uses.
• Rate limit registration attempts. Both to slow brute forcing and to make the attempt visible in your logs.

None of these need cryptography. All of them need somebody to own the configuration, which brings us to the part most vendor pages skip.

Compliance: What HIPAA, SOC 2, GDPR and PCI Ask of a Voice Application

Compliance frameworks are not softphone security controls. They are evidence regimes: they ask what you do, whether you can prove it, and who is contractually on the hook. For a softphone the four that come up are these.

HIPAA. United States healthcare. It requires encryption of protected health information in transit and at rest as an addressable safeguard, access controls with unique user identification, audit controls that record access to systems holding PHI, and a signed Business Associate Agreement with every vendor that touches PHI. Call recordings and voicemail count as PHI when they contain patient information. Note the practical consequence for a reseller: a BAA from your platform covers your relationship with the platform, and you will still need BAAs with your own healthcare customers. We built our HIPAA-compliant video for healthcare around exactly that chain.

SOC 2. Not a law, and not a certification you pass or fail on a softphone security checklist. It is an audit report by an independent CPA firm against the Trust Services Criteria, most often Security, and it describes controls over a period of time. Type I is a point in time, Type II covers a window, usually six or twelve months. Enterprise procurement teams ask for it because it is the cheapest way to outsource a vendor security review. Ask any vendor in your supply chain to confirm their current audit status in writing and to send the report under NDA, and read the exceptions section rather than the cover page.

GDPR. European personal data, and the frame that most often reshapes a softphone deployment outside the United States. Call metadata, recordings, and chat content are personal data. What it asks of a voice application is a lawful basis for processing, a Data Processing Agreement between controller and processor, a stated retention period rather than “forever,” a mechanism for access and erasure requests, and clarity on where data is stored and which transfer mechanism covers any movement out of the EEA. Data residency is a product question, not a legal one, so ask where the media servers and the recording storage physically sit.

PCI DSS. Payment card data spoken over a call, and the one frame where the right softphone security answer is to remove the data rather than protect it. The moment an agent reads back a card number, the call recording is in scope, and so is anything that stores it. The usual answer is not to encrypt harder but to keep card data out of the voice channel entirely: pause and resume recording around payment, or use DTMF masking so the digits never reach the recording or the agent’s screen. If your customers take card payments by phone, ask your softphone platform which of those two it supports before the assessor does.

One pattern worth naming, from the calls we have with healthcare buyers who find us through search: the encryption questions are the opening, not the substance. Our revenue lead made the point on an internal review in March 2026 that healthcare prospects arriving from search convert into meetings reliably, and those meetings then turn into detailed requirement lists that run well past the encryption line. Buyers in regulated verticals have usually assumed transport encryption before they book the call. What they are really testing is whether you can produce audit logs, retention settings, and a signed agreement.

Security Responsibilities in a White-Label Deployment

This is the part no competitor page covers, and it is the part that decides whether softphone security holds up in practice. In a white-label softphone rollout there are three parties: the platform that builds the software, the reseller who brands and sells it, and the end customer who uses it. Controls are split across all three, and every unowned control is a hole.

The split gets sharper in an add-on architecture. The softphone iotum sells to VoIP service providers, ITSPs and MSPs is built to sit on top of an existing PBX rather than replace it. As our revenue lead put it on a product call in April 2026, it is positioned as an alternative at the end-user layer while the reseller keeps their existing PBX on the back end, so they do not have to rip and replace the infrastructure their customers already run on. Security-wise that means the trust boundary sits at the SIP interface: the registrar, the trunks, the dial plan, and the number licensing stay under the reseller’s control, and the client experience, transport policy, and app distribution sit with the platform. Both halves have to be configured, and neither party can see the other’s half.

Control	Platform owns	Reseller or MSP owns
SIP signalling encryption	Ships a TLS 1.2/1.3 client, terminates TLS at its edge, documents downgrade behaviour	Enables TLS transport on the PBX and trunk, disables plain 5060 where the PBX allows it
Media encryption	Negotiates SRTP by default in the client	Confirms the PBX and media gateway do not downgrade to plain RTP
Certificates	Manages certificates for platform hostnames and rotation	Manages certificates for branded hostnames, and app-store identifiers
Extension credentials	Provides the authentication mechanism and password policy controls	Sets password length and rotation, never ships extension-as-password
Admin portal access	Exposes SSO and MFA support	Enables and enforces it, and removes leavers the same day
Class of service and dial permissions	Provides per-seat switches	Sets them, default-deny on international and premium-rate
Trunk spend caps and fraud alerting	Rate limits at the platform edge	Sets carrier-side caps, watches velocity alerts, pays the invoice
Device posture and BYOD	Ships clients that respect OS-level protections	Decides MDM, screen lock, remote wipe policy per customer
Recording storage and retention	Provides encrypted storage and retention settings	Chooses the retention period, controls who can export
White-label configuration fields	Provides the fields and sane defaults	Fills every one of them, on every instance
BAAs and DPAs	Signs with the reseller	Signs with the end customer
Incident notification	Notifies the reseller within a stated window	Notifies end customers within their contractual window

The white-label configuration row deserves a story, because it is the one people underestimate when they audit a softphone deployment. During a routine analytics review of our own white-label partner instances in July 2025, our team found that partner apps whose analytics ID field had been left blank were inheriting the parent template’s tag, so telemetry from branded deployments was reporting into a property those partners did not own. Nothing had been attacked. A default had simply been left in place. A colleague on that call summed up the problem in one line: it kind of violates the whole white-label premise. We tracked it down and cleaned it up, and it permanently changed how we think about provisioning: in a white-label build, an empty configuration field is not empty, it inherits. Push notification certificates, support URLs, analytics IDs, SMTP senders, branding assets, every one of those is a field that has a default if you do not set it.

So the practical rule for securing a softphone deployment is to enumerate every configurable field per instance and confirm a value, rather than confirming that nothing looks wrong on the dashboard.

A Softphone Security Checklist for MSPs Deploying to Client Fleets

Run this per customer, not per platform. It takes about twenty minutes for a fleet you already control.

1. Confirm transport. TLS on for signalling, SRTP on for media, plain 5060 blocked at the edge, downgrade behaviour tested by deliberately failing the TLS connection.
2. Rebuild the credential set. Unique extension passwords of real length, none matching the extension, none shared between customers.
3. Set class of service per seat. International off by default, premium-rate ranges blocked at the trunk, exceptions documented with a requester.
4. Set a carrier-side spend cap. Per account, per day, with an alert threshold below the cap.
5. Enforce SSO and MFA on the admin console. This is the highest-value twenty seconds in the whole softphone security review. Then audit the account list and delete every login that belongs to somebody who left.
6. Fill every white-label configuration field. All of them, on every instance, including the ones that look cosmetic.
7. Set recording retention deliberately. A number in days, agreed with the customer, with encryption at rest and a restricted export permission.
8. Check the endpoints. Minimum OS version, screen lock, MDM enrolment for company devices, remote session revocation tested at least once.
9. Turn on the alerts you will actually read. Registration failures, call velocity by destination, new device registrations for an existing extension.
10. Write down who owns what. One page per customer, using the table above. When an incident happens at 2am, that page is the difference between a fast response and an argument.

If you are building rather than reselling, the same split applies to your own code, and the APIs and SDKs behind it still leave the dial plan, trunk, and credential policy in your hands.

Frequently Asked Questions

Are softphone calls encrypted by default?

Not always, and that is the honest answer. Many softphones support SIP over TLS and SRTP but negotiate them only if the server offers them, and some fall back to unencrypted SIP and plain RTP without telling the user. When you audit softphone encryption, check the client’s actual behaviour on a failed handshake rather than the feature list, because a supported protocol that silently downgrades gives you no protection at all.

What is the difference between SIP TLS and SRTP?

SIP over TLS encrypts the signalling channel: who is calling whom, the extension numbers, the SIP headers, and the credentials. SRTP encrypts the media stream, meaning the actual audio and video packets. They are negotiated separately and you need both, because SRTP keys are usually exchanged inside the SIP signalling, so SRTP without TLS hands the keys to anyone watching the wire.

Is a softphone more or less secure than a desk phone?

It depends on which risk you care about. A softphone inherits every weakness of the device it runs on, which a hardware phone on a dedicated VLAN does not. In exchange it gets modern transport security, central provisioning, remote credential revocation, and patch cycles measured in weeks rather than the years typical of desk-phone firmware. For most fleets the softphone is the safer choice on softphone security grounds, provided the endpoints are managed.

Can a softphone be HIPAA compliant?

A softphone can be used in a HIPAA-compliant way, which is a different sentence. It requires encryption in transit and at rest, unique user identification and access controls, audit logging of access to systems holding PHI, a retention policy for recordings and voicemail, and a signed Business Associate Agreement with every vendor in the chain. Compliance is a property of the deployment and the paperwork, never of the app on its own.

What is toll fraud and how do you prevent it?

Toll fraud is an attacker using stolen SIP credentials or an exposed trunk to place calls, usually to international premium-rate numbers that pay them a share of the termination fee, leaving you with the carrier bill. The three controls that stop most of it are default-deny international dialing per seat, a hard spend or minute cap set with your carrier, and velocity alerting that fires on unusual call patterns within the hour rather than on the monthly invoice.

Does SIP ALG improve softphone security?

No. SIP ALG is a NAT helper on many routers that rewrites SIP headers, and in practice it causes registration failures, one-way audio, and dropped calls more often than it helps. It also cannot see inside SIP that is protected by TLS, so on an encrypted deployment it is doing nothing useful. Disable it and rely on the softphone’s own NAT traversal.

Key Takeaways

• Most losses here are financial, not confidentiality losses. Toll fraud outweighs eavesdropping by orders of magnitude, and in softphone security terms it is stopped by dial permissions and spend caps rather than by encryption.
• Signalling and media encrypt separately. SIP over TLS protects the headers and credentials, SRTP protects the audio, and SRTP without TLS is close to worthless because the keys ride in the signalling.
• Ask for version-level answers. TLS 1.2 with modern ciphers as the floor, TLS 1.3 supported, certificate validation enforced, and no silent downgrade to UDP 5060.
• “End to end” is hop-by-hop for any call that touches a phone number. Say so to your customers before they find out on their own.
• Compliance is evidence, not encryption. VoIP security frameworks ask for proof, not protocols. HIPAA, SOC 2, GDPR and PCI each ask for logs, retention, agreements and proof. Ask any vendor to confirm their current certifications and audit status in writing.
• In a white-label deployment, write the responsibility split down. Every control with no named owner is an open control, and every configuration field left blank inherits a default.

Securing a softphone is unglamorous work: a dial plan reviewed, a spend cap set, a credential policy enforced, a responsibility table filled in per customer. But it is work that scales, and once the split is written down it takes twenty minutes a customer instead of a weekend of forensics. If you are a VoIP service provider, ITSP or MSP looking for a white-label softphone with security you can put your own brand on, take a look at the iotum Communicator and how it fits alongside the PBX and trunks you already run, or read up first on how softphones and VoIP fit together and what service providers get.

Book a demo to learn more about iotum’s capabilities.