Regla de certificado propio de la FCC para STIR/SHAKEN: lo que deben saber los proveedores de voz

Desde el 18 de septiembre de 2025, todo proveedor de servicios de voz con obligación de implementar STIR/SHAKEN debe firmar las llamadas con su propio certificado digital, no con el de un tercero. Si su organización ha dependido de un certificado compartido con un proveedor, ese arreglo ya no cumple con la normativa.

El Eighth Report and Order de la FCC cerró la puerta a un atajo común: usar el certificado del servicio de firma en lugar del propio. La firma por terceros sigue siendo permitida, pero el certificado debe ser suyo, las decisiones de attestation deben provenir de usted, y se requiere un acuerdo escrito que lo establezca con claridad.

Si no ha auditado su arreglo de firma desde que la regla entró en vigencia, esta página detalla qué se requiere, a quién afecta y cómo verificar que su configuración cumpla con el estándar.

Qué exige realmente la regla de certificado propio de la FCC

La regla es sencilla: si usted tiene obligación de implementar STIR/SHAKEN, sus llamadas deben firmarse con su propio certificado, es decir, el que obtuvo usando su propio token Service Provider Code (SPC).

Antes de septiembre de 2025, un proveedor podía contratar un servicio de firma y hacer que las llamadas se firmaran con el certificado del proveedor externo. Eso ya no es válido para los proveedores obligados.

La regla también establece que las decisiones de attestation deben recaer en usted, no en el servicio de firma. El nivel de attestation determina lo que usted asevera sobre cada llamada:

• Nivel A (Full Attestation): Usted puede autenticar a la parte que llama, su número y que está autorizada a usarlo.
• Nivel B (Partial Attestation): Usted puede autenticar al cliente originante y la fuente de la llamada, pero no si la parte que llama está autorizada a usar el número específico.
• Nivel C (Gateway Attestation): La llamada ingresó a su red desde una fuente externa que usted no puede autenticar.

Un servicio de firma puede realizar el acto técnico de firmar, pero no puede decidir el nivel de attestation. Esa determinación debe provenir de su organización, no del servicio de firma.

Qué debe cubrir un acuerdo escrito

Todo proveedor que use a un tercero para realizar la firma STIR/SHAKEN necesita un acuerdo escrito que establezca explícitamente:

1. Las llamadas se firmarán usando su certificado, no el del tercero
2. El tercero solo realiza el acto de firmar digitalmente
3. Su organización toma todas las decisiones sobre el nivel de attestation

Ese acuerdo debe conservarse en caso de una inspección por parte de la FCC.

A quién afecta y quién está exento

La regla del 18 de septiembre de 2025 aplica a todos los proveedores de servicios con obligación de implementar STIR/SHAKEN: operadoras, CLECs y proveedores de VoIP interconectado que originan llamadas y controlan la infraestructura para firmarlas.

Los revendedores y los Mobile Virtual Network Operators (MVNOs) generalmente están exentos; no controlan la infraestructura necesaria para implementar STIR/SHAKEN y no están obligados a obtener su propio token SPC bajo esta regla.

Actualización en el Robocall Mitigation Database

Si su organización ha registrado un estado de implementación STIR/SHAKEN “completo” o “parcial” en el Robocall Mitigation Database (RMD), su certificación debe reflejar ahora que usted posee un token SPC y un certificado digital, y que las llamadas se firman con su certificado. Todo acuerdo de firma con terceros también debe estar documentado en sus registros.

La prueba de cumplimiento en tres partes

El cumplimiento se reduce a tres puntos de verificación concretos:

1. Usted posee su propio token SPC. Obtenido del STIR/SHAKEN Policy Administrator (STI-PA). Este es su credencial fundamental en el ecosistema STIR/SHAKEN.
2. Sus llamadas se firman con su propio certificado. Usted presenta su token SPC a una STIR/SHAKEN Certificate Authority (STI-CA) para obtener ese certificado. Todas las llamadas deben firmarse con él (no con el de un tercero), independientemente de quién realice la operación de firma.
3. Usted toma las decisiones de attestation. El nivel de attestation A, B o C lo determina su organización según lo que sabe sobre el origen de cada llamada. El servicio de firma ejecuta la firma con base en el nivel que usted suministra; no lo asigna de manera independiente.

Si cumple los tres requisitos, con un acuerdo escrito vigente en caso de usar un tercero, está en cumplimiento.

