What you need to know
SRTP can protect RTP and RTCP media traffic, but its result depends on key management and does not secure camera administration, storage, export, or operator access.
Potentially affected
Video architectures proposing or using Secure RTP between cameras, gateways, media services, recorders, or clients.
DSE recommendation
Define the protected media hops and key lifecycle explicitly, validate encryption and authentication on those hops, and control the remaining video lifecycle separately.
Bottom line: SRTP can protect a media session in transit; it does not make an entire surveillance system secure. The architecture must still identify how keys are established, where protected traffic terminates, and what happens to video before and after that boundary.
Source fact: SRTP protects RTP and RTCP with defined security services
RFC 3711 specifies the Secure Real-time Transport Protocol. It describes confidentiality, message authentication, and replay protection for RTP and protection for RTCP. Those services are applied to media transport; the RFC relies on suitable key management rather than defining one universal provisioning workflow for every application.
This distinction matters in video systems. A gateway may decrypt and re-originate a stream, a recorder may store plaintext video, or a client may export an unencrypted file even though one network segment used SRTP.
Source boundary and applicability
The RFC is a protocol specification, not proof that a product implements a current, interoperable, and securely configured profile. It does not secure web administration, discovery, device credentials, recorded databases, exports, backups, metadata, or endpoint operating systems. Later RFCs update parts of the SRTP ecosystem, so exact algorithms and product support require current vendor documentation and policy review.
Applicability questions
- Which source and destination terminate SRTP, and which intermediate systems can see plaintext?
- How are session keys authenticated, generated, distributed, rotated, revoked, and recovered?
- Which algorithms and parameters do both endpoints actually negotiate or configure?
- Are multicast, failover, mobile viewing, analytics, and third-party integrations supported?
- How are recordings, exports, thumbnails, metadata, and backups protected after transport ends?
DSE recommendation: draw and test the cryptographic boundary
The following steps are DSE recommendations based on the cited source.
Create a media-flow diagram that marks every encryption start, termination, retransmission, and storage point. For each hop, record the protocol version, protection services, algorithms, key-establishment method, trust anchor, owner, rotation event, and failure behavior. Reject silent fallback to an unprotected stream unless a time-limited, approved exception explicitly accepts that risk.
In an isolated or approved test, capture traffic on both sides of a termination point and verify that the protected hop is not intelligible as ordinary RTP while authorized endpoints still receive media. Test invalid authentication, expired or replaced credentials, restart, failover, and logging. Continue to use network segmentation, endpoint hardening, least privilege, encrypted storage or exports where required, and audited evidence handling.
Verification and evidence
Retain the flow diagram, product interoperability statement, configuration exports, approved algorithm and key-management design, sanitized capture results, negative test logs, rotation record, fallback test, and separate storage and access-control evidence.
Official references
- RFC 3711 – The Secure Real-time Transport Protocol – RFC Editor
Review the official source
RFC 3711 - The Secure Real-time Transport Protocol · Verified August 25, 2026
Need help applying this guidance safely?
DSE can help confirm applicability, protect service continuity, and validate the result across physical security and IT systems.
Talk with DSE