The rise in global telecom fraud losses to $41.82 billion in 2025, according to the CFCA Global Fraud Loss Survey 2025, has transformed voice traffic protection from a secondary task into a critical element of brand reputation management. Today, Caller ID spoofing is a primary tool for cross-border attacks and complex schemes such as International Revenue Share Fraud (IRSF), which cost operators $6.23 billion in 2023. For telecom CTOs, this necessitates a rapid shift from passive monitoring to active cryptographic verification of every voice connection.
Anatomy of telecom fraud: why legacy signaling is powerless against spoofing
The fundamental problem in telecommunications networks lies in their historical trust architecture. Public networks were designed on the premise that every operator in the transit chain is inherently trusted. However, as the ENISA Threat Landscape 2025 report notes, the exploitation of legacy signaling protocols like SS7 and Diameter remains a significant attack vector. Attackers leverage signaling vulnerabilities to inject false messages, allowing them to spoof Caller ID with any arbitrary number.
In traditional infrastructure, a transit operator receives a SIP INVITE request and passes it along, relying on text data in the headers. Practice shows that up to 53.7% of cross-border traffic in certain segments may be subject to Calling Line Identification (CLI) manipulation, while simple static filters at border nodes can reject only about 27.7% of such traffic. Without end-to-end cryptographic verification of the sender, it is impossible to guarantee the authenticity of a call's origin.
STIR/SHAKEN standards: how cryptographic verification of the SIP Identity header works
To address this, the industry is adopting the STIR/SHAKEN standard stack. The technical foundation of STIR (Secure Telephone Identity Revisited), described in IETF RFC 8224, defines the use of a special Identity header in the SIP protocol to carry cryptographically signed call information.
The end-to-end authentication process consists of several architectural stages:
- Call initiation: The originating operator's Session Border Controller (SBC) receives a SIP INVITE request from the subscriber.
- Token generation: The operator verifies the subscriber's right to use the number and generates a cryptographic PASSporT token (in JSON Web Token format).
- Signing: The token is signed with the operator's private key and integrated into the SIP Identity header.
- Verification: The terminating operator extracts the Identity header, retrieves the originating operator's public key from a trusted repository, and validates the mathematical signature.
Architectural integration challenges: managing latency and preserving billing accuracy
Implementing STIR/SHAKEN creates challenges for heterogeneous networks, the most significant being an increase in Post Dial Delay (PDD). Cryptographic operations and queries to external certificate repositories take time. To minimize the impact on latency, engineers configure local certificate caching in SBC memory so that verification time does not exceed regulatory thresholds.
The second challenge is synchronizing signaling infrastructure with billing systems (BSS). Adding large new SIP headers can lead to UDP packet fragmentation. Furthermore, billing systems must correctly parse the call attestation level in Call Detail Records (CDR). For seamless integration, it is advisable to use carrier-grade platforms with flexible signaling processing. For example, the VoIP platform DooxSwitch (a solution from the Intecracy Group technology alliance) combines softswitch, LCR routing, and real-time billing functions, allowing for the processing of high volumes of SIP traffic without performance degradation or billing errors when new Identity headers are introduced.
Soft launch strategy: handling unattested calls
According to regulatory documents, such as the FCC First Caller ID Authentication Report and Order, SHAKEN defines three attestation levels:
- Level A (Full Attestation): The operator has fully identified the client and their right to use the specific number.
- Level B (Partial Attestation): The operator knows the traffic source (e.g., a corporate SIP trunk) but has not verified every number in the pool individually.
- Level C (Gateway Attestation): The transit operator only records the gateway through which the traffic arrived from another (often international) network.
During the transition period, not all calls will contain a cryptographic signature. A soft launch strategy involves avoiding the hard blocking of traffic with Level B, C, or no signature at all to prevent the rejection of legitimate calls. Instead, such calls are flagged, subjected to enhanced analysis at anti-fraud gateways, or accompanied by a warning on the device screen.
Building a trusted environment: certificate management infrastructure
The reliability of STIR/SHAKEN depends on Public Key Infrastructure (PKI) and certificate governance policies. For large operators, regular key rotation, access management, auditing, and integration with national certificate authorities are significant architectural tasks.
Registries and portals for managing these processes can be deployed on enterprise platforms. For instance, such solutions are successfully built on the UnityBase platform (a joint development by companies within the Intecracy Group alliance; InBase is a key, but not the sole, developer). Thanks to the platform's mechanisms—such as domain metadata, role-based access control (RBAC/RLS), and strict audit trails—a secure environment is created for key generation, distribution across network nodes, and compliance adherence.
It should be remembered that cryptographic authentication is not a panacea for all types of fraud. It confirms the identity of the initiator but does not replace comprehensive security policies. However, it is an essential baseline without which a trusted telecom ecosystem cannot exist.
SIP infrastructure readiness checklist for STIR/SHAKEN implementation
| Evaluation criterion | Technical requirement | Target metric / Action |
|---|---|---|
| SBC compatibility | Support for SIP Identity header processing (RFC 8224) by session controllers. | Update SBC software to a version supporting PASSporT JWT. |
| PKI integration | Interaction with accredited certificate authorities. | Configure ACME clients or a secure API gateway. |
| PDD optimization | Maintaining call setup latency within normal limits. | Implement local certificate caching (validation time < 50 ms). |
| Routing | Presence of rules for Level A, B, and C attestations. | Create flexible policies for unattested international transit. |
| BSS synchronization | Compatibility of billing systems with new SIP headers. | Test CDRs for correct display of attestation levels. |
FAQ
How does STIR/SHAKEN implementation affect Post Dial Delay (PDD)?
Cryptographic signature verification and queries to certificate repositories increase call setup time. To keep PDD within normal limits, operators use local public key caching directly at the SBC and asynchronous requests.
What should be done with calls from cross-border operators that do not support cryptographic signatures?
International transit without a signature typically receives a Level C (Gateway Attestation) marking at the entry point. It is not recommended to block them automatically to avoid losing legitimate traffic; instead, additional anti-fraud filters are applied.
How should attestation levels be configured for corporate clients using dynamic number pools?
For PBX or SIP trunks of corporate clients, Level B (Partial Attestation) is most commonly used. This means the operator confirms the client's identity as the traffic source but does not guarantee ownership of every specific number from an unverified pool.