Regra de certificado próprio STIR/SHAKEN da FCC: o que provedores de voz precisam saber

Desde 18 de setembro de 2025, todo provedor de serviços de voz com obrigação de implementação STIR/SHAKEN deve assinar chamadas com seu próprio certificado digital, e não com o de terceiros. Se a sua organização tem utilizado um certificado compartilhado de fornecedor, esse arranjo não está mais em conformidade.

O Eighth Report and Order da FCC encerrou um atalho comum: usar o certificado do seu serviço de assinatura em vez do seu próprio. A assinatura por terceiros ainda é permitida. Porém, o certificado deve ser seu, as decisões de atestação devem partir de você, e você precisa de um contrato por escrito que especifique tudo isso.

Se você não auditou seu arranjo de assinatura desde que a regra entrou em vigor, esta página explica o que é exigido, quem é afetado e como verificar se sua configuração atende ao padrão.

O que a regra de certificado próprio da FCC realmente exige

A regra é direta: se você tem obrigação de implementação STIR/SHAKEN, suas chamadas devem ser assinadas com seu próprio certificado, aquele obtido usando seu próprio token SPC (Service Provider Code).

Antes de setembro de 2025, um provedor podia contratar um serviço de assinatura e ter as chamadas assinadas usando o certificado do fornecedor. Isso não está mais em conformidade para provedores obrigados.

A regra também define que as decisões de atestação devem permanecer com você, não com o serviço de assinatura. O nível de atestação determina o que você está declarando sobre cada chamada:

• Nível A (atestação completa): você pode autenticar a parte chamadora, seu número e confirmar que ela está autorizada a usá-lo.
• Nível B (atestação parcial): você pode autenticar o cliente originador e a fonte da chamada, mas não se a parte chamadora está autorizada a usar o número específico.
• Nível C (atestação de gateway): a chamada entrou na sua rede a partir de uma fonte externa que você não consegue autenticar.

Um serviço de assinatura pode executar o ato técnico de assinatura, mas não pode decidir o nível de atestação. Essa determinação deve partir da sua organização, não do serviço de assinatura.

O que um contrato por escrito deve cobrir

Qualquer provedor que utilize um terceiro para realizar a assinatura STIR/SHAKEN precisa de um contrato por escrito que declare explicitamente:

1. As chamadas serão assinadas usando seu certificado, não o do terceiro
2. O terceiro está apenas executando o ato de assinatura digital
3. Sua organização toma todas as decisões sobre o nível de atestação

Esse contrato deve ser preservado para o caso de uma inspeção da FCC.

Quem é afetado e quem está isento

A regra de 18 de setembro de 2025 se aplica a todos os provedores de serviços com obrigação de implementação STIR/SHAKEN: operadoras, CLECs e provedores VoIP interconectados que originam chamadas e controlam a infraestrutura para assiná-las.

Revendedores e Operadoras de Rede Móvel Virtual (MVNOs) estão geralmente isentos; eles não controlam a infraestrutura necessária para implementar STIR/SHAKEN e não são obrigados a obter seu próprio token SPC sob esta regra.

Atualização do Robocall Mitigation Database

Se sua organização registrou status de implementação STIR/SHAKEN “completa” ou “parcial” no Robocall Mitigation Database (RMD), sua certificação agora deve refletir que você possui um token SPC e certificado digital, e que as chamadas são assinadas com seu certificado. Qualquer arranjo de assinatura por terceiros também deve estar documentado em seus registros.

O teste de conformidade em três partes

A conformidade se resume a três pontos de verificação concretos:

1. Você possui seu próprio token SPC. Obtido junto ao STIR/SHAKEN Policy Administrator (STI-PA). Esta é sua credencial fundamental no ecossistema STIR/SHAKEN.
2. Suas chamadas são assinadas com seu próprio certificado. Você apresenta seu token SPC a uma STIR/SHAKEN Certificate Authority (STI-CA) para obter esse certificado. Todas as chamadas devem ser assinadas com ele (não com o de um terceiro), independentemente de quem execute a operação de assinatura.
3. Você toma as decisões de atestação. O nível de atestação A, B ou C é determinado pela sua organização com base no que você sabe sobre a origem de cada chamada. O serviço de assinatura executa a assinatura com base no nível que você fornece; ele não o atribui de forma independente.

Cumpra os três requisitos, com um contrato por escrito em vigor se você utilizar um terceiro, e você estará em conformidade.

