In 2025, global losses from telecom fraud reached $41.82 billion, compared to $38.95 billion in 2023 (according to the CFCA Global Fraud Loss Survey 2025). International Revenue Share Fraud (IRSF) remains particularly critical for operators, causing approximately $6.23 billion in losses in 2023 alone. The primary tool for attackers remains CLI spoofing, which allows them to mask cross-border calls as local numbers or trusted brands of major enterprise clients.
Reactive defense methods—static blacklists and heuristic analysis—no longer provide sufficient protection. Traditional filters can block approximately 27.7% of dynamically changing fraudulent calls. Conversely, cryptographic authentication of the call source can cover up to 53.7% of previously elusive cross-border fraud vectors. However, implementing modern protocols in heterogeneous networks with legacy softswitches creates significant architectural challenges for CTOs and network architects.
Anatomy of 2025 telecom fraud: why reactive blacklists no longer protect brands
Cross-border fraud exploits the fundamental trust between operators. When a call is initiated in one country, transit networks often pass signaling information without additional cryptographic verification. Attackers use vulnerable SIP trunks to generate thousands of calls with spoofed numbers belonging to financial institutions or local subscribers.
According to the ENISA Threat Landscape 2025 report, the exploitation of legacy signaling protocols, such as SS7 and Diameter, remains a documented and extremely high risk for mobile network security. These vulnerabilities allow operators' basic filters to be easily bypassed. When a subscriber sees a familiar institution's number on their screen, they become a victim of social engineering. For a telecom operator, this means direct financial penalties, SLA termination, and reputational damage for corporate clients.
RFC 8224 standards and STIR/SHAKEN: how cryptographic signatures work in SIP signaling
To address the issue of number spoofing, the IETF engineering group developed the RFC 8224 standard, which defines a mechanism for Authenticated Identity Management in SIP. The industry-standard STIR/SHAKEN framework is built upon this foundation.
The technology utilizes public-key cryptography. The call processing flow includes several stages:
- Attestation: The originating provider determines the trust level of the subscriber (Attestation Level: A, B, or C).
- Signature generation: The authentication server creates a JSON Web Signature (JWS) object containing data about the originating/destination numbers and a timestamp. This signature is integrated into the SIP Identity header.
- Transit: The call with the cryptographic header is routed through transit IP networks.
- Verification: The terminating provider verifies the signature by accessing the originating operator's public key via a trusted certificate repository.
According to the governance model (e.g., as defined in FCC orders regarding Caller ID Authentication), only authorized operators whose certificates are issued by strictly regulated Certificate Authorities have the right to sign calls.
Architectural barriers: latency, legacy softswitches, and billing system challenges
Implementing STIR/SHAKEN is not merely a software update. In real-world telecom environments, it faces three critical obstacles:
The first issue is legacy softswitches. Many Class 4/5 switches do not natively support the processing of modern SIP Identity headers. Attempts to integrate this logic directly into a legacy core cause routing failures.
The second issue is Post-Dial Delay (PDD). Signature verification requires additional HTTP/HTTPS requests to certificate repositories. In high-load enterprise gateways, this creates critical overhead. Increased latency during connection establishment leads to QoS degradation and dropped calls.
The third issue is conflicts with billing (BSS/OCS). When a call is marked as "unverified" during the session, this logic must be instantly synchronized with the anti-fraud module and the charging system. Legacy billing systems are often incapable of changing the charging model on-the-fly based on the attestation level (Attestation C).
Integration strategy: dedicated authentication servers (AS/VS) and caching optimization
To avoid degrading network core performance, architects recommend moving away from in-line verification on legacy switches and transitioning to a service-oriented model with dedicated AS/VS (Authentication/Verification Service) servers.
In this topology, the Session Border Controller (SBC) or SIP proxy communicates with the AS/VS asynchronously. This isolates cryptographic computations from the signaling path. To solve the latency issue, it is necessary to configure local caching of partner operator public keys with short TTLs and implement background updates for Certificate Revocation Lists (CRL).
Architectural trade-off matrix for call authentication implementation
| Architectural approach | Infrastructure benefits | Technical challenges and risks |
|---|---|---|
| In-line verification on Softswitch | Simple network topology, no additional network hops. | High CPU load on legacy nodes, critical increase in latency (PDD). |
| Out-of-band verification (OOB) | Does not affect the SIP signaling path, maintains compatibility with TDM/SS7. | Complexity of real-time synchronization of signaling and information data. |
| Dedicated AS/VS proxy server | High scalability, complete isolation of cryptographic operations from the core. | Requirement to configure an additional routing hop in the SIP network. |
The role of end-to-end security: modernizing the telecom core without QoS degradation
Successful implementation of authentication standards requires a comprehensive approach: from network topology to billing systems. STIR/SHAKEN is not a silver bullet that instantly eliminates fraud, but it is a necessary foundation of trust that must work in synergy with internal anti-fraud systems.
To ensure such synergy, modern platform solutions that seamlessly integrate switching, security, and billing are required. An example of such a solution is DooxSwitch, a carrier-grade VoIP platform from the Intecracy Group technology alliance portfolio. Thanks to its built-in real-time billing and flexible LCR routing, DooxSwitch allows for call processing that accounts for cryptographic verification results without desynchronization with BSS systems.
For large enterprise companies and telecom operators (Tier-1/2), the expertise of Intecracy Group allows for the design of secure VoIP architectures and the modernization of legacy OSS/BSS components. This ensures seamless integration of STIR/SHAKEN mechanisms, minimization of latency, and reliable brand protection against exploitation via cross-border telecom fraud.
FAQ
How does the STIR/SHAKEN standard affect Post-Dial Delay?
Cryptographic signature verification and certificate downloads can add milliseconds to Post-Dial Delay (typically 100 to 500 ms). To mitigate this impact, an architecture with dedicated AS/VS servers and efficient local caching of partner certificates is used.
What should be done with calls passing through transit networks that do not support SIP Identity?
Such calls generally receive a lower attestation level (Gateway Attestation, C). The receiving operator can route them according to security policies: add an "Unverified" label to the subscriber's screen or direct them to an IVR for additional verification before connecting.
How can certificate verification be integrated into legacy PBXs operating on SS7?
For legacy TDM/SS7 networks, an Out-of-Band (OOB) authentication approach is used. Signaling follows the classic path, while cryptographic tokens (SIP Identity) are transmitted in parallel via a secure API channel to the verification server of the receiving network.