This post explains how to deploy encryption and secure signaling for Voice over IP (VoIP) so your organization can protect Controlled Unclassified Information (CUI) in transit and meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control SC.L2-3.13.14 with practical, actionable steps for a small-business environment.
Control overview and key objectives
SC.L2-3.13.14 requires that cryptographic mechanisms be used to protect the confidentiality of CUI during transmission. For VoIP this translates into two concrete objectives: (1) ensure signaling between endpoints and servers (SIP) is protected from interception and tampering, and (2) ensure media streams (RTP) are encrypted so audio cannot be eavesdropped. Implementation must include appropriate cryptographic algorithms, certificate/key management, logging, and operational controls aligned with your compliance framework.
Practical implementation steps
1) Inventory, architecture and scope
Begin by cataloging all VoIP components that handle CUI: IP phones, softphones, SIP servers/proxies, session border controllers (SBCs), PSTN gateways, hosted providers, and any call-recording systems. Map signaling and media paths (SIP signaling, RTP media, STUN/TURN/ICE flows) and identify which flows carry CUI. That scoped inventory is the basis for policy, network segmentation, and technical controls.
2) Choose the right protocols and cryptography
Use SIP over TLS (SIPS) for signaling (TCP port 5061) and SRTP for media encryption. For SRTP keying prefer DTLS-SRTP (DTLS handshake + SRTP) or SDES only where DTLS is impossible; avoid plain SDP with unencrypted RTP. Configure TLS 1.2 or TLS 1.3 with ECDHE key exchange and AEAD ciphers (e.g., TLS_AES_128_GCM_SHA256 or TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256). For SRTP prefer AES-GCM (SRTP_AES128_GCM or SRTP_AES256_GCM) where supported. Ensure cryptographic libraries are FIPS 140-2/3 validated if your contract or system requires validated modules (e.g., OpenSSL FIPS module, Windows CNG with FIPS-enabled CSP).
3) Certificate and key management
Deploy a PKI strategy: issue certificates to SIP servers, SBCs, and (where possible) endpoints. Use short-lived certs (6–12 months) and strong keys (ECDSA P-256 or RSA 2048+). Implement OCSP stapling and automated renewal (ACME / internal CA tooling) for server certs. For SIP trunking to carriers, prefer mutual TLS (mTLS) if the provider supports it—this offers endpoint authentication and prevents man-in-the-middle attacks. Document key rotation, compromise procedures, and storage protections in a Key Management Policy.
4) Deploy and configure edge devices and endpoints
Use an SBC at the network edge to terminate insecure traffic, enforce TLS/SRTP, perform codec negotiation, and provide NAT traversal. Configure SBCs to require TLS for signaling and SRTP for media on all CUI-handling trunks. On internal PBX/softphone endpoints, enable TLS for SIP and DTLS-SRTP for media. Disable insecure fallbacks: block UDP 5060, disable clear RTP, and remove SDES unless unavoidable. Test interop with popular endpoints (e.g., Cisco/Yealink phones, Zoiper/branded softphones) and ensure firmware supports DTLS and AES-GCM.
5) Network, QoS and NAT traversal considerations
Secure signaling and media increases CPU and TLS handshake load—size SBCs/servers accordingly and enable hardware crypto offload if available. Implement voice-specific VLANs, DSCP markings for QoS, and firewall rules to permit only required ports (SIP-TLS 5061, DTLS ephemeral ranges, TURN if used). For NAT traversal, prefer ICE with TLS/DTLS and a TURN server that supports DTLS/TLS so media between hosts and relays remains encrypted; avoid relaying media over untrusted plain UDP paths.
Real-world examples and small business scenarios
Example A — Hosted provider: If you use a cloud VoIP provider, require an MSA/SLA that the provider supports SRTP and SIP-TLS, uses FIPS-validated modules where needed, and provides evidence (config guides, pen test reports). Configure your phones to use TLS to the provider's SBC and ensure SRTP is negotiated. Example B — On-prem Asterisk/FreePBX: enable TLS in sip.conf/pjsip.conf, enable DTLS-SRTP in PJSIP, install certificates from an internal CA, and put an SBC (e.g., FreeSWITCH, OpenSBC) at the edge to authenticate trunks and isolate the PBX from the Internet. Small businesses often use a cloud SIP trunk with mTLS support to avoid exposing their on-prem PBX directly.
Compliance tips, best practices and validation
Document policies: an Encryption Policy, Key Management Policy, and VoIP Configuration Baseline. Maintain configuration checklists and version-controlled configs. Validate via technical controls: run sipsak, sipp, or Wireshark to verify SIP is TLS and RTP is SRTP/DTLS; verify certificate chains and cipher suites; audit SBC logs into your SIEM and enable CDR protections. Perform periodic vulnerability scans and penetration tests focusing on SIP/TURN/SBC. Train staff to recognize misconfigurations and produce an Incident Response runbook for suspected VoIP compromise.
Risks of not implementing secure signaling and media encryption
Without these controls, attackers can eavesdrop on calls containing CUI, perform SIP impersonation or man-in-the-middle attacks, inject audio, and exfiltrate sensitive information. Non-implementation risks include loss of government contracts, failed audits under NIST 800-171/CMMC, reputational damage, regulatory penalties, and potential lateral intrusion vectors into your network through exploited VoIP services.
Summary: To meet SC.L2-3.13.14, inventory VoIP assets, enforce SIP over TLS and SRTP with DTLS keying wherever possible, manage certificates and keys via an auditable PKI, deploy SBCs and network segmentation, and test/monitor continuously; these practical steps, coupled with documentation and provider requirements, will help a small business protect CUI in transit and demonstrate compliance with NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2.
