Cloud PBX vs on-premises PBX: the security differences

Why this comparison matters now

Openreach is withdrawing the traditional analogue and ISDN telephone network, with the national switch-off scheduled for 31 January 2027. Lines that once ran over copper are being replaced by IP-based voice, which means a PBX that used to sit quietly behind a physical trunk now speaks SIP over the same networks that carry everything else.

That migration changes the threat picture. An IP telephony platform is reachable, enumerable, and subject to the same categories of weakness as any other internet-facing service: exposed management interfaces, weak authentication, unpatched software, and permissive dial plans that allow fraudulent outbound calling. Whether the platform is hosted by a provider or run in your own comms room shapes how those weaknesses arise and who is positioned to fix them.

Exposure and attack surface

On-premises PBX systems concentrate risk in equipment you control. The attack surface is defined by what you expose to the internet, typically SIP signalling, a management interface, and remote-worker or trunk connectivity. If those are published without adequate filtering, the system is discoverable and can be probed for weak extensions and known software flaws. The upside is that the surface is yours to shrink.

Cloud PBX moves the core platform into a provider's estate, but it does not remove your exposure. Your tenant, your extensions, your SIP credentials, and any on-site handsets or gateways remain yours to secure. Misconfiguration of a tenant, reused or weak endpoint passwords, and poorly restricted calling permissions are all within your responsibility even when the underlying servers are not.

• On-premises: broader self-managed surface, full visibility, full accountability for hardening.
• Cloud: narrower self-managed surface, but tenant configuration, endpoints, and credentials still expose you.
• Both: SIP endpoints and outbound calling permissions are common paths to fraud regardless of hosting model.

Patching responsibility

Patching is where the two models diverge most sharply. With an on-premises PBX, the whole software stack is yours to maintain: the telephony application, its web interface, the operating system, and any modules or add-ons. Delayed patching is one of the most common findings we see, and telephony platforms are an active target for serious vulnerabilities.

A concrete example is CVE-2025-57819, an unauthenticated remote code execution flaw affecting FreePBX that was rated CVSS 10.0 and added to the CISA Known Exploited Vulnerabilities catalogue. A vulnerability of that severity in a self-hosted PBX is a direct route to compromise if the system is exposed and unpatched.

With cloud PBX, the provider patches the core platform, which removes a substantial maintenance burden. What does not disappear is your responsibility for the components you still own: firmware on handsets and gateways, any on-premises session border controller, and the configuration of your tenant. Provider patching also introduces a dependency you should verify contractually rather than assume.

The shared-responsibility model

Cloud telephony follows the same shared-responsibility principle as other cloud services. The provider secures the platform they operate; you secure how you use it. The failure mode is not usually a breach of the provider's infrastructure. It is the quiet assumption that moving to the cloud transferred all security duties along with the servers.

• Provider typically owns: platform software patching, core infrastructure, physical security, network for the hosted service.
• You typically own: tenant and dial-plan configuration, extension and SIP credentials, endpoint firmware, access control for administrators, and fraud-limit settings.
• Shared and worth confirming: logging and alerting, incident response roles, and the process for reporting suspected fraud or compromise.

On-premises has no such division. Every layer is yours, which is simpler to reason about but heavier to maintain. Neither model is inherently more secure. The safer one is the one whose responsibilities you have mapped and are actually meeting.

Authentication and access

Authentication weaknesses cut across both models. SIP endpoints authenticate with credentials that are frequently weak, reused across extensions, or left at vendor defaults. Where an extension number and its secret follow a predictable pattern, an attacker who can reach the signalling can attempt to register rogue devices and place calls at your expense.

Administrative access is the higher-value target. On-premises management portals exposed to the internet, or cloud tenant administration without multi-factor authentication, give an intruder control of the dial plan and the calling permissions that fraud depends on. The NCSC's PBX guidance is direct on the fundamentals: change default credentials, restrict management access, and control who can make what type of call.

Authorisation to test: a real difference

There is one security-relevant difference that is procedural rather than technical, and it catches organisations out. Testing a system you host on infrastructure you control is straightforward to authorise. Testing a cloud PBX means assessing a system that runs inside a provider's environment, and you cannot unilaterally consent to testing assets you do not own.

A responsible assessment of a hosted platform requires right-party consent: confirmation that the party who owns the environment permits the specific activity, within agreed boundaries. In practice we scope hosted-PBX engagements to the customer-controlled configuration and endpoints, obtain the necessary permissions or defer to what the provider allows, and avoid activity that would test the provider's shared infrastructure without their agreement. This keeps the work lawful and within scope rather than reaching into someone else's estate.

• On-premises: you can authorise testing of the full system you own.
• Cloud: you authorise testing of your tenant, configuration, and endpoints; the provider's platform requires their consent.
• Either way, written authorisation defining targets, timing, and limits comes before any testing begins.

What an authorised assessment covers for each

For an on-premises PBX, an authorised assessment can examine the full stack you control. That includes discovering exposed SIP services, fingerprinting the platform and version, checking for known vulnerabilities and insecure configuration, reviewing management interfaces such as the Asterisk Manager Interface, testing extension exposure and credential strength in a lockout-aware manner, and running a controlled, agreed proof of concept to demonstrate whether fraudulent outbound calling is possible.

For a cloud PBX, the assessment concentrates on what you own and configure: endpoint and tenant exposure, SIP credential strength, NAT and STUN behaviour, TLS and SRTP encryption on the paths you control, dial-plan and calling-permission review, and the fraud-control settings that limit financial damage. The provider's core platform is out of scope unless they authorise otherwise.