Caller ID authentication proves the carrier. It says nothing about who is speaking.

STIR and SHAKEN did what they were designed to do: they made it hard to put a number on a call that you have no right to use. They were never designed to say anything about the person speaking, and the fraud has moved to exactly that gap. This is a walk through the mechanism, the attestation levels, and the one change that takes authorization off the phone call altogether.

It is a Tuesday afternoon in a mid-size bank's contact centre. An agent, eleven months into the job and rated well on handle time, picks up a call. The desktop shows a green tick and the words Verified caller. The number matches the mobile on file for a customer with a decent balance and a twenty year relationship.

The voice is right. Not close, right. The cadence, the slight hesitation before numbers, the way the customer clears their throat before saying their own surname. The agent has never spoken to this person before, but the voice sounds like the voice of someone who has been a customer for twenty years, because it was assembled from a podcast interview the real customer gave in 2023.

The caller wants to update the email address on the account. Not the phone number, which would look suspicious, and not a payment, which would trigger a hold. Just the email. The agent asks the knowledge based questions, and the caller answers them, because the answers were in a breach corpus that has been circulating for six years. The agent makes the change.

Four days later, a password reset is requested. It goes to the new email address. Nobody at the bank has done anything wrong according to any procedure written down anywhere, and the green tick was accurate the entire time. That is the part worth sitting with. The tick was not fooled. The tick answered a different question from the one the agent thought it was answering.

What does STIR/SHAKEN actually do?

Start with the problem it was built for, because the framework is genuinely good at that problem and any honest reading has to say so first.

For most of the telephone network's history, the calling number was a claim. A call arrived carrying a number in a header field, and nothing checked whether the party placing it had any relationship with that number. This was an inheritance rather than an oversight: the signalling systems were designed for a world of a few hundred trusted operators, and then the world stopped looking like that. Voice over IP made origination cheap and made the calling number a field in a configuration file. Two decades of spoofed calls followed, from nuisance robocalls up to targeted impersonation of banks and government agencies.

STIR is the set of IETF standards that fixes the claim by signing it. SHAKEN is the deployment profile that tells North American carriers how to run it. Together they turn "here is a number" into "here is a number, and a named carrier has cryptographically asserted something about my right to use it."

The PASSporT, in plain terms

When a call is placed, the originating provider builds a small signed token called a PASSporT, defined in RFC 8225. It is a JSON Web Token. It is signed with a private key whose certificate chains up to an authority approved for the ecosystem, under the credential rules in RFC 8226. The token travels in a SIP header, defined in RFC 8224, and the terminating provider verifies the signature and the certificate chain before the phone rings.

Conceptually the payload holds about what you would expect:

{
  "attest": "A",
  "orig":   { "tn": "18005550199" },
  "dest":   { "tn": ["12025550143"] },
  "iat":    1790000000,
  "origid": "8bf7a2c1-4d1e-4b09-9d55-8a3f0c2d1e77"
}

Read that payload slowly, because everything in this post follows from what is in it and what is not. There is a calling number. There is a called number. There is a timestamp, which stops the token being replayed onto a different call next week. There is an origination identifier, which lets a carrier trace the call back to a specific customer or trunk during a traceback investigation. And there is an attestation level, which is the interesting field.

There is no name. There is no person. There is no hash of the audio, and there could not be, because the token is created before anybody has said anything. The signature covers call metadata at the moment of origination. That is the whole contract.

The three attestation levels, and what each one means

The attest claim carries one of three values, and the difference between them is entirely about the originating carrier's relationship with its own customer.

A, full attestation. The provider has an authenticated relationship with the customer placing the call, and has established that the customer is authorized to use the calling number. This is the green tick case.

B, partial attestation. The provider has an authenticated relationship with the customer, but has not established that the customer is entitled to that particular number. Common where a business routes its own numbers through a provider that did not issue them.

C, gateway attestation. The provider put the call onto the network but has no relationship with whoever initiated it. Typical for traffic arriving from an international gateway.

Now put those definitions next to the question a contact centre agent is actually asking, which is "is this my customer". None of the three answers it. They are statements about a carrier's confidence in a number's provenance. The framework is not being modest, it is being precise.

Why was it built, and what did it fix?

In the United States the TRACED Act of 2019 directed the Federal Communications Commission to require implementation, and the Commission set deadlines that pushed the major voice providers to deploy authentication in their IP networks, with a Robocall Mitigation Database to catch the rest. The FCC maintains its call authentication material publicly. Other regulators have pursued equivalent work, including Ofcom's programme on calling line identification authentication in the United Kingdom.

