STIR/SHAKEN Attestation Explained — What A, B, and C Mean for Your Outbound Answer Rates

Quick answer: Every outbound call on US networks carries a STIR/SHAKEN attestation level — A (full), B (partial), or C (gateway) — that downstream carriers use to decide whether the recipient sees "caller verified" or "Spam Likely." On Devotel Orbit, the level your numbers attest at is determined by ownership: numbers your organization owns through Orbit attest at A, leased pool numbers and numbers covered by a delegate certificate cap at B, and anything else falls to C. Because Orbit records your tenant-owned attestation policy (target_attestation, downgrade_handling, inbound_min_verification, flag_unverified_inbound) and exposes a posture snapshot over it, you can see exactly which of your originating numbers meet your target and which are stuck below it.

This is the buyer-facing walkthrough of the mechanics documented in the STIR/SHAKEN attestation docs. If attestation posture is one of the questions on your outbound-voice checklist, this is the page that answers it.

What A, B, and C actually assert

The attestation levels come from ATIS-1000074, the industry standard that defines how a provider signs a call. A level asserts two things: whether the originating provider authenticated the customer, and whether it verified that customer's right to use the calling number.

Carriers weight these levels very differently. A- and B-attested calls are eligible for "caller verified" treatment; C-attested calls are the traffic carriers routinely label "Spam Likely." Industry field data keeps showing the same pattern — answer rates on A-attested traffic run dramatically higher than on C-attested traffic — which is why attestation level is the single biggest caller-identity lever an outbound program has.

One more piece of context that matters when you compare providers: Orbit never signs a PASSporT itself. Orbit computes the level from your ownership, lease, and delegate-certificate records; Devotel's wholesale softswitch — the carrier-of-record network every outbound leg terminates on — holds the signing certificate and cryptographically signs at exactly that level. It will never sign higher than the level the platform attests.

Why ownership beats delegate certificates

The path to A attestation is ownership, full stop.

• Owned numbers → A. A number your organization purchased or ported into Orbit — active and billed to your org — attests at A because number authorization is provider-verified by construction.
• Leased or delegate-certificate numbers → B (maximum). A leased pool number with an active assignment, or a number covered by an ATIS-1000092 delegate certificate you registered, attests at B. The ceiling is deliberate: a self-registered certificate is not something Orbit cryptographically chain-validates, so treating it as A would let anyone spoof full attestation for arbitrary numbers.
• Everything else → C. A caller ID that cannot be attributed to your org, or a platform fallback number, attests at C — the traffic that "Spam Likely" labels feed on.

If your outbound traffic runs on external caller IDs or pool numbers today, no policy setting or provider negotiation moves them to A. Purchasing or porting the numbers into Orbit is the only route, and it is a one-time ownership play rather than an ongoing negotiation.

The attestation policy you own

Beyond per-number ownership, Orbit keeps an org-level attestation policy — a declared target for your outbound traffic plus the inbound verification floor your fraud posture is measured against. Four fields, all yours to set:

Two endpoints cover it: GET /api/v1/compliance/attestation/policy reads the policy (an org that never set one gets the safe defaults), and PUT /api/v1/compliance/attestation/policy patches it — absent fields keep their current value, so you can change just the target level without touching the rest.

One thing to hold onto: the policy is reporting and intent, not a gate. Setting target A while your traffic runs on leased numbers changes nothing about how calls are handled — it makes your posture snapshot start reporting those numbers as below target, which is exactly the visibility you need to fix them. Raising the actual level is always the ownership move, not a PUT.

Reading your attestation posture

GET /api/v1/compliance/attestation/posture answers two questions at once: which of your originating numbers meet your target, and how inbound verification looks against your floor.

• `originating.numbers[]` lists each originating number with the level it actually attests at — owned → A, leased → B — and a meets_target verdict against your target_attestation. The summary aggregates meeting_target and below_target counts, so one read tells you where the gap lives.
• `inbound.summary` classifies the calls that arrived on your DIDs over the trailing 30-day window: signed calls at or above your inbound_min_verification floor count as verified; signed-below-floor and off-net calls count as unverified; failed and unsigned calls count as spoof_risk when flag_unverified_inbound is on. verified_rate is the verified share — null, not zero, when there was no inbound traffic in the window.

