IT Managers: 5 Vendor Questions That Prevent Caller ID Spoofing

Caller ID spoofing prevention on a business cloud phone system comes down to three things working together: provider-level caller signing under STIR/SHAKEN or an equivalent standard, platform controls inside your telephony estate, and carrier cooperation when a number needs blocking. Confirm your provider signs calls with A-level attestation wherever it controls the number, keep a locked-down inventory of every CLI allowed to present on outbound calls, switch on SIP authentication across every trunk, and get a named carrier escalation contact in writing before you need one.

TL;DR:

• Ensuring all outbound calls are signed with A-level attestation across every trunk, gateway, and international route is critical for effective spoofing prevention.
• Regular updates to CLI inventories, strict control over authorized numbers, and enforcement of SIP security measures prevent unauthorized caller ID presentation.
• Carrier cooperation relies on documented escalation processes, including specific evidence requirements and designated contacts, to block spoofed numbers quickly.
• Internal staff training and simple reporting channels can catch spoofing attempts early, supplementing technical controls and reducing incident response times.
• Continuous review of attestation coverage, certificate health, and provider processes is necessary as spoofing techniques evolve and new interconnects are added.

Table of Contents

• Caller ID spoofing prevention checklist for the next 90 days
• How does caller ID authentication actually work?
• What should you ask a cloud telephony vendor before signing?
• Platform controls that stop spoofed calls before they connect
• Working with carriers and the TCF Scam Prevention Code
• Investigating a suspected spoofing incident
• Keeping spoofing defences current as tactics evolve
• Why staff reporting matters as much as the technical controls
• Fitting spoofing controls into your existing security stack
• Vendor evaluation criteria that actually matter
• Common pitfalls when deploying STIR/SHAKEN and SIP identity
• What surprises IT managers most about spoofing prevention
• How Vadacom supports caller ID authentication in practice
• Sources
• FAQ

Caller ID spoofing prevention checklist for the next 90 days

Most IT managers inherit a phone estate where nobody has ever asked the provider what attestation level it actually applies. That is the first gap to close, and it is the cheapest to close.

Start with the questions that expose weak signing coverage, then work down to the operational controls that stop spoofed calls from ever reaching a call flow.

• Ask your provider to confirm attestation and signing coverage across every leg, including SBC gateways and any international interconnects.
• Build a CLI/DID inventory that lists every number authorised to present outbound, and lock changes behind an approval step.
• Turn on SIP or trunk authentication, IP allowlists, and TLS on every trunk that supports it.
• Get carrier blocking and escalation processes in writing, with a named contact and a response time.

Pro Tip: Run the CLI inventory audit before you touch anything else. Every other control depends on knowing exactly which numbers should legitimately be leaving your network, and most SMBs discover during this step that at least one legacy trunk is presenting a number nobody remembers assigning.

How does caller ID authentication actually work?

Caller ID authentication works by having your provider cryptographically sign each outbound call so the receiving network can verify the caller actually has the right to use that number. This is the STIR/SHAKEN framework, and the mechanics matter more to your risk exposure than most vendor pitches suggest.

When a call leaves your network, an authentication service generates a signed token called a PASSporT and inserts it into the SIP Identity header travelling with the INVITE, as defined in RFC 8224. The receiving carrier’s verification service checks that signature before the call rings through. RFC 8588 extends PASSporT with the attestation claim and an “origid” field, which is the traceback identifier investigators use to trace a spoofed call back to its origin.

Attestation comes in three levels, and the differences are operationally significant:

• A-level: the provider verified the caller is authorised to use that number. This is what you want for every number you own.
• B-level: the provider knows the customer but cannot verify their right to the specific number.
• C-level: the provider only knows where the call entered its network, nothing more.

Attestation gaps compound at the FCC notes point out that signing can be lost entirely when a call crosses a non-IP segment or an older gateway, which is exactly where legacy PBX trunks and international carriers tend to sit. SIP registration under RFC 3261 authenticates a device to a network, but it says nothing about whether the caller ID presented is genuine. You need both controls running, not one standing in for the other.

What should you ask a cloud telephony vendor before signing?

Vendor answers on signing and attestation separate providers who take spoofing seriously from providers who simply tick a compliance box. Put these questions in writing and keep the answers on file.

