Treat SRTP as stream protection, not complete VMS security

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