Troubleshooting: STIR/SHAKEN attestation downgrade

An attestation downgrade is the quiet answer-rate failure: the call connects, the routing is clean, and no error is returned anywhere — but the call leaves signed at C (gateway) instead of A or B, and downstream carriers label it “Spam Likely.” Answer rates collapse and the error-code catalog has nothing to point at, because a downgrade is not a refusal: there is no structured STIR/SHAKEN error code — the call still dispatches, signed at a weaker level. This page works the five root causes that produce a downgrade and the fix run for each. For what the attestation levels mean and where signing happens, see STIR/SHAKEN attestation; this page starts where that one ends — at a call that attests lower than you expected.

A downgrade never blocks a call. Attestation resolution fails open to C rather than failing the dial, and the policy flags below — target level, downgrade handling, certificate status — are reporting surfaces: they flag the gap, they do not gate traffic. Do not look for the failure in a blocked- call log.

Symptoms

Outbound calls arrive labeled “Spam Likely” on downstream carriers even though your dialing practices, traffic volume, and caller IDs haven’t changed.
Answer-rate drop on outbound campaigns with no other change in caller ID, list quality, or time of day — the signature of a level that silently fell from A or B to C.
Calls sign at C on numbers you used to reach A or B on — visible per call on the call record (the parsed attestation result is stored on every call), or across the org in the Attestation posture page.
Rich Call Data (branded calling) no longer renders on handsets that showed it before — often the same downgrade from the recipient’s side: RCD only attaches to A-attested calls.

Reads: measuring the downgrade before fixing it

Two reads tell you the downgrade is real and which numbers it covers. A posture snapshot is fine-grained enough to name the specific number — don’t work the fix runs below blind.

Originating: which numbers attest below your target

GET /compliance/attestation/posture lists every originating number with the level calls from it actually attest at, and compares that against your target_attestation:

curl "https://api.orbit.devotel.io/api/v1/compliance/attestation/posture" \
  -H "Authorization: Bearer $ORBIT_API_KEY"

{
  "data": {
    "policy": {
      "target_attestation": "A",
      "downgrade_handling": "alert",
      "inbound_min_verification": "B",
      "flag_unverified_inbound": true,
      "updated_at": "2026-08-20T14:03:11.000Z"
    },
    "originating": {
      "summary": {
        "total": 12,
        "meeting_target": 9,
        "below_target": 3,
        "by_level": { "A": 9, "B": 3, "C": 0 }
      },
      "numbers": [
        { "phone_number": "+14155550100", "source": "owned", "attestation": "A", "meets_target": true },
        { "phone_number": "+14155550777", "source": "leased", "attestation": "B", "meets_target": false }
      ],
      "numbers_truncated": false
    },
    "inbound": {
      "window_days": 30,
      "window_start": "2026-07-27T10:15:00.000Z",
      "window_end": "2026-08-26T10:15:00.000Z",
      "summary": {
        "total": 1840,
        "verified": 1712,
        "unverified": 96,
        "spoof_risk": 32,
        "verified_rate": 0.9304
      }
    }
  }
}

How to read it for a downgrade:

originating.numbers[] — each originating number with the level it attests at (owned → A, leased → B) and meets_target against your declared target. A row with meets_target: false is a downgrade on that number; originating.summary.below_target counts them. numbers_truncated tells you when the 500-number list cap truncated the evidence.
policy.target_attestation — what you intend. If it’s A and your traffic runs on leased pool numbers (B) or BYON numbers (C), the below-target count lights up — that is the surface flagging the gap, not a blocked call.

Inbound: verification summary against your floor

The same snapshot carries the inbound half: inbound.summary classifies the last 30 days of calls arriving on your DIDs against your inbound_min_verification floor — verified share, spoof-risk count, and the verified_rate (or null, not zero, when the window had no inbound traffic). A drop in verified_rate or a spike in spoof_risk is the inbound-side signal worth reading before tuning the floor.

Root causes and fixes

Work the causes in order — the top two produce the spam-likely symptom on your own traffic; the bottom two produce it on the recipient’s handset even when the attestation level itself is fine.

Root cause 1: calling from a number you don’t own in Orbit (the C ceiling)

The dial-time attestation resolver mints A/B/C purely from ownership: a number your org owns through Orbit attests A, an active pool lease attests B, and anything else — a verified external caller ID, a hosted number, a BYON number you legitimately control but haven’t ported — attests C. That C is the “dreaded C ceiling”: no configuration raises a non-owned number to A. A is ownership-only, per STIR/SHAKEN attestation — and a delegate certificate (root cause 2) caps at B by design, because a self-registered certificate the platform doesn’t cryptographically chain-validate must never be able to spoof full attestation. Diagnostic. Pull the posture snapshot. The column that matters is source: a number showing attestation: "C" (or “B” against an “A” target) on a source the org doesn’t hold as owned is living under the ceiling. Fix run.