Both reads are scoped to your organization, and because posture is recomputed against live assignments, a released DID never drags the prior owner's verification history into your numbers.

A playbook for raising answer rates

Attestation is the biggest lever on answer rates, but it is not the only one. The order of operations that works:

1. Own your caller IDs. Move outbound traffic onto numbers your org owns through Orbit — the one move that takes a number from C or B to A.
2. Set the policy target. PUT /attestation/policy with target_attestation: "A" and downgrade_handling: "alert" so below-target numbers surface to your team instead of sitting silent.
3. Audit the posture snapshot weekly. GET /attestation/posture tells you which originating numbers still attest below the A target; every leased number on that list is an ownership decision waiting to happen.
4. Register delegate certificates where ownership genuinely isn't possible. Verified external caller IDs and hosted numbers you legitimately control move from C to B — the remediation stops there by design.
5. Layer CNAM and branded calling on top. CNAM names the number carriers display; on A-attested calls, registered US carriers can render your verified brand name, logo, and reason-for-call (Rich Call Data, ATIS-1000095). Attestation proves the number; CNAM and RCD name it.

Answering these five in order is the difference between an outbound program that argues with "Spam Likely" labels and one that never earns them.

Frequently asked questions

Is attestation the same as branded caller ID?

No — they stack. Attestation (STIR/SHAKEN) cryptographically proves the calling number. CNAM registers the calling name carriers display alongside it, and Rich Call Data adds the verified brand name, logo, and reason-for-call on carriers where your registration is complete. Attestation is the foundation: branded calling only renders on A-attested calls, and a brand on a C-attested call is a label on traffic the carrier already distrusts.

Can a delegate certificate get me to A attestation?

Never, on Orbit. A registered ATIS-1000092 delegate certificate raises a number you don't own through Orbit from C to B, and that ceiling is deliberate. Orbit does not chain-validate the certificate, so count it as what it is — legitimate remediation for numbers you genuinely control, capped at "partial" because number authorization is not provider-verified. Full (A) attestation stays reserved for numbers owned through Orbit.

Does my attestation policy change how calls are signed?

No. The policy is a declared posture, not a gate — it drives how Orbit classifies and reports your traffic (what counts as meeting your target, what counts as spoof-risk inbound). It does not raise what gets signed, reroute a call, or block one at dial time. Devotel's wholesale softswitch signs at exactly the level Orbit attests, and no policy value moves that level.

What about inbound attestation — what do I do with it?

Inbound posture is the same policy's second half. Orbit parses the attestation result off every inbound PSTN call (the pre-verified Verstat value covers the overwhelming majority of traffic), and your inbound_min_verification floor decides what counts as verified in your fraud posture. With flag_unverified_inbound on, failed-signature and unsigned calls are classified as spoof-risk so your team sees the threat surface rather than a shrug. A per-DID minimum-attestation floor can also reject inbound calls below a level you choose — off by default, and yours to set.

If my posture shows leased numbers below target, what's the fix?

Ownership, not configuration. Purchase or port the numbers into Orbit, move traffic onto the owned DIDs, and re-read the posture snapshot — the below_target gap closes because ownership is the only thing that moves a number to A. No PUT on the policy endpoint can do it for you.

The takeaway

Attestation level is decided by one question — does your provider verify your right to use the calling number? — and on Devotel Orbit that question has exactly one answer that reaches A: own the number. The tenant-owned controls around it (target level, downgrade handling, inbound floor, spoof-risk flagging) exist to make the gap visible and the remediation measurable, and the posture snapshot closes the loop. Run the playbook once, keep the weekly posture read on the calendar, and attestation stops being a label carrier analytics hand you — it becomes a number you own.

The full mechanics — the signing split, the endpoint schemas, the inbound parsing table, and the ITG traceback workflow that signed traffic obliges you to answer — live in the STIR/SHAKEN attestation docs.