HDCP — High-bandwidth Digital Content Protection

HDCP (High-bandwidth Digital Content Protection) is an encryption and authentication protocol that protects digital video and audio content from unauthorized copying as it travels across HDMI, DisplayPort, DVI, and HDBaseT connections. Developed by Intel and licensed through Digital Content Protection LLC, HDCP is enforced by content sources (streaming devices, Blu-ray players, cable boxes) at the requirement of content owners. In AV integration, HDCP is one of the most frequent sources of unexplained black screens, switching failures, and 4K resolution dropouts — not because the technology is unreliable in simple point-to-point connections, but because the AV signal chain introduces repeaters, matrix switchers, extenders, and AV-over-IP encoders that each must authenticate correctly. See also glossary/hdcp for a quick-reference overview.

HDCP 1.4 is the baseline version supported by virtually all HDMI 1.x and HDMI 2.0 devices. Key characteristics:

Key exchange: Source sends a 56-bit encrypted key to the sink; sink confirms authentication within 5 seconds
Link bandwidth: Supports up to 1080p60 and 4K30 content (limited by HDMI 2.0 bandwidth)
Repeater depth: Maximum 7 repeater devices in series (hops)
Device limit: Maximum 127 downstream devices per repeater
Authentication timeout: If authentication takes longer than 5 seconds, the source drops the encrypted link and the display goes black

HDCP 1.4 is backward compatible — a HDCP 2.2 source can fall back to HDCP 1.4 for non-4K HDR content if the sink only supports 1.4.

HDCP 2.2 is mandatory for 4K UHD HDR content from streaming services (Netflix 4K, Disney+ 4K, Amazon 4K) and 4K Blu-ray. Key characteristics:

Key exchange: Uses RSA 3072-bit public key cryptography — fundamentally stronger than HDCP 1.4
Required for: 4K HDR content from any major streaming platform; 4K Blu-ray via compatible player
HDMI version: Requires HDMI 2.0 or higher on every link in the chain
Repeater depth: Maximum 4 repeater devices (shallower than HDCP 1.4)
Device limit: Maximum 31 downstream devices
Authentication time: Up to 7 seconds; longer than HDCP 1.4

The critical rule: Every device in the signal path — source, switcher, extender, scaler, and display — must support HDCP 2.2 for 4K HDR content to pass. A single HDCP 1.4-only device anywhere in the chain forces the source to downgrade to 1080p or black out entirely.

Minor update to HDCP 2.2. Adds locality checks (verifying the receiving device is physically nearby, blocking internet-based relay attacks). Backward compatible with HDCP 2.2 in practice; AV integrators rarely need to distinguish 2.2 from 2.3.

HDCP uses a three-phase handshake over the DDC (Display Data Channel) — the same I²C bus used for EDID:

Phase 1 — Authentication: Source reads the sink's BKSV (Broadcast Key Selection Vector), a 40-bit device identifier. Source verifies BKSV is not on the revocation list (KSV revocation list, or SRM — System Renewability Message). If the sink's key is revoked, authentication fails and content is blocked.

Phase 2 — Key Exchange: Source and sink exchange encrypted session keys. A shared secret is derived. From this point, the HDMI stream is encrypted with this session key.

Phase 3 — Repeater Authentication (if a repeater/switcher is in the chain): The repeater collects KSVs from all downstream devices and presents them to the source as a signed list. The source verifies the total device count is under 127 (HDCP 1.4) or 31 (HDCP 2.2), and the repeater depth is under 7 (1.4) or 4 (2.2). If either limit is exceeded, authentication fails.

Re-authentication occurs on every input switch event. A matrix switcher routing a new source to a display must re-authenticate HDCP from scratch — this is why there is a 1–7 second black screen delay when switching HDCP-encrypted sources.

Matrix switchers are the most common failure point for HDCP in AV systems. A matrix switcher is a repeater — it must:

Authenticate with every connected source (as a sink)
Authenticate with every connected display (as a source/repeater)
Present the downstream device list to each source on every route change

HDCP 2.2 matrix requirements: Every input port and every output port on the matrix must support HDCP 2.2 if 4K HDR sources will be routed. A matrix with HDCP 2.2 inputs but HDCP 1.4 outputs will strip HDCP 2.2 and downgrade the content — resulting in 1080p output or a black screen from the source.

Mixed-version matrices: Some matrices support HDCP 2.2 on a subset of ports (e.g., "4K HDMI 2.0 inputs on ports 1–4, HDMI 1.4 on ports 5–8"). Routing a 4K source through a non-2.2 output produces a black screen. Always verify per-port HDCP version in the matrix spec sheet.

Route change latency: Each route change forces HDCP re-authentication. With HDCP 2.2, this takes 3–7 seconds. Design the control system to account for this delay — do not assume instant display after a route command. Add a 7-second delay before showing a "source live" indicator on the touch panel.