1. What attestation level do you apply to our outbound calls, and does that level hold across every trunk and gateway we use?
2. Where does signing physically occur: on your network, or does a third party sign on your behalf?
3. What log retention period applies to Identity headers and PASSporT data, and can you export that data in a usable format during an incident?
4. What is your documented robocall mitigation plan, and can you name the person or team who executes it?
5. Under what conditions will you request carrier-level blocking of a spoofed number, and what is your SLA for acting on that request?

Some providers run hosted or carrier-managed SHAKEN rather than signing in-house. That is not necessarily a weaker option, but you need to know which model you are buying, because it changes who controls the attestation decision when something goes wrong.

Pro Tip: Write the incident SLA and evidence-export format into the contract itself, not into a support ticket after the fact. A verbal promise of “we’ll help during an incident” is worthless at 2am when a spoofed number is hitting your customers.

Platform controls that stop spoofed calls before they connect

Standards compliance from your provider only covers half the job. The other half sits inside your own platform configuration, and this is where most SMBs leave gaps that a determined attacker finds quickly.

SIP and trunk authentication is the foundation. Use strong, unique credentials per trunk, restrict registration to known IP ranges through allowlisting, and enable TLS and SRTP wherever your platform supports them. Loosely secured trunks are a common entry point for both toll fraud and spoofed outbound traffic, and they are also the easiest thing on this list to fix in an afternoon.

CLI governance needs to move from a spreadsheet nobody updates to an enforced process. Maintain the authoritative inventory of every outbound CLI, require sign-off before any new number is authorised to present, and configure your platform to reject presentation attempts for numbers not on that list. This single control closes the gap the FCC’s own guidance flags as the weak point in attestation: a number displaying correctly is not proof anyone verified the right to use it.

Call-flow and trunk-level filters do the rest:

• Flag or block calls presenting a blank or malformed CLI.
• Return the correct SIP response code for traffic your platform does not trust, rather than silently dropping it, which helps downstream diagnosis.
• Apply rate and volume limits per trunk so a compromised credential cannot generate a burst of spoofed outbound traffic before anyone notices.

Working with carriers and the TCF Scam Prevention Code

Provider-side signing and your own platform controls only get you so far. When a number is actively being spoofed, you need the carrier network to act, and that depends on the process your provider follows.

In New Zealand, the TCF Scam Prevention Code sets out how network operators share scam indicators, issue verified and advisory scam notices, and apply edge-network blocking against confirmed scam traffic. A provider that participates properly in this code can move from “we’ve noted the complaint” to actual blocking far faster than one that does not.

Carriers need specific evidence to act, not a general complaint:

• The exact number or number range being spoofed, with timestamps.
• Traffic characteristics: call volume, duration patterns, and destination spread.
• Logs showing origid and Identity header data where available, to support traceback.

Test this before you need it. Ask your provider to walk through a mock escalation and confirm who on their side actually has authority to request upstream blocking, because that authority sometimes sits with a partner carrier, not the provider itself.

Investigating a suspected spoofing incident

When a spoofing report lands on your desk, the speed of resolution depends entirely on whether your logs captured the right fields before the incident happened. Retrofitting logging during a live incident wastes hours you don’t have.

Capture these fields as standard: the full SIP INVITE, the Identity header and PASSporT contents, the origid claim, trunk ID, precise timestamps, and the call path metadata showing which network elements the call traversed.

1. Validate the PASSporT signature first to confirm whether the call was signed at all, and at what attestation level.
2. Map the origid value to the specific provider element that originated the call. Without this field, a background pattern in traceback investigations is that resolution slows down and usually ends up requiring manual carrier coordination.
3. Check whether the call path crossed a legacy or non-IP gateway, since that is where signature and attestation data commonly drop out.

Run scheduled signed-call tests against your own trunks, verify interconnect paths quarterly, and re-test every time a provider or trunk configuration changes. A control you haven’t re-tested since deployment is a control you’re hoping still works.

Pro Tip: Log origid on every call from day one, even before you have an incident to investigate. It’s the one field that turns a multi-day carrier escalation into a same-day traceback.

Keeping spoofing defences current as tactics evolve

Spoofing prevention is not a set-and-forget deployment. Attackers adjust their methods faster than most SMB IT teams revisit their configuration, and a control that worked well last year can quietly degrade without anyone noticing.