The effect on the crudest attacks was real. Blanket neighbour spoofing, where a robocaller wears a number from your own area code that belongs to somebody else entirely, is a much worse business than it was, because the traffic either fails verification or carries an attestation that terminating carriers can act on. Traceback, the process of walking a call back through the chain of providers to find who put it on the network, went from a months long favour-based exercise to something with an identifier attached to it. Enforcement depends on that.

So the honest summary is: the framework works, at what it targets. The trouble is that the fraud that costs the most money moved somewhere else, and the label the framework produces is being read as an answer to a question it never asked.

Why does a deepfake call still show as verified?

Two reasons, and they are worth separating because they fail differently.

The number is a credential of the account, not of the person

Full attestation means a carrier confirmed that its customer is entitled to use a number. A fraudster who opens an account with a compliant voice provider, passes whatever onboarding that provider runs, and is assigned a number, is a customer entitled to use that number. Every call they place is eligible for full attestation, forever, until somebody complains and the account is closed.

This is not a bug. Read the definition again: the provider authenticated the customer and established their right to use the number. Both of those things are true. The framework has done its job perfectly and delivered a green tick to a criminal, because the framework's job is to bind numbers to accounts, and the criminal has an account.

The analogy that lands with most people is a signed courier envelope. The courier verifies who handed over the package and can prove the chain of custody. The seal is genuine, the paperwork is genuine, and the courier will testify to all of it. None of that tells you whether the letter inside is a forgery. You have proof about transport and none about content, and if you have been trained to read the seal as a sign the letter is trustworthy, the seal has made you easier to defraud rather than harder.

Nothing in the framework touches the audio

The PASSporT is built before the call connects. There is no point in the protocol where anybody signs the speech, and no defined mechanism by which they could, because the speech does not exist yet and is not a thing the signalling layer sees. Voice cloning is now cheap enough and good enough that a short sample from a conference talk, a voicemail greeting, or a social video is sufficient for a convincing impersonation, and none of that interacts with call authentication at any layer.

So a legitimately originated call carrying a synthetic voice verifies exactly as well as a legitimately originated call carrying a real one. It has to. The two are identical everywhere the framework looks.

What does each attestation level actually establish?

The last row is the only one that answers the question the agent needed answered. Every other row answers a question about the channel.

Is caller ID authentication evidence of identity?

It is evidence about routing. Treating it as evidence about identity is a category error, and it is an expensive one because it is embedded in interface design. A green tick and the word Verified next to a caller's name does not read to a stressed human on their fortieth call of the shift as "the carrier vouches for number provenance". It reads as "this is fine".

This is the same shape as several other failures. Passkeys authenticate a login and are read as authorizing everything the session goes on to do. Zero trust evaluates device posture and is read as establishing intent. In each case a control does its narrow job impeccably, and the organisation quietly promotes the result into a broader claim nobody made. We catalogue that pattern in the Identity Failure Map.

The costs are not hypothetical. The FBI's Internet Crime Complaint Center reported that people over 60 filed more than 201,000 complaints in 2025 with losses of roughly 7.7 billion dollars, including around 352 million dollars tied to schemes using artificial intelligence, a category that includes cloned voices (FBI IC3 2025 Internet Crime Report). Trade surveys of contact centre leaders published over the last two years have repeatedly found large majorities ranking voice deepfakes among their top threats and majorities reporting low confidence in their ability to detect them; treat those as self-reported survey findings from a self-selecting group rather than measurements, because that is what they are.

On enforcement, the Federal Communications Commission issued a six million dollar forfeiture against the political consultant behind the 2024 New Hampshire robocalls that used a cloned presidential voice, and separately settled with the voice service provider that put the traffic on the network. Reporting described the attestation applied to that campaign as one of the issues at stake, which is worth noting rather than asserting, because accounts of the attestation assignment differ. The Commission also ruled in February 2024 that calls using AI-generated voices are artificial under the Telephone Consumer Protection Act, which made the practice unlawful without needing to prove anything about signalling.

What about Rich Call Data and branded calling?

The natural next question, and a fair one. Extensions to the framework allow an originating provider to carry additional signed information about the caller, such as a business name and logo, so that a call from a hospital or a bank can display as that organisation rather than as a number. Branded calling products build on this.

