Zero-Trust Architecture for Business VoIP: A Practical Guide
Zero-trust architecture applied to voice means no device, extension, or call is trusted by default because it is on the office network or presents a familiar caller ID — every registration, call, and administrative action must be independently verified.
This is a meaningful shift from how PBX security traditionally worked, where anything inside the firewall was implicitly trusted. VoIP’s attack surface does not respect that boundary, because calls originate from the public internet and caller identity is a claim, not a fact, unless something verifies it.
What is the real attack surface of a business phone system?
Four attack classes account for most incidents, and none of them require sophisticated tooling.
- SIP registration abuse. Attackers scan for exposed SIP endpoints and attempt to register fake extensions using weak or default credentials, then use the registered extension to place calls.
- Toll fraud. Once an extension is compromised, attackers route expensive international calls through it, often to premium-rate numbers they control, running up charges before anyone notices.
- Eavesdropping on unencrypted trunks. SIP signalling and RTP media sent in plaintext over the public internet can be intercepted and read by anyone positioned on the network path.
- Caller-ID spoofing. SIP allows the calling party to set an arbitrary caller ID, which is what makes robocalling and vishing (voice phishing) viable at scale.
None of these are new or exotic. They are the direct consequence of a protocol designed before the public internet was an adversarial environment, run today without the controls that address that.
How do you encrypt VoIP traffic in transit?
Encrypt both layers independently, because encrypting one without the other leaves a real gap. SIP signalling — the call setup and teardown messages — should run over TLS 1.3, not plaintext SIP or older TLS versions with known weaknesses. The actual audio, the RTP media stream, should run as SRTP (Secure RTP), which encrypts the voice payload itself.
| Layer | Unencrypted | Encrypted |
|---|---|---|
| Signalling (call setup) | Plain SIP — readable, spoofable | TLS 1.3 |
| Media (voice audio) | Plain RTP — interceptable | SRTP |
| Caller identity | Unverified claim | STIR/SHAKEN attestation |
A system can get this half right — TLS on signalling but plain RTP on media — and still leak the content of every call to anyone who can capture packets on the path. Confirm both are enforced, not just offered as an option, when evaluating a provider’s security posture.
What does least privilege mean for phone extensions?
It means an extension or user role can only do what its function requires, and nothing is granted by default beyond that. A receptionist extension rarely needs international dialling permissions. A conference room handset rarely needs the ability to forward calls externally. A new hire’s extension does not need admin console access just because the person who set it up had it.
In practice this means configuring outbound dialling permissions per extension or group (domestic only, domestic plus specific countries, or international), restricting admin console roles so that most users can manage their own settings but not organization-wide call routing, and reviewing permissions when roles change rather than only at provisioning. Over-permissioned extensions are the most common reason toll fraud losses are large rather than small — the fraud itself is caught quickly, but the compromised extension could reach expensive destinations before it was.
How does STIR/SHAKEN stop caller-ID spoofing?
STIR/SHAKEN is a framework that lets the originating carrier cryptographically sign a call’s caller ID, so the terminating carrier can verify the number wasn’t forged in transit. STIR (Secure Telephone Identity Revisited) defines the signing standard; SHAKEN (Signature-based Handling of Asserted information using toKENs) defines how carriers implement and pass that signature across networks. A signed call gets an attestation level — full, partial, or gateway — that tells the receiving network how confident it can be that the caller ID is genuine.
It does not eliminate spoofing everywhere overnight, because it depends on every carrier in the call path supporting it, but US carriers are required to implement it, and calls lacking valid attestation are increasingly flagged or blocked outright by carriers and handsets. Salamtalk is STIR/SHAKEN compliant, which keeps outbound calls from being marked as spam or blocked by terminating carriers.
What rate-limiting and geo-restrictions actually stop toll fraud?
Rate-limiting caps how many calls or how much spend an extension can generate in a time window, which contains the damage even if credentials are compromised. A practical configuration limits concurrent outbound calls per extension, caps spend per extension per day with an automatic hold once the threshold is hit, and flags any extension suddenly calling destinations it has never called before.
Geo-restrictions block outbound dialling to countries or number ranges a business has no legitimate reason to call. If your organization only operates in North America and Western Europe, there is no reason an extension should be able to dial premium-rate numbers in regions with no business relationship — restricting that range by default removes an entire fraud category rather than trying to detect it after the fact.
What should you log and monitor on a VoIP system?
At minimum: every registration attempt (successful and failed), every admin console login and permission change, outbound call destinations and durations per extension, and any attestation failures on inbound STIR/SHAKEN checks. Failed registration attempts clustering from one IP range is the earliest signal of an attack in progress, often hours or days before any fraudulent call is placed.
Retain these logs long enough to support an investigation after the fact — 90 days is a reasonable minimum for most organizations — and make sure logs are exported to a system an attacker who compromises the phone platform cannot also delete.
Is zero trust overkill for a small business phone system?
No — the controls that matter most (TLS 1.3, SRTP, STIR/SHAKEN, least-privilege extensions) are configuration, not infrastructure, so there is no meaningful size threshold below which they stop being worth enabling. A five-person office and a 500-seat contact center both benefit from the same baseline; what scales with organization size is the monitoring and review process around it, not the underlying controls. Salamtalk is SOC 2 Type II audited and aligned with HIPAA and GDPR requirements, so these controls are enabled by default rather than left as optional configuration.
Next steps: review the full control set on security, see how trunk-level encryption applies with SIP trunking, or contact us to discuss a security review for your current setup.