Review attestation coverage every time you add a trunk, change carriers, or onboard an international route. New interconnects are exactly where signing gaps reappear, since a provider that signs cleanly on domestic traffic may hand international calls to a partner network with weaker or no signing support. Schedule this review on a calendar, not as a reaction to a complaint.

Revisit your CLI inventory on the same cadence as staff and vendor changes. Numbers get decommissioned, ported, or reassigned, and a stale inventory either blocks legitimate calls or, worse, leaves an old presentation rule active for a number nobody uses anymore.

Certificate handling deserves its own check. RFC 8226 governs how providers assert authority over telephone numbers through certificates, and certificate expiry or misconfiguration silently breaks signing without any obvious symptom until a downstream carrier starts rejecting your calls as unverified. Ask your provider how they monitor certificate health and whether you’d be notified before an expiry causes an outage.

Finally, treat vendor robocall mitigation plans as living documents. A plan written two years ago rarely accounts for current spoofing techniques, so ask for the plan’s last review date as part of any annual contract renewal, not just at initial signup.

Why staff reporting matters as much as the technical controls

Technical signing and platform filters catch a lot, but they don’t catch everything, and the calls that slip through are usually the ones your own staff notice first. A receptionist who gets three near-identical calls from a “customer” using slightly wrong terminology is often your earliest warning of a spoofing campaign targeting your business number.

Build a simple, low-friction internal reporting path. Staff need one obvious place to flag a suspicious call, whether that’s a shared inbox, a ticket category, or a Teams channel, and it needs to take under a minute to use. If reporting a suspicious call requires five clicks through an unfamiliar system, most people won’t bother, and you lose the early signal.

Train staff on what actually indicates spoofing rather than generic “be careful” messaging: a caller ID matching a known number but the voice or request pattern feeling off, unexpected calls claiming to be from your own IT or finance team, or a spike in complaints about calls appearing to come from your business that you never made. These are patterns your platform logs won’t flag on their own, because the call itself may be signed and technically legitimate on the network side.

Feed every internal report into the same log you use for technical incident triage. A pattern of five staff reports in a week is a much stronger case for carrier escalation than a single ambiguous log entry, and having both data sources ready speeds up the carrier evidence conversation covered earlier.

Fitting spoofing controls into your existing security stack

Caller ID spoofing prevention shouldn’t sit as an isolated project bolted onto your phone system. It belongs inside the same security architecture you already run for network and endpoint protection, and treating it separately is how gaps appear.

If your voice traffic passes through a session border controller, that SBC is a natural enforcement point for CLI governance and trunk-level filtering, sitting between your carrier trunks and your internal call-flow platform. Configure it to reject or flag calls with blank, malformed, or unauthorised CLI presentation before they ever reach a user’s handset or an IVR flow.

Firewall rules protecting your SIP trunks deserve the same scrutiny you’d apply to any other exposed service. IP allowlisting on trunk registration, rate limiting against burst attacks, and logging that matches the retention period you’d apply to any other security-relevant data source all belong in the same review cycle as your firewall’s other rule sets.

Your security information and event management setup, if you run one, should ingest voice logs alongside network logs. A spike in failed SIP registration attempts is a security event in exactly the same category as a failed login spike on a corporate account, and it deserves the same alerting threshold. Treating voice security as a silo separate from IT security is how a compromised trunk credential goes unnoticed for weeks instead of hours.

Vendor evaluation criteria that actually matter

Most vendor comparisons for cloud telephony focus on call quality, uptime, and price, and rightly so, but spoofing prevention capability rarely gets the same scrutiny during procurement. It should, given how directly it affects your legal and reputational exposure.

Ask specifically whether attestation is applied at A-level for numbers you control, not just whether the provider “supports STIR/SHAKEN” in general terms, since that phrase covers a wide range of actual signing quality. A provider offering hosted or carrier-managed SHAKEN isn’t automatically weaker, but you need clarity on who signs the call and who controls the attestation decision when a dispute arises.

Push for concrete answers on log retention and export format before you sign anything. A provider that can’t produce Identity header and origid data in a usable format during an incident will slow down every future investigation, no matter how strong their signing coverage looks on paper.

Confirm participation in relevant industry blocking frameworks, such as the TCF Scam Prevention Code in New Zealand. A provider engaged in that process can request edge-network blocking against confirmed scam traffic far faster than one operating outside it. This single criterion often separates providers who treat spoofing as a compliance checkbox from those who treat it as an operational responsibility.