Como os Controladores de Borda de Sessão se encaixam na conformidade STIR/SHAKEN

Os Controladores de Borda de Sessão (SBCs) ficam na borda de originação da sua rede, que é exatamente onde a assinatura STIR/SHAKEN acontece. Entender a arquitetura ajuda a esclarecer onde os controles de conformidade precisam estar. Para um passo a passo completo de configuração, consulte o Guia de implementação STIR/SHAKEN para SBC.

Em uma implementação típica, o SBC recebe uma chamada do seu cliente originador e inicia uma solicitação de assinatura para um STIR/SHAKEN Authentication Service (STI-AS) externo antes de encaminhar a chamada. Essa solicitação de assinatura carrega as credenciais do seu provedor e o nível de atestação que você determinou para a chamada. O STI-AS busca seu certificado na sua STI-CA, gera o token PASSporT e retorna um header Identity assinado, que o SBC injeta no SIP INVITE de saída.

Vários pontos arquiteturais merecem confirmação com seu fornecedor de SBC:

• Suas credenciais acompanham a solicitação de assinatura. O SBC deve enviar seu token de autorização e a URL do serviço de assinatura na solicitação; o certificado usado para assinar a chamada deve estar registrado no seu domínio, não no do serviço de assinatura.
• O controle de atestação permanece na camada de roteamento. O SBC deve preencher o parâmetro de atestação na solicitação de assinatura com base na sua lógica de roteamento e no que ele sabe sobre cada fonte de chamada. Uma arquitetura em conformidade não dá ao serviço de assinatura autoridade independente para sobrescrever ou modificar o nível de atestação.
• Redundância para disponibilidade do serviço de assinatura. SBCs que suportam tanto uma URL primária quanto secundária do serviço de assinatura oferecem failover automático sem intervenção manual.
• Tratamento adequado quando a assinatura falha. Quando um serviço de assinatura está indisponível, a chamada ainda deve ser completada, com um mecanismo para sinalizar aos provedores downstream que a assinatura não estava disponível para aquela chamada. Vale a pena revisar como seu SBC lida com esse caso limite para confirmar que está alinhado com as expectativas da FCC.

Como verificar sua conformidade

A regra está em vigor desde 18 de setembro de 2025. Use este checklist para auditar sua configuração:

1. Confirme sua obrigação STIR/SHAKEN. Verifique se sua organização é um provedor de serviços obrigado ou se se enquadra em uma isenção.
2. Confirme que você possui seu próprio token SPC. Obtido junto ao STI-PA antes ou logo após 18 de setembro de 2025. Se ainda não obteve, este é seu primeiro passo corretivo.
3. Confirme que as chamadas são assinadas com seu próprio certificado digital. Verifique com seu serviço de assinatura se o certificado atualmente em uso é seu, não um compartilhado pelo fornecedor.
4. Verifique se seu serviço de assinatura está configurado com seu certificado. Seja usando TransNexus, Neustar ou outro serviço integrado com STI-CA, confirme que está assinando com seu certificado, não com o do próprio serviço.
5. Confirme que um contrato por escrito está em vigor. O contrato deve declarar: seu certificado é utilizado, o terceiro apenas executa a operação de assinatura e sua organização toma todas as decisões de atestação. Mantenha-o disponível para inspeção da FCC.
6. Audite a configuração do seu SBC. Confirme que a URL do serviço de assinatura aponta para uma integração usando suas credenciais e certificado. Revise sua lógica de roteamento para verificar se as regras de nível de atestação refletem corretamente seu conhecimento sobre cada fonte de chamada.
7. Verifique se sua certificação no Robocall Mitigation Database está atualizada. Seu registro no RMD deve refletir a posse do token SPC, a assinatura com certificado próprio e documentar qualquer arranjo de assinatura por terceiros em vigor.

Se você usa um serviço de assinatura: provavelmente está tudo certo. Verifique estas três coisas.

A regra de certificado próprio da FCC não proíbe a assinatura por terceiros. Ela define as condições sob as quais isso é permitido: seu certificado, suas decisões de atestação, seu contrato por escrito.

A maioria das implementações STIR/SHAKEN bem arquitetadas já segue esse modelo: a atestação é definida na camada de roteamento, as credenciais pertencem ao provedor e o serviço de assinatura executa a solicitação. O checklist de auditoria acima cobre tudo o que você precisa para confirmar a conformidade.