Check XProtect integration HTTPS support before recording server encryption

Bottom line: Make integration compatibility a prerequisite for an XProtect recording server encryption change, with evidence for every required media consumer.

Source fact: documented behavior

The Encryption topic is the primary reference for this XProtect 2026 R1 architecture discussion.

Milestone warns against using certificates with recording server encryption when any integration does not support HTTPS, including some third-party MIP SDK integrations. The architecture separates recording server communication with stream-consuming clients, servers and integrations from other encrypted communication paths. It requires the public CA certificate to be trusted on client computers. Its server-certificate requirements include the server host name and access to the private key for the service account running the server.

What the source does not establish

The cited 2026 R1 architecture page does not establish that a particular plug-in version, export service or other consumer supports HTTPS. It also does not verify installed trust stores or permissions. An encryption setting and a certificate inventory do not constitute a completed compatibility assessment.

Applicability questions

• Which applications and services retrieve streams from each recording server?
• What versions and supported HTTPS configurations do their manufacturers document?
• Which service identities and computers need the issuing CA trust?
• What approved recovery route is available if a required integration fails the pilot?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends treating this as a dependency change with named owners. Use a representative recording server and the actual types of integrations required by the operation.

1. Build a consumer register. Record application, version, owner, server endpoint, service identity and the evidence supporting its HTTPS capability. Include unattended jobs and specialist integrations in the review, and leave uncertain capability explicitly unresolved.
2. Have the system owner reconcile the certificate subject or DNS names, issuing CA, client trust and service-account access with the vendor requirements. Keep private keys and passwords out of the assessment record. Obtain the relevant integration supplier’s guidance when its documentation is incomplete.
3. In an approved pilot, exercise each required retrieval workflow using the planned encrypted path. Include operator viewing and the specific integration tasks in scope. Assign a result to every consumer and resolve failures before scheduling a broader change.

Verification and evidence

Retain the dependency register, supplier references, versions, certificate identifiers, trust checks and redacted results for each workflow. Record the intended endpoint and identity alongside the observed outcome so a later review can distinguish compatibility from a configuration error.

Require the operational owner to accept the complete consumer set. Reopen the assessment after a plug-in, server or service-account change. This proposed verification does not claim that any customer integration has been tested or that encryption guarantees overall system security.

Official references

• Encryption — Milestone Systems; XProtect 2026 R1 architecture.

Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.