Own the number. Purchase or port the numbers into Orbit (Number porting) so your org owns them outright. This is the only path from C to A. A delegate certificate covers the gap while the port completes (root cause 2), but the floor to A is ownership.
Move your outbound traffic onto the owned DIDs. Until ownership lands, expect and accept a B target for BYON/leased traffic — or cover BYON numbers with a delegate certificate (root cause 2).
Re-read the posture snapshot. The moved numbers now resolve to A, and meeting_target closes the below_target gap.

Do not PUT /attestation/policy a higher target and expect calls to sign higher: the softswitch signs exactly the level Orbit attests and no more — a worse-compared-to-target posture is a reporting flag, not a gate.

Root cause 2: delegate certificate expired, pending, or rejected

A delegate certificate lifts the specific numbers it covers from C to B — the answer for BYON / verified external numbers you hold certificates for. The failure modes are the certificate’s own lifecycle, and they are all silent: coverage falls to C the moment the certificate stops being active, with no call blocked and no error.

Symptom in the registry	Effective status	Result
`valid from` still in the future	`pending`	Coverage has not begun; covered numbers attest at ownership level (C for BYON)
`valid until` has passed	`expired`	Coverage ended; covered numbers fall back to C
You clicked Revoke	`revoked`	Same immediate fallback as expired
Chain not parseable at registration	`422 INVALID_CERTIFICATE`	The certificate never registered at all

Diagnostic. List the registered certificates and read the effective status column (the registry derives it live, not from what it was last told):

curl "https://api.orbit.devotel.io/api/v1/compliance/attestation/delegate-certs" \
  -H "Authorization: Bearer $ORBIT_API_KEY"

A certificate showing pending, expired, or revoked is one whose covered numbers have silently dropped to C — this is the most common way a previously-working call route degrades. Fix run.

Re-register with a fresh chain. Obtain the renewed delegate certificate chain (PEM) from your service provider (ATIS-1000092), then re-register with the numbers listed in E.164:

curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/attestation/delegate-certs" \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "friendly_name": "BYON caller-ID coverage",
    "certificate_pem": "-----BEGIN CERTIFICATE-----\n…\n-----END CERTIFICATE-----",
    "covered_numbers": ["+14155551234", "+14155550987"],
    "covered_ranges": [{ "start": "+14155555000", "end": "+14155555999" }],
    "not_before": "2026-09-01T00:00:00Z",
    "not_after": "2027-09-01T00:00:00Z"
  }'

Match the coverage to the numbers you actually dial. Coverage falls to C per-number: a chain registered with one range or list doesn’t cover a number outside it. A registered certificate only raises the numbers it explicitly covers; E.164 the whole outbound set.
Re-register before the window closes. Watch the valid until column on the dashboard section and re-register before it flips to expired — the flip is when the drop happens, not after.

Limits to plan around: an org holds at most 50 certificates (409 DELEGATE_CERT_LIMIT at the limit), re-registering the same fingerprint returns 409 DELEGATE_CERT_DUPLICATE, and a revoked certificate cannot be un-revoked — re-register a fresh chain instead. Certificate writes are admin-gated (owner/admin role); certificate reads and the posture snapshot are not.

Root cause 3: certificate chain rejected at registration

A rejected chain never enters the registry, so the numbers it was meant to cover silently attest at ownership level (C) while you believed they were covered. The registration endpoint rejects two shapes with a 422 before any coverage exists:

422 INVALID_CERTIFICATE — certificate_pem held no parseable PEM-encoded certificate block (wrong encoding, truncated chain, or a non-certificate payload pasted in).
422 INVALID_COVERAGE_RANGE — a covered_ranges entry had start > end.

Diagnostic. Re-issue the POST and read the response error.code directly — the two codes above name the failure exactly. A 422 at registration time means your numbers were never covered; the calls themselves carry no mark of that. Fix run. Obtain the chain again from the provider and re-submit with a well-formed PEM body and valid ranges. If your provider issued a chain that won’t parse, escalate to the provider — the registry records the authorization artifact; it does not repair the chain.

Root cause 4: per-number branded-calling override blocking RCD

This one bites from the recipient side even when attestation itself is A. RCD (branded calling) renders only on A-attested calls; a per-number branded-caller profile set on a DID can override the org-level profile for that DID, and a profile that is disabled or incomplete drops RCD for that number without touching the attestation level — the call still signs A, but the handset renders plain attestation plus CNAM, and recipients who associate the brand with the rendered name see a bare “Spam Likely”-adjacent treatment on the numbers they expected branded. Diagnostic. Check the DID’s own branded-calling surface before blaming the org default: if a per-number profile exists on the number, it overrides the org configuration for that number, and a disabled/blank profile on it removes RCD for that DID only. Fix run.

Confirm attestation first. RCD is downstream of A — a downgraded number breaks RCD regardless of profile (work root cause 1/2 first).
Lift the per-number profile to the org default. Unless the DID needs its own brand, remove the per-DID override and let the org-level branded calling apply. Per the Branded calling page, the org-level surface is PUT /api/v1/settings/branded-calling; a per-DID profile that was set as a one-off and left behind is the common culprit.
Verify. Place a test call from the number to a carrier where your brand registration completed; confirm the brand renders instead of the bare caller ID.