This is a real improvement and worth deploying if you are an enterprise that calls customers. It attacks impersonation of institutions, which is a large and painful problem. A caller claiming to be your bank has a harder time when your bank's calls display with verified branding and theirs do not.

What it does not do is help in the direction that matters for the scenario at the top of this post. Rich Call Data describes the enterprise placing the call. The contact centre's problem is inbound: a consumer is calling in, and the question is whether that consumer is the account holder. No amount of signed information about the caller's carrier or brand speaks to that, and a consumer does not have an enterprise identity to carry.

The direction of travel is good and the gap is structural. Signed call metadata will keep getting richer, and it will keep describing the origination of the call rather than the authority of the person on it.

How should a contact centre authorize a change requested by phone?

The answer that follows from everything above is uncomfortable and simple: do not authorize consequential changes on the call at all. Use the call for conversation, diagnosis, and service, which is what it is good for, and move the authorization onto a channel the caller does not control.

Concretely, the agent desktop stops being the place where a change is committed and becomes the place where a change is proposed. The agent gathers what the customer wants, and the system emits a signed change request to the customer's enrolled device. The customer sees the actual change on their own screen, approves it with the gesture that unlocks their phone, and the receipt comes back. If it does not come back, the change does not happen.

The payload, and what it is for

{
  "action":    "account.contact.update",
  "subject":   "cust_8812",
  "change":    { "field": "email",
                 "from_masked": "j***@old.example",
                 "to_masked":   "b***@new.example" },
  "channel":   "voice_inbound",
  "call_ref":  "ctr-2026-09-29-113",
  "displayed": "sha256:9f2c41d0ab7e...",
  "not_after": "2026-09-29T11:41:00Z"
}

Four fields do real work. The change object is what the customer reads on their own device, so the thing they approve is the thing that happens rather than a summary an agent typed. The displayed hash covers the exact text rendered, so a dispute six months later is settled by recomputation rather than by whose recollection is better. The not_after field keeps the request short lived, because a request that expires in four minutes cannot be banked for later. The call_ref ties the receipt to the interaction record without putting anything sensitive in it.

Verification on the way back is unremarkable, which is the point:

receipt = ctr.await_signature(request_id, timeout="4m")

if not receipt:
    agent.show("No approval received. Change not applied.")
    return

assert verify_ed25519(receipt.signature,
                      receipt.payload_hash,
                      published_key)          # no callback needed
assert receipt.payload_hash == sha256(canonical(payload))
assert receipt.subject      == "cust_8812"

apply_change(payload["change"])
audit.attach(receipt)                          # offline-verifiable evidence

The receipt verifies against a published key with no call home, which means the bank's auditor, its insurer, and if it ever comes to it a court can check it without asking the bank or us to vouch for anything. That property is doing more work than it appears to: it converts an internal log, which is a record an organisation wrote about itself, into an artifact a third party can independently confirm.

The mechanics of this control in the voice channel are covered in more depth in our piece on contact centre voice deepfakes, and the same reasoning applied to payment instructions rather than account changes is in why callback verification fails. The signing demo shows the customer side of the flow, and the integration shape is in the docs.

What does this feel like for the customer?

Better than the current experience, which is the part that surprises people. Today a customer calling to change their email answers questions about a car loan they closed in 2019 and a street they lived on as a student, and then waits while the agent decides whether to believe them. Legitimate customers fail that gauntlet regularly and end up at a branch.

Under the signed model the agent says "I have sent that to your phone, tap approve when you see it", the customer looks at a screen that says exactly what is being changed, and taps. It takes seconds and it removes the interrogation entirely. For the fraudster it is not harder, it is impossible, because they do not have the device and no amount of correct answers about a 2019 car loan produces a signature.

The customers this does not serve are the ones without a smartphone, without their phone at that moment, or unable to use it. That population is real and disproportionately elderly, which is exactly the population most targeted by voice fraud. A design that strands them has failed. The correct answer is a staffed fallback treated as a normal path with its own controls, such as a verified branch visit or a signed approval from a pre-designated trusted contact, and not a shrug.

Honest limits

• It does not stop a coerced customer. If somebody talks a real account holder into approving a real change, the signature is valid and the change was authorized. This control binds intent, not judgment. Scams that work by persuading the victim rather than impersonating them are a different problem, and we say so plainly in the piece on reimbursement.
• Enrolment is the weak point. Everything rests on the keypair belonging to the right human. If an attacker is present at enrolment, they own the account. Enrolment deserves more scrutiny than any subsequent action, and pushing customers to register two devices matters more than most teams expect.
• Device compromise defeats it. A phone in an attacker's hands signs whatever they approve. This raises cost enormously compared with a phone call, and it does not create an unbreakable control.
• It does not improve the call. Voice fraud aimed at information rather than changes, such as talking an agent into confirming a balance, is unaffected. Restricting what agents may disclose is a separate and still necessary exercise.
• Coverage takes time. Until enrolment is broad, most calls fall back to the old procedure, so the interim policy has to be explicit about which actions simply wait.

