Skip to main content

​
STIR/SHAKEN Attestation Posture

STIR/SHAKEN attaches a cryptographic signature to each outbound call, rated at one of three attestation levels: A (full — the carrier knows you and your right to use the calling number), B (partial — the carrier knows you but not every number’s authorisation), or C (gateway — origin unverified). Receivers use that level to weigh robocall risk, so your posture directly influences answer rates. Own your attestation posture from Settings → Compliance → Attestation: declare the level you target for outbound calls, decide how below-target downgrades are reported, register delegate certificates that lift verified external numbers (BYON) from gateway (C) to partial (B), and read a live posture snapshot of every originating number plus inbound verification.
This page describes your tenant’s own attestation controls. It is not legal advice, and Orbit neither mandates a target level for you nor guarantees any particular STIR attestation — the carrier of record signs outbound traffic, and it will not sign higher than the platform attests. The policy and statuses you set here drive reporting; they never gate or reroute a call.

​
1. Control scope

Your attestation policy is a singleton set of four tenant-owned choices: There are three control layers on the same page: the policy form (these four choices), the delegate certificates section (BYON upgrades), and the posture snapshot (read-only measurement). All three endpoints live under /compliance/attestation and require an authenticated session.

​
2. Set your target and downgrade handling

Only workspace owners and admins can write the policy.
  1. Open Settings → Compliance → Attestation.
  2. Under Attestation policy, pick your target level. Remember the weighting: numbers you own attest A, leased pool numbers attest B, and anything else attests C.
  3. Pick a downgrade mode — most tenants leave Monitor on and switch to Alert while they actively work a gap.
  4. Set the inbound verification floor and the spoof-risk flag.
  5. Select Save policy.
The same policy is readable and writable over the API:
  • GET /compliance/attestation/policy returns the policy (with safe defaults for a tenant that never set one).
  • PUT /compliance/attestation/policy accepts a partial patch; absent fields keep their current value.
Below-target downgrades stay reporting semantics: setting alert flags calls that attest below your target so your team can review them — the call still goes through.

​
3. Review delegated certificates (BYON / verified caller ID)

Outbound levels derive from number ownership: an owned number is A, an active pool lease is B, and everything else — including a verified external or hosted number you legitimately control but do not own in Orbit (BYON) — is gateway (C). Downstream carriers often surface C-rated calls with spam shading, which cuts answer rates. Registering an ATIS-1000092 delegate certificate lifts the numbers it covers from C to B. A delegate certificate can only ever reach partial (B), never full (A): the chain is tenant-supplied and its recorded coverage list is free-form input, so the platform cannot vouch for full attestation — and a self-registered certificate must never spoof that. The registry lives at /compliance/attestation/delegate-certs with a full lifecycle: register (POST), list (GET), revoke (DELETE). The dashboard section on the same page calls it for you.

​
Register a certificate

  1. Obtain the delegate certificate chain (PEM) from your service provider, per ATIS-1000092.
  2. Select Register certificate.
  3. Paste the certificate chain, list the covered numbers in E.164 (comma- or newline-separated), and set the valid from / valid until window. You can label the certificate and record its Service Provider Code (SPC) — both are optional. A certificate may cover individual numbers, inclusive number ranges, or both.
  4. Register. Coverage starts on the certificate’s valid from timestamp.

​
Read the table

Each registered certificate shows its name, coverage (the numbers and ranges it authorises), its effective status, and its valid-until date. Effective status is derived live, so you see the policy-relevant state, not just what the registry was last told:
  • Active — valid now; covered numbers attest B.
  • Pending — registered but the valid from time is still in the future.
  • Expired — past valid until; coverage no longer applies and numbers fall back to their ownership-based level.
  • Revoked — you revoked it; same fallback as expired.

​
Revoke

Select the trash action on a certificate and confirm. Revocation stops covered numbers from attesting B immediately — they fall back to their ownership-based level — and cannot be undone. The record is kept with a revoked-by line for audit; revoking does not delete history.

​
4. Read your traffic posture

The Attestation posture card on the same page (GET /compliance/attestation/posture) measures your current state against your policy.

​
Originating numbers

A totals row shows how many originating numbers you have, how many meet your target, how many are below it, and the per-level split (A / B / C). Below it, a per-number table lists each number, its source (owned or leased), the attestation level applied to it, and whether it meets your target — so you can spot the specific held-back identifier instead of reading only an aggregate.

​
Inbound verification

An inbound summary over the last 30 days counts total inbound calls, verified, unverified, spoof-risk, and the verified rate, where “verified” means the inbound Identity header meets the verification floor you set in the policy. A call counts as spoof-risk when it is unsigned or fails SHAKEN validation and your spoof-risk flag is on.

​
How levels affect gateway handling

Attestation levels travel with the call so receiving carriers can weigh risk: A is the strongest signal, B is accepted by most receivers, and C is the weakest and the most likely to be treated as doubtful. Because downgrade and spoof-risk handling here are reporting-only, “below target” or “unverified” never means blocked — it means flagged for your review.

​
5. Typical response events

Partial upgrade on BYON numbers. Your outbound traffic originates from a verified external or hosted caller-ID your team controls but does not own in Orbit, so those calls attest C and get flagged below target. Register a delegate certificate covering those numbers; they move to B and read as meeting a C or B target in the per-number table. Certificate approaching expiry. Watch the valid until column, and re-register with a renewed chain before the window closes. Once it flips to Expired, covered numbers drop back to their ownership-based level, which reopens the below-target gap. Unrealistic target. If you set target A while originating from leased pool numbers (B) or uncovered BYON numbers (C), the below-target count lights up — either cover those numbers with a delegate certificate (if BYON and you hold the chain) or accept a B target until coverage changes. Inbound spoof-risk spike. When the inbound summary shows a suspicious verified-rate drop or a spike in spoof-risk, review the traffic before tuning your floor. Tightening the floor to A only reclassifies every B and C inbound call as unverified — treat that as a review-aid shift, not a blocking rule.

​
6. Tenant-owned posture

These controls are yours to run, not Orbit’s to impose. You pick the target, the downgrade handling, the inbound floor, and the certificate coverage. Orbit records the policy, reports how your numbers and inbound traffic measure against it, and derives effective certificate status — it mandates no level, and it guarantees no STIR attestation outcome. Regulatory judgement about which level a given programme must hold stays with you and your counsel.
  • Voice channel overview — how STIR/SHAKEN attestation levels behave across your voice traffic.
  • Verify — recipient-verification features that complement caller-ID posture.