Cómo encajan los session border controllers en el cumplimiento de STIR/SHAKEN

Los Session Border Controllers (SBCs) se ubican en el borde originante de su red, que es exactamente donde ocurre la firma STIR/SHAKEN. Comprender la arquitectura ayuda a clarificar dónde deben residir los controles de cumplimiento. Para una guía completa de configuración, consulte la guía de implementación de STIR/SHAKEN en SBC.

En una implementación típica, el SBC recibe una llamada de su cliente originante e inicia una solicitud de firma a un STIR/SHAKEN Authentication Service (STI-AS) externo antes de reenviar la llamada. Esa solicitud de firma incluye sus credenciales de proveedor y el nivel de attestation que usted ha determinado para la llamada. El STI-AS obtiene su certificado de su STI-CA, genera el token PASSporT y devuelve un encabezado Identity firmado, que el SBC inyecta en el SIP INVITE saliente.

Hay varios aspectos arquitectónicos que vale la pena confirmar con su proveedor de SBC:

• Sus credenciales viajan con la solicitud de firma. El SBC debe pasar su token de autorización y la URL del servicio de firma en la solicitud; el certificado usado para firmar la llamada debe estar registrado en su dominio, no en el del servicio de firma.
• El control de attestation permanece en la capa de enrutamiento. El SBC debe incluir el parámetro attest en la solicitud de firma según su lógica de enrutamiento y lo que conoce sobre cada fuente de llamada. Una arquitectura conforme no le otorga al servicio de firma ninguna autoridad independiente para anular o modificar el nivel de attestation.
• Redundancia para la disponibilidad del servicio de firma. Los SBCs que admiten tanto una URL de servicio de firma principal como una secundaria ofrecen conmutación por error automática sin intervención manual.
• Manejo adecuado cuando la firma falla. Cuando un servicio de firma no está disponible, la llamada debe completarse de todas formas, con un mecanismo para indicar a los proveedores posteriores que la firma no estuvo disponible para esa llamada. Vale la pena revisar cómo maneja su SBC este caso límite para confirmar que se alinea con las expectativas de la FCC.

Cómo verificar su cumplimiento

La regla está en vigencia desde el 18 de septiembre de 2025. Use esta lista de verificación para auditar su configuración:

1. Confirme su obligación de cumplimiento con STIR/SHAKEN. Verifique si su organización es un proveedor de servicios obligado o si se encuentra bajo alguna exención.
2. Confirme que posee su propio token SPC. Obtenido del STI-PA antes o poco después del 18 de septiembre de 2025. Si aún no lo ha obtenido, este es su primer paso correctivo.
3. Confirme que las llamadas se firman con su propio certificado digital. Verifique con su servicio de firma que el certificado actualmente en uso es suyo, no uno compartido con el proveedor.
4. Verifique que su servicio de firma esté configurado con su certificado. Tanto si usa TransNexus, Neustar u otro servicio integrado con STI-CA, confirme que está firmando con su certificado, no con el propio del servicio.
5. Confirme que existe un acuerdo escrito. El acuerdo debe indicar: se usa su certificado, el tercero solo realiza la operación de firma, y su organización toma todas las decisiones de attestation. Consérvelo para una posible inspección de la FCC.
6. Audite la configuración de su SBC. Confirme que la URL de su servicio de firma apunta a una integración que usa sus credenciales y certificado. Revise su lógica de enrutamiento para verificar que las reglas de nivel de attestation reflejen correctamente su conocimiento de cada fuente de llamada.
7. Verifique que su certificación en el Robocall Mitigation Database esté actualizada. Su registro en el RMD debe reflejar la titularidad del token SPC, la firma con certificado propio, y documentar cualquier acuerdo de firma con terceros vigente.

Si usa un servicio de firma: probablemente esté bien. Verifique estas tres cosas.

La regla de certificado propio de la FCC no prohíbe la firma por terceros. Define las condiciones bajo las cuales es válida: su certificado, sus decisiones de attestation, su acuerdo escrito.

La mayoría de las implementaciones STIR/SHAKEN bien diseñadas ya siguen este modelo: el attestation se establece en la capa de enrutamiento, las credenciales pertenecen al proveedor, y el servicio de firma ejecuta la solicitud. La lista de verificación anterior cubre todo lo que necesita confirmar para cumplir con la normativa.