Global telecom fraud losses reached $41.82 billion in 2025, highlighting the critical vulnerability of modern corporate communications. Traditional perimeter defense tools, such as Session Border Controllers (SBC), often prove insufficient for countering Caller ID manipulation, as they are not always capable of cryptographically verifying the origin of a SIP call.
Why SBC no longer guarantees security: limitations of perimeter defense
Many corporate VoIP networks rely on trust in IP addresses or Access Control Lists (ACL). However, the SIP INVITE standard is architecturally vulnerable to number spoofing, as standard SBC configurations often ignore cryptographic sender authentication. For network architects, this necessitates a transition from a perimeter-based model to cryptographic authentication.
STIR/SHAKEN architecture: how SIP Identity and certification work
The STIR/SHAKEN framework defines the technical process for call authentication and a system of certification trust. According to the RFC 8224 standard, sender information is transmitted in encrypted form via an Identity header in the SIP INVITE. This allows the call recipient to verify the legitimacy of the phone number usage via a public key issued by a trusted authority.
Technical verification pipeline
The verification process is based on the cryptographic validation of the signature accompanying the call. A corporate network implementing this standard must be able to recognize the call attestation level. Given that a significant portion of calls in the corporate segment requires additional verification, automating this process becomes mandatory.
Integrating call attestation into corporate audits
For effective fraud prevention, call attestation results must be integrated into internal monitoring systems. Call processing solutions, such as DooxSwitch, support modern authentication standards. For building audit and logging systems, it is advisable to use the UnityBase platform. Thanks to its domain model management and API generation capabilities, engineers can automate the processing of security events, achieving a high level of traffic analysis automation.
Implementation strategy
STIR/SHAKEN is not a complete replacement for security policies, but it provides the necessary information base for decision-making. Implementing the framework allows SBCs to apply flexible routing policies for calls with different attestation levels, minimizing risks without blocking legitimate traffic.
Algorithm for processing incoming SIP calls with verification
| Step | Action |
|---|---|
| 1 | Receive SIP INVITE and extract Identity header |
| 2 | Request public key from the certification authority |
| 3 | Cryptographic signature verification |
| 4 | Assign attestation status (Verified/Unverified) |
| 5 | Log result in UnityBase and route call |
FAQ
Does STIR/SHAKEN replace security policy configuration on SBCs?
No, it is an authentication framework. It provides data for decision-making, based on which SBC policies should manage call routing.
How to integrate STIR/SHAKEN verification into legacy systems?
Legacy VoIP gateways may require an intermediate SBC or an integration layer to verify signatures before passing traffic to the internal PBX.
How to link attestation results with internal enterprise systems?
Attestation results can be transmitted via API to the UnityBase platform, allowing for a detailed audit trail and automated responses to suspicious activity.