How a PBX security assessment works, step by step

1. Authorise and scope

Nothing begins without written authorisation. Testing telephony without permission is unlawful and, on a live system, potentially disruptive. The first step is a signed authorisation that names the systems in scope, the source addresses testing will come from, the permitted window, and any activity that is explicitly excluded.

Where the PBX is hosted, scoping also establishes right-party consent. You can authorise testing of the tenant, configuration, and endpoints you control, but the provider's underlying platform is theirs to consent to. Getting this straight at the outset keeps the engagement lawful and prevents scope creep into systems nobody agreed to touch.

2. Discover the telephony footprint

With authorisation in place, discovery maps what is actually reachable. This uses standard SIP signalling behaviour, such as OPTIONS and REGISTER requests, to identify live SIP services and responsive endpoints within the agreed scope. Passive open-source reconnaissance supplements this to find telephony assets that may be exposed without the organisation realising.

The output of this stage is an inventory: which SIP services respond, on which paths, and how the network handles them through NAT and STUN. It is common for discovery alone to surface systems the customer had forgotten, test instances, or services exposed more broadly than intended.

• Identify live SIP services and responsive endpoints in scope.
• Characterise NAT and STUN behaviour that affects reachability.
• Use passive OSINT to find telephony assets exposed to the public internet.

3. Identify and fingerprint

Knowing a service is live is not enough; you need to know what it is. Fingerprinting identifies the vendor and, where possible, the software version of each platform. That matters because vulnerability and configuration expectations differ sharply between, for example, an Asterisk-derived system and a proprietary appliance.

Accurate identification is what lets the assessment move from generic checks to specific ones. It determines which known vulnerabilities are relevant, which management interfaces might be present, and which hardening guidance applies. Getting this wrong produces noise; getting it right makes everything downstream precise.

4. Assess vulnerabilities and configuration

With platforms identified, the assessment checks them against known vulnerabilities and insecure configuration. Known-vulnerability checks map identified versions to documented CVEs, prioritising anything with active exploitation. Telephony platforms attract serious flaws: CVE-2025-57819, an unauthenticated remote code execution issue in FreePBX rated CVSS 10.0 and listed in the CISA Known Exploited Vulnerabilities catalogue, is a recent illustration of why version currency is not optional.

Configuration review looks at the settings that turn a working phone system into a liability: default or weak credentials, over-permissive dial plans, exposed management interfaces such as the Asterisk Manager Interface, and encryption gaps in signalling and media. The NCSC's PBX best-practice guidance frames the baseline here, covering default credentials, management access restriction, and control over who can make which calls.

• Map identified versions to known CVEs, prioritising actively exploited issues.
• Review dial-plan and outbound-calling permissions for least privilege.
• Check management interfaces, including AMI, for exposure and weak access control.
• Assess TLS on signalling and SRTP on media for encryption gaps.

5. Validate findings

A finding that has not been validated is a hypothesis. This stage confirms which weaknesses are real and exploitable, so your remediation effort goes where it counts rather than into a queue of theoretical alerts.

Extension exposure is checked, and credential strength is tested in a lockout-aware manner: testing is paced and bounded to respect account-lockout thresholds so it demonstrates weakness without locking out legitimate users or disrupting service. Where in scope and authorised, a controlled toll-fraud proof of concept demonstrates whether fraudulent outbound calling is genuinely possible, under agreed limits and stop conditions. This turns an abstract risk into a concrete, evidenced one without causing harm.

6. Prioritise by risk

Validated findings are ranked so the most damaging, most reachable issues rise to the top. Severity uses recognised scoring, with CVSS applied to vulnerabilities, combined with exploitability and business context. A weakness that enables fraudulent outbound calling on an exposed system outranks a low-severity information leak even if both are technically valid.

To make the financial dimension tangible, the assessment includes an overall risk score out of 100 and an illustrative estimate of toll-fraud exposure. That estimate is directional, not a prediction, but it helps decision-makers understand why a permissive dial plan deserves attention. Telecom fraud remains a large-scale problem: the Communications Fraud Control Association estimated global losses in 2023 at around US$38.95 billion.

7. Report in formats you can use

The report is the deliverable, and it serves two audiences. Leadership needs a clear narrative: what was found, how serious it is, and what to do first. Technical teams need detail they can act on and feed into their own tooling.

Findings are provided as a readable HTML report alongside machine-readable JSON and CSV, and SARIF output so results can flow into development and security workflows. Each finding carries a CVSS-based severity where applicable, evidence, and specific remediation guidance, sitting under the overall risk score and the illustrative toll-fraud estimate.

• HTML report for readable, prioritised findings and executive summary.
• JSON and CSV for integration, tracking, and analysis.
• SARIF for ingestion into security and development pipelines.
• Risk score out of 100 plus an illustrative toll-fraud exposure estimate.

8. Remediate and verify

A report that is filed and forgotten changes nothing. The value is realised when findings are remediated and the fixes are verified. Remediation guidance is specific to each finding: patch a named vulnerability, restrict a management interface, tighten a dial plan, enforce stronger endpoint credentials, or enable encryption on a given path.

Verification re-tests the specific items that were fixed to confirm the weakness is genuinely closed and that the change did not introduce a new gap. This closes the loop between finding and fix, and it gives you defensible evidence that the risk has actually been reduced rather than merely acknowledged.

9. Sustain assurance over time

A PBX is not static. Firmware changes, dial plans get edited, new sites come online, and fresh vulnerabilities are disclosed. A point-in-time assessment is a snapshot, and its accuracy decays as the environment moves on.

We are honest about how ongoing assurance is delivered. There is no always-on, real-time monitoring platform or customer portal behind this service. Recurring assurance is provided as an automated, scheduled reassessment that is operationally run and human-validated: the same disciplined methodology, repeated on an agreed cadence, so drift and newly disclosed issues are caught before they are exploited. That is a scheduled, automated reassessment that people run and validate, rather than always-on, real-time monitoring, and describing it that way avoids implying capability that does not exist.