SRTP protects RTP media by encrypting audio and video and adding integrity checks to prevent tampering. It does not replace signalling security, so key exchange still has to be protected by the surrounding call setup. Defenders should ensure compatible key management, verify both signalling and media protection, and watch for downgrade to unprotected streams.
How SRTP secures RTP media
SRTP sits on top of RTP and protects the media stream itself, not the call signalling. That means the voice or video packets can be encrypted in transit and checked for integrity after they are generated, while the SIP or other signalling path that negotiated the session must be protected separately. NIST SP 800-57 Key Management is relevant here because SRTP depends on sound key lifecycle handling, not just encryption.
In practical terms, SRTP protects the confidentiality of media and helps detect tampering, replay, or manipulation of packets once media is flowing. It does not make the entire voice or video session secure by itself. If the surrounding call setup leaks keys, permits weak negotiation, or fails to protect signalling, an attacker may still reach the media path indirectly even though the RTP payloads are encrypted.
Why key exchange and negotiation matter
SRTP usually inherits its security from how keys are established, distributed, and refreshed. That is why the surrounding protocol stack matters: a secure media profile with weak key transport still leaves the session exposed. NIST SP 800-63 Digital Identity Guidelines is not about media encryption, but it reinforces the broader principle that strong authentication and protected negotiation are foundational when one protocol depends on another for trust.
For defenders, the critical question is not only whether SRTP is enabled, but whether both endpoints actually negotiated it and whether the keys were exchanged through a channel that resists interception or downgrade. A secure design treats signalling, key management, and media protection as linked parts of one control chain. If any link is weak, the media security outcome weakens with it.
What to verify in deployments
Operationally, the most useful check is whether the environment enforces protected media end to end and fails closed when secure negotiation is unavailable. Mixed estates often create false confidence, because some calls are encrypted while others quietly fall back to plain RTP. NIST Cybersecurity Framework 2.0 fits this verification mindset because it frames the control objective as consistent protection, detection of gaps, and recovery from misconfiguration.
- Confirm that signalling and media protection are both required for the session type you are using.
- Check that key exchange is protected by the call setup mechanism and cannot be silently downgraded.
- Validate that endpoints, SBCs, and media relays agree on compatible SRTP profiles and do not fall back unexpectedly.
- Review logs and call traces for failed negotiations, unprotected streams, or repeated renegotiation attempts.
Risk and Threat Considerations
SRTP reduces exposure on the media path, but it does not eliminate the risk of downgrade, key compromise, or control-plane weakness. If attackers can influence negotiation or observe weak signalling, they may force unprotected RTP, capture keys, or exploit a mismatch between what the system intended to protect and what was actually deployed.
Failure mechanism: The protection fails when signalling is unsecured, key exchange is exposed, or endpoints accept a weaker media mode after negotiation pressure or compatibility failure.
Impact: Attackers can eavesdrop on calls, tamper with media, or obtain enough session material to compromise confidentiality even when SRTP was expected to be in use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | SRTP depends on protected key generation, exchange, rotation, and lifecycles. |
| Recommendation — Manage SRTP keys with protected exchange, bounded lifetime, and timely rotation. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Secure negotiation and authentication underpin trust in the session setup. |
| Recommendation — Use strong authenticated negotiation for the signalling path that establishes SRTP trust. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | SRTP protects media data in transit by encrypting the RTP payload stream. |
| PR.DS-02 — Data-in-transit is protected | SRTP is a transport protection mechanism for RTP media traffic. | |
| PR.AA-05 — Access permissions and authorizations are managed, enforced, and reviewed | Session and key negotiation must enforce the intended media protection policy. | |
| Recommendation — Protect voice and video payloads in transit with encryption and integrity checks. Require protected transport for media streams and block cleartext fallback. Enforce policy so only authenticated sessions can negotiate protected media. | ||
Practitioner Guidance
What to verify: Treat SRTP as a session-property check, not a checkbox. Verify that secure media is mandatory for the call paths that matter, and that the call cannot complete in cleartext without an explicit exception.
Decision rule: If you can protect the media but not the signalling or key exchange, prioritize the negotiation path first. Media encryption without trusted key establishment gives a fragile security result.
Practitioner takeaway: The right mental model is layered protection, secure signalling establishes the trust, key management sustains it, and SRTP then protects the media itself.