A phone number can look familiar, pass authentication checks, and still leave an enterprise exposed. An attacker may spoof a trusted number, misuse a legitimate one, or impersonate a supplier, employee, or customer. STIR/SHAKEN helps address number spoofing by providing cryptographic information about the calling number, but it does not establish who is actually speaking or whether the call is safe. For Voice Operations leaders, the challenge is understanding what these signals prove, what they leave unanswered, and how to turn them into meaningful decisions before a suspicious call reaches the business.
For Example: A finance team receives a call from a known supplier and asks to change bank details. An employee gets a call from an internal IT number and is told to reset credentials. A contact center receives a call from a customer and asks for information that should not be disclosed without verification. And all three calls are fake. [1, 2]
In each case, the danger is not simply that a phone rings, it’s that the call arrives carrying a claim of familiarity or authority. The recipient sees a number they recognize or a number that appears legit, so the conversation starts with an assumption of trust. This is the enterprise voice security problem I believe deserves more attention.
Organizations have spent years improving email security, endpoint security, network security and access controls. Voice still often relies on the recipient to decide whether the caller is who they say they are, even though the number on the screen is only one piece of evidence. [1, 2]
A phone number can easily be spoofed; A legitimate number can be used in a suspicious context, and a caller can claim to represent a vendor, customer, colleague or executive without the call signaling proving that relationship. Those are related risks, but they are not the same problem. A useful defense must understand what the network can/cannot verify, and where the enterprise needs to apply its own policy. [1, 2]
What STIR/SHAKEN actually verifies
STIR/SHAKEN improves caller authentication in IP voice networks. In a typical implementation: [1, 2, 3]
- The originating provider creates a signed PASSporT, conveyed in the SIP Identity header. [1]
- A downstream provider can validate the signature and the associated telephone number. [1, 2]
- The attestation level describes the originating provider’s basis for asserting the calling number. [2, 3]
All these are not proof that the caller is legitimate. [1, 2, 3]
The SIP message may carry From and P-Asserted-Identity (PAI) headers, and a downstream network may add a verstat parameter to either header to convey the number-validation result. The Identity header carries the signed PASSporT; verstat is a separate result. In deployments where the receiving carrier exposes the result in PAI, an example is: P-Asserted-Identity: <tel:+14085264000;verstat=TN-Validation-Passed>. Header placement and availability depend on the provider and configuration. [1, 4]
Even when the signature verifies, the result has a narrowly defined scope – it helps establish that the calling number assertion passed the relevant validation process. It does not, however, independently establish that the person speaking is the right and real one, nor does it establish the caller’s intent or whether the requested action is authorized. [1, 2, 3]
That distinction is central to the threat model. STIR/SHAKEN is a valuable layer against certain forms of caller ID spoofing but it should not be presented as a complete enterprise identity or fraud verification system – where an attacker originates traffic through a legitimate number, compromises a trusted endpoint, or uses a different number while impersonating a known person or organization, the enterprise still needs controls that evaluate the caller rather than just the number. [2, 3, 5]
Why a familiar number can still be dangerous
For a Voice Operations team, the practical question is not simply whether a carrier supports STIR/SHAKEN. It is whether the verification result reaches the enterprise’s SIP handoff, in a usable header, for the number type and route actually in production. A carrier may verify a call internally without exposing the result to the customer’s SBC. Delivery may also depend on service configuration, and the absence of verstat is not, by itself, proof of fraud or failed verification. The provider examples below separate field observations from publicly documented product behavior; they should be treated as a starting point for carrier validation, not as a nationwide coverage guarantee. [4, 6]
| Provider / platform | What the enterprise can expect | Operational implication |
| AT&T | In Assertion-observed traffic, verstat has appeared when requested. This is an operational observation, not a public, universal AT&T commitment. | Request written confirmation for the exact AT&T product, trunk, and SIP handoff. Test whether verstat is actually present in production traces. [7] |
| Verizon | Verizon documentation describes configurable acceptance of verstat on supported IP termination services. Assertion’s field observation is that delivery has been seen on toll-free traffic. | Ask Verizon to confirm support and configuration for the specific enterprise termination service. Validate delivery in raw SIP traces rather than assuming it is universal. [6] |
| Bandwidth | Public documentation describes optional inbound verification that can deliver verstat in P-Asserted-Identity; the feature must be enabled and the result depends on information received with the call. | Enable the inbound verification feature where applicable, then measure how often usable results arrive. [4] |
| Twilio | Twilio documents verification results through product-specific fields, including X-Twilio-VerStat for Elastic SIP Trunking and StirVerstat for Programmable Voice. Do not assume these are delivered as a literal verstat parameter in every product. | Validate the exact Twilio product and inspect its raw SIP or event output; provider-specific verification fields may differ from the literal verstat parameter. [8] |
| Telnyx | Telnyx documents inbound verification information in SIP headers, including verstat in P-Asserted-Identity for supported flows. Header forwarding may depend on connection and transport settings. | Confirm the connection and transport settings, then inspect inbound SIP headers to verify that the result is being forwarded. [9] |
For operations, treat verstat as one signal in a call-evidence pipeline and not as a universal reputation score. A passed result indicates that the relevant telephone-number identity validation passed under the applicable STIR/SHAKEN process; it does not authenticate the human being speaking, establish their authority, or certify that the call is benign. A missing result should be recorded as “not observed / unknown” unless the provider confirms a different meaning for that specific interface.
The first implementation task is a carrier acceptance test. For each provider, capture inbound SIP for calls to both a local DID and a toll-free number, using test calls from multiple originating networks. Record whether Identity is present, whether verstat appears and where, the value returned, the provider product / configuration, and whether the result survives any SBC or hosted-voice intermediary. Ask the carrier whether the feature is on by default or must be enabled, and retain its written answer. This gives operations a measured view of coverage on its own routes instead of assuming a US-wide state map that the available documentation does not establish.
Consider that a business may have known number range for their vendor. That information is useful, but it does not answer every question, like: [1, 2]
- Is the number spoofed?
- Does the signaling contain the expected identity information?
- Is the call arriving in a pattern that should trigger additional scrutiny?
- Is the number associated with complaints or another configured risk indicator?
Assertion Secure Voice addresses this as an inbound call control problem. Its controls include number validity checks, number type checks, P-Asserted-Identity validation, own-DID-range detection, carrier reported verstat handling, FCC complaint lookup and parallel caller detection.
Each control has a specific purpose. The PAI validator can compare the calling number presented in From with the number asserted in P-Asserted-Identity; an unexpected mismatch can be a useful spoofing indicator. PAI is supplied within a trusted network domain and commonly represents the network-asserted calling identity, but its presence alone does not prove who is speaking. Own-DID-range detection can identify calls that present the enterprise’s own registered number range as the caller. Neither check, on its own, proves human identity. [1, 7]
The objective is to combine the available evidence in a configurable pipeline and apply a policy before the call reaches the enterprise voice communication system. The controls do not magically know every vendor relationship or authenticate every human identity, they give the enterprise enforceable checks at the point where inbound calls are routed.
From detection to a controlled response
Detection is only useful if the system can do something with it.
An enterprise may choose to allow a call, redirect it for screening, block it or generate an alert, depending on the configured control and policy. Those actions should reflect the organization’s operating requirements.
A high-risk call pretending to be an internal administrator may be handled differently from an uncertain call that could be a genuine customer trying to reach support.
This is where the call path matters. Secure Voice places Defender as the first routing point behind the existing SBC. That position allows the configured controls to influence routing while the call is being handled, instead of relying solely on an alert that someone may review later. The existing SBC remains part of the enforcement path.
Why policy matters more than a universal score
It is tempting to reduce call risk to a single number. In practice, the meaning of a signal depends on the context that a failed validation result, a missing header, a call from an enterprise’s own DID range and an unusual burst of parallel calls are different observations. They should not automatically be treated as equivalent evidence or force the same response. [1, 2, 7]
Secure Voice is designed around configurable controls and tenant-specific policy. An enterprise can select and order controls and define what action follows. This matters because false positives have operational consequences: a blocked call can interrupt a legitimate business interaction, while an unexamined call can expose the organization to fraud or social engineering.
For a business head, the product question is not whether one signal can label every call as good or bad. It is whether the system gives voice and security teams practical controls, places them at the right point in the call path, and makes the resulting action understandable and configurable.
What this does and does not claim
This article focuses on inbound calls that spoof or misuse caller identity and impersonate vendors, customers, employees or internal stakeholders. [1, 2, 3]
The larger point is straightforward: a calling number is a useful piece of evidence, but it cannot carry the full burden of enterprise trust. STIR/SHAKEN helps validate a calling-number assertion. SIP signaling and configured controls provide additional evidence. The enterprise’s policy must decide how to act on that evidence before a suspicious call is allowed to influence a person or a process. [1, 2, 3, 7]
That is the problem Secure Voice is built to address: giving enterprises a way to apply call-security controls in the voice path, so a familiar-looking number does not get a free pass.
The question every enterprise should ask
If a call arrives with a familiar number, carries whatever validation evidence is available, and still comes from someone impersonating a supplier, customer or colleague, what stops it from reaching the person who can act on it? The uncomfortable question is not whether your organization has STIR/SHAKEN protection, it is whether your controls can make a decision before trust is exploited.
Put your defenses to the test
The most useful way to answer that question is to test it against your own call flows. Assertion offers a 30-day free pilot of Secure Voice, scoped around your existing SBC and agreed inbound threat scenarios. Your team can evaluate how configured controls behave, which calls are allowed, redirected or blocked, and whether the policy fits your operational needs.
If you want to know whether a trusted-looking number could still walk a caller into your organization, ask Assertion for an assessment and, find out what your defenses do before a real impersonation attempt forces you to find out the hard way.
References and further reading
[1] IETF, RFC 8224, “Authenticated Identity Management in the Session Initiation Protocol (SIP).” https://www.rfc-editor.org/rfc/rfc8224.html
[2] IETF, RFC 8588, “Personal Assertion Token (PASSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN).” https://www.rfc-editor.org/rfc/rfc8588.html
[3] Federal Communications Commission, FCC 25-76, discussion of STIR/SHAKEN scope, attestation and limitations. https://docs.fcc.gov/public/attachments/FCC-25-76A1.pdf
[4] Bandwidth Help Center, “STIR/SHAKEN Inbound Verification” (optional VERSTAT delivery, SIP header examples, and rollout caveat; updated March 17, 2026). https://www.bandwidth.com/support/en/articles/12823011-stir-shaken-inbound-verification
[5] Federal Communications Commission, “Unwanted Calls/Texts – Phone” (FCC overview of spoofing and enforcement; not a carrier-specific VERSTAT deployment statement). https://consumercomplaints.fcc.gov/hc/en-us/articles/115002234203-Unwanted-Calls-Texts-Phone
[6] Verizon Business, “Network Manager User Guide” (carrier-specific forwarding behavior referenced in the source draft; confirm the applicable version and service before relying on it). https://www.verizon.com/business/support/
[7] AT&T verstat availability for local DIDs and toll-free numbers: Assertion Ground Report (available on request); not independently verified by public AT&T documentation.
[8] Twilio, “STIR/SHAKEN for Elastic SIP Trunking” and Programmable Voice reference documentation (product-specific verification result fields). https://www.twilio.com/docs/voice/api/call-resource
[9] Telnyx, STIR/SHAKEN and SIP header documentation (inbound verification result and Identity-header forwarding behavior). https://developers.telnyx.com/docs/voice/sip-trunking