Common pitfalls when deploying STIR/SHAKEN and SIP identity

Deployment rarely fails at the standards level. It fails at the seams, the places where signing quietly drops out or where a team assumes coverage that was never actually confirmed.

The most common pitfall is assuming attestation is uniform across an estate when it isn’t. A provider might sign domestic calls at A-level while handing international traffic to a partner carrier with weaker or absent signing, and nobody notices until a compliance review or an incident forces the question.

Legacy gateways and older PBX trunks are the second recurring gap. The FCC’s own framing is explicit that authentication is an IP-network mechanism, and any call segment that touches a non-IP leg can lose signature data entirely, silently, with no error thrown anywhere.

Teams also frequently confuse SIP registration security with caller-ID authentication, treating a properly secured trunk as proof the caller ID presented is legitimate. Under RFC 3261, registration authenticates the device to the network. It says nothing about whether the number presented on that device’s outbound calls is genuine. Both controls need enforcing, and neither substitutes for the other.

Finally, many SMBs deploy signing once and never revisit it, missing certificate expiry, provider changes, or new trunk additions that reopen gaps closed months earlier.

What surprises IT managers most about spoofing prevention

The gap that catches most teams off guard isn’t the standards themselves, it’s the distance between a number displaying correctly and anyone having actually verified the right to use it. Attestation levels exist precisely because that distance is real, and B and C level signing leave more of it open than most procurement teams assume going in.

Local, telco-grade support shortens the distance between spotting an anomaly and getting a carrier to act on it, because the escalation contact already exists and the evidence format is already agreed rather than negotiated mid-incident. A provider that has walked through blocking requests before responds faster than one working it out for the first time under pressure.

— Stuart

How Vadacom supports caller ID authentication in practice

Getting attestation, CLI governance, and carrier escalation working together usually takes more than a single settings change, which is why a platform built for it matters. NextVoice runs on telco-grade cloud architecture across multiple availability zones, giving your business the call-flow controls, in-app recording, and logging that support the operational side of spoofing prevention without you managing hardware.

Where NextVoice earns its place in this checklist is the local support behind it. Experienced teams delivering and supporting business communications can be invaluable when you’re chasing a carrier escalation at short notice and need someone who already knows the process. If your current setup has never had its signing coverage or CLI governance properly reviewed, a technical audit is the practical starting point, surfacing exactly where your existing trunks and gateways stand before you commit to changes. For teams wanting deeper forensic visibility on top of the platform, AI Call Intelligence adds call recording and analysis you can layer onto the logging this article recommends. Talk to Vadacom about a technical audit of your current call flows and trunk configuration.

FAQ

Is caller ID spoofing illegal?

Whether spoofing a caller ID is illegal depends on intent and jurisdiction, since regulators generally target spoofing done to defraud, cause harm, or mislead rather than legitimate business uses like presenting a head-office number. In New Zealand, the TCF Scam Prevention Code addresses the network-level response to scam traffic rather than setting criminal law itself, so check current government guidance for the legal position in your specific case.

What’s the difference between SIP registration and caller ID authentication?

SIP registration, defined under RFC 3261, authenticates a device or trunk to your network, confirming it’s allowed to connect. Caller ID authentication under STIR/SHAKEN is a separate process that verifies whether the number presented on an outbound call is genuine, and a system can have one secured without the other.

What is attestation level A versus B or C?

A-level attestation means the provider has verified the caller is authorised to use the presented number, the standard to aim for on any number your business controls. B-level means the provider knows the customer but not their right to that specific number, and C-level means the provider only knows where the call entered its network.

How do I get a spoofed number blocked?

Report the spoofed number to your provider with timestamps, traffic patterns, and any available log data, and ask them to escalate through their carrier’s process. In New Zealand, providers participating in the TCF Scam Prevention Code can request edge-network blocking against confirmed scam traffic once sufficient evidence is presented.

Does NextVoice support caller ID spoofing prevention?

NextVoice provides the platform-level controls, including call-flow management, in-app recording, and logging, that support the operational side of spoofing prevention, backed by Vadacom’s local support team for carrier coordination. Pricing for NextVoice is available on request through Vadacom’s site.