Root cause 5: RCD-capable carrier coverage mismatch

RCD is carrier-dependent: the branded-calling treatment only renders on carriers where your per-carrier brand registration completed, and elsewhere the RCD payload silently drops — but the call still carries full attestation. A registration gap across the RCD-capable carrier list is therefore a downgrade of the branded treatment, not of attestation: a recipient on a non-registered carrier sees plain attestation plus CNAM while a recipient on a registered carrier sees the brand. The confusing part is that the payload is silently dropped for that call, and no error surfaces. Diagnostic. Check the per-carrier registration status on the branded- calling surface. RCD renders only where the Devotel branded-calling team has finished the registration side-band — an incomplete or not-yet-registered carrier drops the RCD while the attestation level still shows A on the call record. Fix run.

Verify A-attestation first — RCD can’t ride a downgraded call (fix root cause 1/2, or the org branded-calling enabled toggle).
Complete carrier registration. Registration is an operator-managed side-band with the Devotel branded-calling team, not something a tenant self-serves — until it completes on a downstream carrier, RCD stays silent there by design.
Re-check after save. Remember a config save on the branded-calling surface — a changed display name, logo URL, or reason-for-call — resets the brand-verification state to unverified, so the revised brand goes back through review before it renders again.

What not to do

Do not chase a blocked call. A downgrade never blocks — fail-open to C is deliberate (a recoverable reporting downgrade beats a blocked call). Work the level reads, not a call-failure log.
Do not PUT a higher policy target and wait for calls to improve. The target is reporting intent; the softswitch signs at exactly the attested level and no more. Policy changes make the gap more visible, never smaller.
Do not re-register a revoked delegate certificate’s same chain. A revoked record can’t be un-revoked — obtain and re-register a fresh chain.
Do not treat “RCD renders nowhere” as an attestation outage. Check the branded-calling surface first: RCD is a signalling surface on top of A, not the attestation level itself.

Error-code map

No structured STIR/SHAKEN refusal exists — the call dispatches regardless — but three real codes from the compliance surface are worth recognizing when they do appear:

Code	HTTP	Where it surfaces	What it means
`INVALID_CERTIFICATE`	422	`POST /compliance/attestation/delegate-certs`	The PEM chain had no parseable certificate block — coverage never started
`INVALID_COVERAGE_RANGE`	422	`POST /compliance/attestation/delegate-certs`	A covered range had `start > end` — rejected before registration
`DELEGATE_CERT_LIMIT`	409	`POST /compliance/attestation/delegate-certs`	The 50-per-org certificate cap is full — revoke an unused certificate first
`DELEGATE_CERT_DUPLICATE`	409	`POST /compliance/attestation/delegate-certs`	This chain fingerprint is already registered — covered numbers already attest at its level

VALIDATION_ERROR (422) on the policy/cert write endpoints means a malformed field, not a downgrade. For everything else — the C ceiling, an expired cert, a per-number override, a registration gap — there is no error: the signal lives in the posture snapshot and the branded-calling status, not the error-code catalog.

Reference

Troubleshooting: STIR/SHAKEN attestation stuck at C — spam-likely treatment, delegate certificates, and RCD

Troubleshooting: STIR/SHAKEN attestation downgrade

Symptoms

Reads: measuring the downgrade before fixing it

Originating: which numbers attest below your target

Inbound: verification summary against your floor

Root causes and fixes

Root cause 1: calling from a number you don’t own in Orbit (the C ceiling)

Root cause 2: delegate certificate expired, pending, or rejected

Root cause 3: certificate chain rejected at registration

Root cause 4: per-number branded-calling override blocking RCD

Root cause 5: RCD-capable carrier coverage mismatch

What not to do

Error-code map

See also

​Troubleshooting: STIR/SHAKEN attestation downgrade

​Symptoms

​Reads: measuring the downgrade before fixing it

​Originating: which numbers attest below your target

​Inbound: verification summary against your floor

​Root causes and fixes

​Root cause 1: calling from a number you don’t own in Orbit (the C ceiling)

​Root cause 2: delegate certificate expired, pending, or rejected

​Root cause 3: certificate chain rejected at registration

​Root cause 4: per-number branded-calling override blocking RCD

​Root cause 5: RCD-capable carrier coverage mismatch

​What not to do

​Error-code map

​See also

Troubleshooting: STIR/SHAKEN attestation downgrade

Symptoms

Reads: measuring the downgrade before fixing it

Originating: which numbers attest below your target

Inbound: verification summary against your floor

Root causes and fixes

Root cause 1: calling from a number you don’t own in Orbit (the C ceiling)

Root cause 2: delegate certificate expired, pending, or rejected

Root cause 3: certificate chain rejected at registration

Root cause 4: per-number branded-calling override blocking RCD

Root cause 5: RCD-capable carrier coverage mismatch

What not to do

Error-code map

See also