{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/check-xprotect-integration-https-support-before-recording-server-encryption/", "item": { "id": "https://update.dsesecurity.com/updates/check-xprotect-integration-https-support-before-recording-server-encryption/", "slug": "check-xprotect-integration-https-support-before-recording-server-encryption", "url": "https://update.dsesecurity.com/updates/check-xprotect-integration-https-support-before-recording-server-encryption/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/check-xprotect-integration-https-support-before-recording-server-encryption.md", "json": "https://update.dsesecurity.com/api/v1/posts/check-xprotect-integration-https-support-before-recording-server-encryption/" }, "title": "Check XProtect integration HTTPS support before recording server encryption", "summary": "Milestone warns against recording server certificate encryption when an integration cannot use HTTPS. Check each stream consumer and its trust requirements before changing transport.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-28T23:23:32+00:00", "modified_at": "2026-10-28T23:23:38+00:00", "reviewed_on": "2026-10-28", "reading_minutes": 3, "word_count": 467, "potentially_affected": "XProtect 2026 R1 architecture and deployments planning certificate encryption for recording server communications.", "dse_recommendation": "Inventory stream-consuming integrations, obtain version-specific HTTPS evidence, and pilot each required path before rollout.", "primary_source": { "name": "Milestone Systems — Encryption (XProtect 2026 R1 architecture)", "url": "https://doc.milestonesys.com/xprotect/xprotect-system-architecture-guide/2026r1/en/encryption", "published_on": null, "authority": "doc.milestonesys.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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

\n

Source fact: documented behavior

\n

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

\n

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.

\n

What the source does not establish

\n

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.

\n

Applicability questions

\n\n

DSE recommendation: controlled next steps

\n

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

\n

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.

\n
    \n
  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. \n
  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. \n
  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.
    4. \n
\n

Verification and evidence

\n

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.

\n

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.

\n

Official references

\n\n

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

\n", "content_text": "Bottom line: Make integration compatibility a prerequisite for an XProtect recording server encryption change, with evidence for every required media consumer.\nSource fact: documented behavior\nThe Encryption topic is the primary reference for this XProtect 2026 R1 architecture discussion.\nMilestone 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.\nWhat the source does not establish\nThe 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.\nApplicability questions\n\nWhich applications and services retrieve streams from each recording server?\nWhat versions and supported HTTPS configurations do their manufacturers document?\nWhich service identities and computers need the issuing CA trust?\nWhat approved recovery route is available if a required integration fails the pilot?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\n\nBuild 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.\nHave 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.\nIn 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.\n\nVerification and evidence\nRetain 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.\nRequire 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.\nOfficial references\n\nEncryption — Milestone Systems; XProtect 2026 R1 architecture.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Make integration compatibility a prerequisite for an XProtect recording server encryption change, with evidence for every required media consumer.\n\n## Source fact: documented behavior\n\nThe [Encryption](https://doc.milestonesys.com/xprotect/xprotect-system-architecture-guide/2026r1/en/encryption) topic is the primary reference for this XProtect 2026 R1 architecture discussion.\n\nMilestone 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.\n\n## What the source does not establish\n\nThe 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.\n\n## Applicability questions\n\n- Which applications and services retrieve streams from each recording server?\n\n- What versions and supported HTTPS configurations do their manufacturers document?\n\n- Which service identities and computers need the issuing CA trust?\n\n- What approved recovery route is available if a required integration fails the pilot?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\n- 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.\n\n- 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.\n\n- 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.\n\n## Verification and evidence\n\nRetain 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.\n\nRequire 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.\n\n## Official references\n\n- [Encryption](https://doc.milestonesys.com/xprotect/xprotect-system-architecture-guide/2026r1/en/encryption) — Milestone Systems; XProtect 2026 R1 architecture.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/check-xprotect-integration-https-support-before-recording-server-encryption/", "url": "https://update.dsesecurity.com/updates/check-xprotect-integration-https-support-before-recording-server-encryption/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/check-xprotect-integration-https-support-before-recording-server-encryption/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Check XProtect integration HTTPS support before recording server encryption", "item": "https://update.dsesecurity.com/updates/check-xprotect-integration-https-support-before-recording-server-encryption/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/check-xprotect-integration-https-support-before-recording-server-encryption/#article", "identifier": "https://update.dsesecurity.com/updates/check-xprotect-integration-https-support-before-recording-server-encryption/", "url": "https://update.dsesecurity.com/updates/check-xprotect-integration-https-support-before-recording-server-encryption/", "headline": "Check XProtect integration HTTPS support before recording server encryption", "description": "Milestone warns against recording server certificate encryption when an integration cannot use HTTPS.", "abstract": "Milestone warns against recording server certificate encryption when an integration cannot use HTTPS. Check each stream consumer and its trust requirements before changing transport.", "articleBody": "Bottom line: Make integration compatibility a prerequisite for an XProtect recording server encryption change, with evidence for every required media consumer.\nSource fact: documented behavior\nThe Encryption topic is the primary reference for this XProtect 2026 R1 architecture discussion.\nMilestone 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.\nWhat the source does not establish\nThe 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.\nApplicability questions\n\nWhich applications and services retrieve streams from each recording server?\nWhat versions and supported HTTPS configurations do their manufacturers document?\nWhich service identities and computers need the issuing CA trust?\nWhat approved recovery route is available if a required integration fails the pilot?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\n\nBuild 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.\nHave 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.\nIn 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.\n\nVerification and evidence\nRetain 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.\nRequire 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.\nOfficial references\n\nEncryption — Milestone Systems; XProtect 2026 R1 architecture.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-28T23:23:32+00:00", "dateModified": "2026-10-28T23:23:38+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/check-xprotect-integration-https-support-before-recording-server-encryption/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/check-xprotect-integration-https-support-before-recording-server-encryption/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Check XProtect integration HTTPS support before recording server encryption" }, "articleSection": [ "Cybersecurity", "Video Surveillance" ], "keywords": [ "Cybersecurity", "Video Surveillance", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "wordCount": 467, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Milestone Systems — Encryption (XProtect 2026 R1 architecture)", "url": "https://doc.milestonesys.com/xprotect/xprotect-system-architecture-guide/2026r1/en/encryption" } } ] } }