When the phone rings at a front desk and the screen shows a small checkmark beside the number, what has anyone actually promised? The answer sits in a joint standard most of the people answering those calls will never read, and it is narrower than the checkmark suggests.
This note reads the attestation levels in SHAKEN as written, then translates each one for the person picking up the handset. It sits in our standards hub, alongside the other open specifications we read clause by clause.
Where The Definitions Live
The three levels are defined in ATIS-1000074, the SHAKEN framework published jointly by ATIS and the SIP Forum. The version we read is ATIS-1000074.v003, whose cover page reads "Approved August 16, 2022" (checked 1 October 2026).
The IETF side of the work is RFC 8588, which adds the "attest" claim to the signed token a carrier attaches to a call. That RFC states the claim "can be one of the following three values: 'A', 'B', or 'C'" and points back to ATIS-1000074 for what each value means (checked 1 October 2026).
The regulatory side comes from the FCC. In a March 31, 2020 news release, the Commission said its order "requires all originating and terminating voice service providers to implement STIR/SHAKEN in the Internet Protocol (IP) portions of their networks by June 30, 2021" (checked 1 October 2026).
Keep in mind that the FCC release describes the purpose in one line: STIR/SHAKEN "enables phone companies to verify that the caller ID information transmitted with a call matches the caller's phone number." Everything below is a reading of how far that verification reaches, and where it stops.
What The Originating Carrier Is Signing
Before the levels make sense, it helps to see the object they live in. When a call starts on an IP network, the originating carrier can sign a token called a PASSporT and carry it in the SIP Identity header, which RFC 8588 notes is the header field defined in RFC 8224.
The example payload printed in ATIS-1000074.v003 looks like this:
{
"attest": "A",
"dest": { "tn": ["12125551213"] },
"iat": 1471375418,
"orig": { "tn": "12155551212" },
"origid": "123e4567-e89b-12d3-a456-426655440000"
}
Read it field by field and the scope is plain. There is a calling number, a called number, a timestamp, an origination identifier the spec ties to traceback, and a single letter.
Note that nothing in that payload describes the caller as an entity. There is no field for a name, a purpose, a business category, or whether a human or software placed the call.
Full Attestation (A), Read As Written
Section 5.2.4 of ATIS-1000074.v003 says that for Full Attestation, "the signing service provider shall satisfy all of the following conditions." Those conditions are:
- Origination. The provider "is responsible for the origination of the call onto the IP-based service provider voice network."
- Customer relationship. The provider "has a direct authenticated relationship with the customer and can identify the customer."
- Number association. The provider "has established a verified association with the telephone number used for the call."
The spec then adds, in a note, that the provider is asserting its customer "can 'legitimately' use the TN that appears as the calling party." What counts as legitimate is left to the carrier: the same note says "it is up to service provider policy to decide what constitutes 'legitimate right to assert a TN.'"
For the person at the desk, an A means one thing in plain terms. The carrier that put this call on the network knows who its customer is and has satisfied its own policy that this customer may use this number.
Partial Attestation (B), Read As Written
Partial Attestation keeps the first two conditions and drops the third. Per section 5.2.4, the provider originated the call and "can identify the customer," but "has NOT established a verified association with the telephone number being used for the call" — the capitals are in the standard.
The note under B explains why the level exists at all. By signing B, the provider "attests that it can trace the origination of the call to a customer for traceback or policy enforcement purposes."
For the desk, a B reads as follows. The carrier knows which of its customers sent the call, but has not confirmed that the number on the screen belongs to that customer.
A B can follow from ordinary setups, such as a customer presenting a number the signing carrier did not assign and has not yet verified. That said, the standard does not enumerate those situations, so a B by itself does not tell you which reason applies.
Gateway Attestation (C), Read As Written
Gateway Attestation is the thinnest assertion. Section 5.2.4 requires only that the signing provider "has no relationship with the originator of the call (e.g., international gateways)."
The spec widens that in a note: C "may also be used when the STI-AS does not have sufficient information for determining that an 'A' or 'B' attestation level applies even when the call was received at a customer interface." RFC 8588 describes it in the same spirit, as "the lowest level of attestation," representing a provider "receiving a call from a telephone gateway that does not support PASSporT or STI."
For the desk, a C says the call entered this carrier's IP network at a known point. It says nothing about who placed it or whether the number is theirs.
The Three Levels Side By Side
All of the above reduces to three questions the signing carrier answers. Here is how each level answers them, using only the conditions in ATIS-1000074.v003 section 5.2.4:
- A — Full. The carrier originated the call on its IP network, can identify its customer, and verified that the customer may use the number.
- B — Partial. The carrier originated the call and can identify its customer, but did not verify the customer's right to the number.
- C — Gateway. The carrier is only the entry point and has no relationship with the originator, so neither the customer nor the number is vouched for.
Overall, the levels grade one carrier's relationship to two things: the caller as a customer account, and the number on the screen. They grade nothing else.
What No Level Asserts
This is the part a front desk most needs, and the standard is consistent about it. No attestation level asserts any of the following:
- Whether the caller is a person or software. The payload has no field for it, and the conditions in section 5.2.4 are about accounts and numbers, not about who or what is speaking.
- What the caller wants. A fully attested call can be a booking, a vendor, a patient, a debt collector, or a scam run from a legitimately held number.
- Whether the call is lawful or welcome. The FCC release pairs STIR/SHAKEN with "call analytics" for that judgment, which tells you the signature alone was never meant to make it.
- Who the individual on the line is. The carrier identifies its customer account, which may be an enterprise, a contact center, or a platform placing calls for many others.
The last point matters for agent traffic. An AI agent placing calls through a voice platform can arrive with an A, because the platform's carrier knows the platform and the platform holds the number; we covered what else that line carries in what an AI agent phone call actually carries.
In fact, the same gap appears on the web, where a signed HTTP request proves which key signed it rather than what the agent intends. Our reading of what a signed agent request looks like lands in the same place: identity of the sender is one layer, and purpose is another.
Where A Business Actually Sees The Result
The standard says less about display than most people assume. A business meets attestation in roughly three places, and each depends on carrier choices outside the spec.
On a mobile carrier's verified-call display
Wireless carriers render verification results their own way, with labels and icons that differ by carrier and handset. ATIS-1000074.v003 does not define what a handset shows, and we did not find a primary source that settles a common display across carriers, so we stop there.
In a SIP header on a business line
For businesses on SIP trunks or hosted PBX platforms, the result can arrive as a header. The verification clauses of ATIS-1000074.v003 (section 5.3) say the terminating network "conveys the verification result to the called user by including a tel URI 'verstat' parameter" in the From and/or P-Asserted-Identity header, as defined in 3GPP TS 24.229.
The same section sets a rule that surprises people. A verstat of "TN-Validation-Passed" goes to the endpoint "only if verification passes" and either the level is A, or the attestation level itself is also included in the INVITE.
Put differently, if the call was B or C and the terminating carrier does not pass the letter along, the spec says it "shall either set the 'verstat' value in the INVITE request to 'No-TN-Validation' or shall omit the 'verstat' parameter," based on local policy. A business line can therefore see a valid B call arrive looking no different from an unsigned one.
When the business's own carrier passes it through
Whether the raw Identity header, the attestation letter, or only verstat reaches a business phone system is the terminating carrier's decision. Note that the standard leaves this to local policy, so the answer is a question for the carrier or trunk provider, not something the spec settles.
Many Calls Arrive With No Attestation At All
A missing checkmark is common, and it is not a verdict. STIR/SHAKEN rides on SIP, so a call that crosses a non-IP segment can lose its Identity header along the way.
The FCC's 2020 release says as much in its own terms. It covers the IP portions of networks, and the same release describes a further rulemaking on "requirements to promote caller ID authentication on voice networks that do not rely on IP technology."
Unsigned calls can also come from providers working under the deadline extensions the same release describes for small voice service providers. We did not find a primary source that publishes a current, network-wide share of unsigned calls reaching businesses, so we will not estimate one.
Reading The Letter At The Desk
Given all of the above, here is how the letter translates for someone answering the phone:
- A — the originating carrier knows its customer and stands behind that customer's use of this number. Treat it as a stronger signal that the caller ID is not spoofed, and nothing more.
- B — the carrier knows which customer sent the call but did not vouch for the number. The call may be fully legitimate; the number on screen is simply unconfirmed.
- C — the call entered a carrier at a gateway. The number on screen is unverified, and the caller is unknown to the signer.
- No result — the path lost or never carried a signature. That describes the route, not the caller.
We do not recommend blocking or auto-rejecting calls on an attestation level. The standard grades a carrier relationship, and the people and systems who call a front desk legitimately arrive with every one of those letters.
The better use of the letter is routing. A front desk can treat the level as one input among several, alongside what the caller says and asks for, which is the approach behind our three kinds of caller reading and the wider channels hub.
What We Measure, And Where
Attestation is one of the signals we read when we look at how agents and people reach a business across phone, web, chat, and forms. The current figures live on the Aethelforge Index, and we link there rather than restate them here.
If you are mapping what your own phone line receives and want to know which of these signals actually reaches your desk, start with your trunk or carrier's documentation on Identity and verstat pass-through. Then compare it against the definitions above — the gap between the two is usually where the confusion lives.