HDBaseT carries HDCP natively — the protocol passes the DDC/HDCP authentication channel transparently over the Cat cable. Key points:

HDBaseT transmitters and receivers count as repeaters in the HDCP chain
A source → HDBaseT TX → HDBaseT RX → display chain has 2 repeater hops (TX and RX)
Adding a matrix switcher between source and HDBaseT TX adds another hop
HDCP 2.2 limit of 4 hops is easily exceeded in complex systems: source → scaler → matrix → HDBaseT TX → HDBaseT RX → display = 5 hops, which exceeds the limit

Some HDBaseT extenders terminate and re-originate the HDCP session rather than passing it through, resetting the hop count. Check manufacturer documentation — this behavior is device-specific.

AV-over-IP encoders present the most complex HDCP challenge because:

The encoder must authenticate with the source as an HDCP sink
The decoder must authenticate with the display as an HDCP source
The encoder/decoder pair must handle re-authentication on every route change in the virtual matrix

HDCP stripping: Some AV-over-IP encoders intentionally strip HDCP, decrypting the content at the encoder and transmitting unencrypted video over the network. This is technically illegal under the HDCP license agreement and can result in content playback failures for sources that verify HDCP compliance throughout the chain (4K streaming services, Blu-ray). Many corporate AV systems use this approach for convenience but accept the legal and compatibility risk.

Compliant AV-over-IP: Systems like Crestron DM NVX, Extron NAV, and SDVoE (SVS600) implement HDCP 2.2 end-to-end — the encoder authenticates with the source, the decoder authenticates with the display, and the encrypted stream is re-encrypted for transport. Route changes require re-authentication at the decoder side, causing the same 3–7 second black screen as a hardware matrix.

A display with multiple HDMI outputs (e.g., a display that passes HDMI through to a second display, or a capture card) is an HDCP repeater. Each additional output adds to the repeater device count. An HDCP 2.2 source with more than 31 downstream devices (across all branches of the repeater tree) will refuse to authenticate.

In practice this is rarely an issue in standard AV installs, but matters in:

Large video wall controllers with many downstream display tiles
Video production setups with multiple capture cards and monitors
Systems using HDMI splitters to feed many displays from one source

Single HDCP 1.4 device blocking 4K HDR. One HDCP 1.4-only device anywhere in the signal chain — a legacy scaler, an older HDBaseT extender, a non-4K-compliant switcher port — forces the source to downgrade from HDCP 2.2 or output a black screen. The failure is silent: the display shows nothing, and there is no error message on screen. Fix: audit every device in the chain for HDCP 2.2 support before commissioning a 4K system; replace or bypass any HDCP 1.4-only device in the 4K signal path.
Exceeding the HDCP 2.2 repeater depth limit of 4. Complex systems with source → scaler → matrix → HDBaseT TX → HDBaseT RX → display have 5 repeater hops, one more than HDCP 2.2 allows. The source fails authentication and outputs black. Fix: reduce hops by eliminating intermediate devices (connect source directly to matrix input, remove inline scalers); or use a device that terminates and re-originates the HDCP session to reset the hop counter.
Black screen after switching with no apparent cause. HDCP re-authentication on a matrix route change takes 3–7 seconds (HDCP 2.2). If the control system issues a route command and immediately checks for video, the display will be black — not because routing failed, but because authentication is in progress. Fix: add a 7-second delay in the control system logic after any route command before declaring success; use a video presence detection signal if available.
HDCP stripping causing 4K streaming failures. An AV-over-IP system that strips HDCP may work fine for local PC sources but fail to display Netflix 4K, Disney+ 4K, or 4K Blu-ray, because those sources check for valid HDCP 2.2 authentication at the encoder input and refuse to output 4K HDR if it is not present. Fix: use a compliant HDCP 2.2 AV-over-IP system for any signal chain that includes protected 4K content; or accept 1080p downgrade for stripped systems.
DDC/EDID line failure blocking HDCP. HDCP authentication travels over the DDC line (same as EDID). If the DDC line is interrupted — common with long HDMI cables, damaged connector pins, or some HDBaseT extenders — HDCP authentication cannot complete even if the video signal is present. Fix: use an active HDMI extender with DDC regeneration, or an EDID/HDCP emulator at the source output.
Revoked device KSV causing silent authentication failure. If a device's HDCP key has been revoked (KSV on the SRM revocation list), sources with an updated SRM will refuse to authenticate with it. This appears as a black screen with no error. Revocations are rare but happen after security breaches. Fix: check for SRM updates from content providers; replace the device with a revoked key.

HDCP — High-bandwidth Digital Content Protection

HDCP Versions

HDCP 1.4

HDCP 2.2

HDCP 2.3

How HDCP Authentication Works

HDCP in Matrix Switchers

HDCP in HDBaseT and Extenders

HDCP in AV-over-IP

HDCP and Multi-Output Displays

Common Pitfalls