What to do this week

1. Write down every action an agent can complete on voice authorization alone. Contact details, address, beneficiary, card reissue, credential reset, limit changes, account closure. Most teams have never enumerated this and are surprised by the length.
2. Rank that list by irreversibility, not by dollar value. An email change moves no money and unlocks everything. It should be near the top.
3. Relabel the caller verification indicator on the agent desktop. Change "Verified caller" to something that describes what it means, such as "Number authenticated by carrier". This costs a sprint of front end work and immediately stops the interface from making a claim the data does not support.
4. Pick the top three actions and route them to a device signature. Not all of them. Three.
5. Retire knowledge based questions for those three actions. Keep them for low-consequence servicing if you must, but stop treating breach-corpus data as an authenticator.
6. Design the fallback before you launch. Decide what happens for customers who cannot sign, staff it, and measure how often it is used.
7. Instrument abandonment. If legitimate customers drop out at the signature step, you have a usability problem to fix, not a reason to abandon the control.
8. Tell your insurer. Controls that deterministically prevent a loss category are worth raising at renewal, and the receipt is the evidence that the control ran.

Frequently asked questions

Does STIR/SHAKEN stop caller ID spoofing? It stops one kind. Placing a call carrying a number you have no relationship with is much harder, because the call either fails verification or carries an attestation that terminating carriers can act on. It does not stop a fraudster who lawfully obtains a number from a compliant provider, because that person genuinely is entitled to use it and receives full attestation on every call.

What does attestation level A mean? Full attestation means the originating provider has an authenticated relationship with the customer placing the call and has established that the customer is authorized to use the calling number. It is a statement about the carrier's confidence in the number's provenance. It says nothing about who is speaking, whether they are the account holder, or whether anyone authorized anything.

Can a phone call be used to verify someone's identity? For anything consequential, no. Voice can be cloned from short public samples, knowledge based questions are answerable from breach data, and caller ID authentication describes routing rather than people. A call is an excellent channel for conversation and a poor one for authorization. Move the authorization to a channel the caller does not control.

Does Rich Call Data or branded calling fix this? It helps in the outbound direction, by letting an organisation's calls display verified branding so impersonation of that organisation is harder. It does not help inbound, where a contact centre needs to know whether the consumer calling in is the account holder. Consumers do not carry an enterprise identity, so the extension cannot speak to their authority.

How should a bank authorize a change requested over the phone? Treat the call as a request rather than an instruction. The agent proposes the change, the system sends the exact change to the customer's enrolled device, the customer approves it there, and the resulting receipt is stored with the interaction. If no receipt arrives, the change does not happen. Provide a staffed fallback for customers who cannot sign.

Is voice biometrics a reasonable alternative? It is a detector, and detectors lose ground as generation improves. It also creates a voiceprint database, which is biometric data under laws including the Illinois Biometric Information Privacy Act and the GDPR, so it carries retention and litigation exposure that a signature over an action does not. Detection can usefully triage; it should not be the last line before an irreversible change.

Sources

1. RFC 8224, Authenticated Identity Management in the Session Initiation Protocol. https://www.rfc-editor.org/rfc/rfc8224
2. RFC 8225, PASSporT: Personal Assertion Token. https://www.rfc-editor.org/rfc/rfc8225
3. RFC 8226, Secure Telephone Identity Credentials: Certificates. https://www.rfc-editor.org/rfc/rfc8226
4. ATIS, SHAKEN deployment specifications (ATIS-1000074 and related documents). https://www.atis.org/
5. Federal Communications Commission, call authentication and STIR/SHAKEN. https://www.fcc.gov/call-authentication
6. Federal Communications Commission, robocalls and enforcement. https://www.fcc.gov/robocalls
7. FBI Internet Crime Complaint Center, annual Internet Crime Reports. https://www.ic3.gov/AnnualReport/Reports
8. Ofcom, work on calling line identification authentication. https://www.ofcom.org.uk/

The carrier can prove it had the right to hand you the envelope. Nobody signed the letter inside.