Stuck on a compliance audit requirement for our 15 BYOC trunks in AP-Southeast-1 where the security team mandates strict TLS certificate pinning validation. The current configuration relies on the default Genesys Cloud edge certificates, but the audit tool flags these as non-compliant because we cannot verify the full chain of trust against our internal CA policies. When attempting to update the SIP TLS settings via the Platform API endpoint /api/v2/telephony/providers/edges, specifically targeting the transport object to include custom certificate fingerprints, the system returns a HTTP 400 Bad Request. The error payload indicates that the tlsCertificatePin field is immutable for BYOC trunks managed under the current tenant security profile. We are running Architect flow v14.2.1 which handles the outbound routing logic, and while the calls succeed, the lack of verifiable certificate pinning data in the session logs is a critical gap. The SIP registration remains stable with 200 OK responses, but the TLS handshake details in the raw SIP traces do not expose the certificate subject details clearly enough for our automated compliance script to validate against the required SHA-256 hash. We have verified that the carrier SBCs are presenting valid certificates from a trusted public CA, yet the Genesys Cloud interface does not provide a mechanism to inject or validate custom pinning rules for these specific trunk groups. The documentation suggests that certificate management is abstracted for BYOC, but this creates a blind spot for our security posture. Is there a workaround using the Data Action to capture and validate the TLS certificate details during the session setup, or is there a hidden configuration flag in the trunk provisioning that allows for explicit certificate pinning enforcement? We need a definitive way to ensure that the media and signaling paths are validated against our specific certificate requirements without breaking the existing failover logic that depends on these 15 trunks.