STIR/SHAKEN and caller ID authentication, explained for businesses

Published by OttoCall Editorial Team · Published 13 November 2026 · Published automatically after quality, citation and claims checks

5 min read

Caller ID gives a business a way to identify an incoming call, but the identity shown on a call and the evidence supporting it are different things. STIR/SHAKEN is a term businesses may encounter when discussing caller ID authentication. The technical source used here describes the STIR identity mechanism for SIP; it does not explain the operational rules of SHAKEN. This article focuses on what that mechanism does and how to approach it as part of a broader voice security review.

What caller ID authentication addresses

The Session Initiation Protocol, or SIP, is used to set up communications sessions. RFC 8224 explains that baseline SIP security mechanisms are inadequate for cryptographically assuring the identity of the end users originating SIP requests, especially across administrative domains.^[1] Its response is a mechanism for securely identifying the originators of those requests.^[1]

In practical terms, the issue is not merely whether an identity appears in a call setup message. It is whether there is information a receiving system can use to assess an identity claim. A business considering caller ID authentication should therefore distinguish the displayed identity from the process used to validate it.

The supplied RFC describes STIR's SIP identity mechanism rather than a complete business implementation of STIR/SHAKEN. Details such as SHAKEN attestation categories, provider obligations and how particular devices present results are outside the supplied evidence. Ask your provider about those details rather than assuming that the RFC alone answers them.

How the SIP identity mechanism works

RFC 8224 defines a SIP header field that conveys a signature used to validate an identity and a reference to information about the signer.^[1] The document also describes authentication service and verifier behavior, including signature generation and validation.^[1]

A useful way to think about the exchange is as a sequence of distinct tasks:

1. An identity is associated with an originating SIP request.
2. The authentication process provides a signature for identity validation.
3. The SIP identity header carries the signature and a reference to information about the signer.
4. A verifier checks the signed identity information using the applicable verification process.

This is a conceptual outline of the mechanism described in RFC 8224, not a description of every system or call route. The distinction matters: the RFC sets out technical behavior, while the business needs to understand how its own calling arrangement handles that behavior.

A signature is evidence used in an identity check; it is not a substitute for all other business controls. For example, assessing whether a request made during a conversation is appropriate is a separate decision from checking information associated with a SIP request. Teams should treat those as different questions.

What an identity check can and cannot tell you

The narrow question is whether the identity information presented for a SIP request can be validated through the mechanism. That is different from deciding whether the conversation is legitimate, whether the caller's instructions are authorized, or whether the audio itself is private.

RFC 8224 also distinguishes protected request fields from unprotected request fields in its security considerations.^[1] That distinction is a reason to ask which information a particular check evaluates, rather than treating an identity result as a statement about every part of a call.

For an employee receiving a sensitive request, a practical response is to use an established internal process to check the request independently. For a voice administrator, the corresponding task is to understand what information is available for investigation and what it means. Neither task requires assuming that a single identity signal resolves every question about a call.

Caller identity and voice security are separate concerns

NIST's publication on VoIP introduces voice technology, its security challenges and potential countermeasures.^[2] That broader framing is useful because identity is only one topic in a voice security discussion. A review can consider how calls are set up, how voice traffic is protected and how staff respond to suspicious requests as separate workstreams.

For example, RFC 3711 describes Secure Real-time Transport Protocol, or SRTP, as a profile that can provide confidentiality, message authentication and replay protection for RTP and its control traffic.^[3] SIP identity validation and SRTP address different parts of the communications process: the former concerns an identity associated with a SIP request, while the latter concerns protections available for media and control traffic.

When discussing a deployment, ask which protections are configured and where they apply. The existence of a protocol in a standard does not establish how a particular business calling service is configured.

Questions to take to your provider

Use these questions to turn the technical distinction into an operational discussion:

• For outbound calls: How is identity information handled for our calling setup, and what should we provide to help establish the correct calling identity?
• For inbound calls: What identity-related information can our administrators or staff see, and how should they interpret it?
• For investigation: What information is available when an identity check produces an unexpected result, and which team should review it?
• For changes: What should we review when we change a calling workflow or the identity presented by an outbound call?
• For media protection: What protections are configured for voice traffic, and how are those distinct from identity validation?

These are questions for your specific setup, not claims about a provider's features. Record the answers alongside the relevant internal owner and revisit them when the calling arrangement changes.

Build a practical review process

Start by mapping the calling workflows that matter to your organization. Note who administers each workflow, what identity staff expect to present or see, and who can investigate an unexpected result. Keep the record focused on business responsibilities rather than assumptions about the underlying implementation.

Next, compare those expectations with the provider's explanation. If an answer is unclear, ask whether it concerns identity information in call setup, a result presented to a recipient, or protection of the voice traffic itself. Those distinctions make it easier to route an issue to the right people.

Finally, make the procedure usable by staff. Explain whom to contact internally when a call or request seems unusual, and identify the separate process for approving sensitive actions. Caller ID authentication is most useful in a review when its purpose and limits are understood alongside those business procedures.

This article is general information and is not legal or compliance advice. Confirm the requirements that apply to your organization with qualified legal or compliance advisers.

Sources

1. RFC 8224: Authenticated Identity Management in SIP
2. SP 800-58: Security Considerations for Voice Over IP Systems
3. RFC 3711: The Secure Real-time Transport Protocol (SRTP)

Contact OttoCall to discuss your business calling setup.

This article is general information, not legal, compliance or financial advice. Check current rules and provider terms for your situation.