--- title: "The Polaris Cloud: What It Does, What It Holds, and What Your Content Never Touches | Mersive" canonical: https://www.mersive.com/resources/blog/cloud-trust description: "An architecture read for the people who have to sign off on a cloud-connected meeting room: the two jobs the cloud does, the path a share actually takes,…" published: 2025-06-12 language: en-US publisher: Mersive Technologies --- [Home](https://www.mersive.com/) /[Blog](https://www.mersive.com/resources/blog) /SECURITY & COMPLIANCE SECURITY & COMPLIANCE # The Polaris Cloud: What It Does, What It Holds, and What Your Content Never Touches An architecture read for the people who have to sign off on a cloud-connected meeting room: the two jobs the cloud does, the path a share actually takes, what is held about your fleet, and the evidence behind all three. June 12, 20259 min read Every wireless collaboration platform that manages rooms centrally has a cloud somewhere, and every security review eventually asks the same three questions about it: what does it do, what does it hold, and where does my content actually go. Those questions deserve a durable answer rather than a reassurance. This is that answer for Mersive Polaris, written to be read once and cited later. Architecture first, then data handling, then the independent evidence behind both - including the parts that are deliberately not claimed. THE SHORT ANSWER - Mersive Polaris Cloud does two jobs: it introduces sessions so endpoints can find each other, and it runs the fleet. It does not store workspace content. - Same-network sessions stay on your LAN. Cross-network sessions are a direct, encrypted WebRTC connection between the sharing device and the display, so shared content does not transit Mersive. - All cloud traffic is outbound TLS on TCP 443 from both sides: no inbound firewall rules, and no bridging of networks that were separated on purpose. - Room names, session names, device metadata, operating-system information and anonymized usage data are classified Confidential under the data-management policy the auditors reviewed. - The SOC 2 Type 2 scope is the cloud management console and says so in one sentence; the room devices are excluded from it and are tested independently in their own right. Start with the boundary ## Two jobs, and only two. Polaris Cloud does session brokering and fleet operations. Session brokering is the signaling that lets a sharing device and a room display find each other, including across networks that do not route to one another. Fleet operations is the administrative plane: analytics by room, building and hour; activation and licensing; bulk configuration with templates; staged firmware; alerts and health; and idle-display signage from the same portal. What it does not do is store what people share. The workspace is composited by the room's own hardware and rendered to the display and to every participant's browser; the cloud introduces the connection and then stays out of the picture. That single sentence is the boundary the rest of this piece elaborates, and it is the one worth putting in front of a reviewer first, because it decides how much of the remaining conversation is even necessary. The data path ## Where a share actually goes. When a source and a display are already on the same network, the connection is negotiated with local addresses only and never leaves the LAN. Nothing about the on-network case involves a round trip through a data center. When they are not - a guest on LTE, a laptop on another VLAN, a team in another building - the share does not try to route to the display, because no route exists and none will be created. The sharing device opens an outbound TLS session on TCP 443 to the signaling service instead. The cloud exchanges connection details between the two endpoints, and they negotiate a direct, encrypted WebRTC connection between themselves. Content then flows device to display over that connection. - What reaches the cloud: session signaling - the connection details the two endpoints need in order to find each other. Not your screen. - What stays on your network: same-network sessions, negotiated with local addresses and never leaving the LAN. - What never happens: inbound firewall rules, or any bridging of your networks. Cloud traffic is outbound TLS on TCP 443 from both sides, and a guest device gets zero access to your network - the workspace is the only shared surface. - Where it does not work: networks behind symmetric NAT, which assigns a different external port for every destination, so a direct connection cannot be formed. The diagnostic tool tests for that condition specifically and tells you before you deploy. ![Conceptual cross-network path: sources and the display establish outbound sessions, and no inter-VLAN route exists or is created.](https://www.mersive.com/blog/poc-cross-network.png) Conceptual cross-network path: sources and the display establish outbound sessions, and no inter-VLAN route exists or is created. Data handling ## What the cloud holds about your fleet. "We do not sell your data" is not an answer to the question a security reviewer is asking. The specific answer is a classification, and it comes from the data-management policy that sits inside the audited control environment: room names, session names, device metadata, operating-system information and anonymized usage data are all classified Confidential, on a Confidential, Restricted and Public scale where Restricted is the default. That is the shape of what a fleet management plane necessarily knows - which rooms exist, which devices are in them, what firmware they run, whether they are online, how often they are used. It is also the reason the content boundary above matters so much: the management plane is deliberately a metadata system, and the thing it does not carry is the thing people are usually worried about. Resilience ## What sits underneath, and how it is examined. The cloud runs on Google Cloud, with firewall rules and access controls around it, TLS from a public certificate authority in transit, administrative access behind IAM and multi-factor authentication, and failover across multiple availability zones. Availability is not left as an adjective, either. It is one of the three trust services criteria the SOC 2 examination covers, alongside security and confidentiality, so an independent CPA firm tests the controls behind it rather than taking the claim on trust. Business continuity and disaster recovery is one of fourteen named policies the Security Committee reviews and approves every year - and that annual review is itself an audited control, which is the difference between a policy and a policy that happens. The honest counterweight belongs in the same paragraph: no infrastructure is immune to failure, and the architecture above is designed so that the blast radius of a bad day is bounded. Same-network sharing does not depend on a round trip through the cloud, and content never depended on it in the first place. The evidence, and its scope ## Attested - and the scope sentence is the point. The SOC 2 Type 2 and SOC 3 reports name their system in one sentence, and the system they name is the cloud management console. The examination was performed by BARR Advisory, P.A. for the period 1 March to 31 May 2025, opinion dated 15 July 2025, on security, confidentiality and availability. Mersive SMART, Mersive Essentials and Mersive Pro are excluded from the attested system - the entity-level controls behind those products are audited, because a SOC 2 examines the control environment of the company, but the products themselves are not inside the boundary. Publishing that exclusion is deliberate. A reviewer opens the report and reads the scope sentence first, so it should not be a surprise when they get there - and the honest version is also the stronger one, because the products get their own independent testing rather than borrowing the cloud's. - 46 controls across 11 families were examined, and the report records a single exception, on the HR control covering annual employee performance evaluations. It is a people-process control: nothing in access control, encryption, logging, change management, vulnerability management or incident response was excepted, and management's response is published in the report alongside it. - The opinion also covers controls implemented to meet 45 C.F.R. section 164.308, the HIPAA Security Rule administrative safeguards. That is inside the auditor's opinion, not a separate letter and not a self-assessment. - A control-by-control mapping of NIST SP 800-171 Rev. 2, as required by DFARS, is published inside the report, and the report also maps our controls to HITRUST CSF v11.5. A mapping is not a HITRUST certification and this piece will not pretend otherwise; it is the translation work already done for a healthcare reviewer. - SOC 3 is the general-distribution report and can be published. SOC 2 Type 2 goes out under NDA. The management system ## ISO 27001, and the discipline that goes with it. Mersive holds ISO/IEC 27001:2022 certification - certificate 011964-03, issued by BARR Certifications LLC on 30 June 2026, registered 28 June 2024 and valid to 26 June 2028, audited against a statement of applicability dated 18 June 2026. The second annual surveillance audit, completed June 2026, closed with no nonconformities: every clause assessed and the Annex A control testing came back as design and operating effectiveness met, with nothing carried over from the prior year. Two exclusions, both re-validated in June 2026: the physical-security controls of Annex A.7, because customer data sits in Google Cloud rather than in a Mersive data center, and A.8.30 outsourced development, because there is none - nobody outside Mersive writes this software. The management system operates in a fully virtual environment with no physical locations in scope, and all sixty employees are inside it. One piece of discipline is worth spelling out, because it is a certification requirement rather than a stylistic choice: a management-system certificate certifies a management system, never a product. So no Polaris device is "ISO 27001 certified", and no page on this site will say so. Product-level assurance has to rest on evidence about the product, which is what the next section is. Independent testing ## Someone else attacks it, and the result is stated without decoration. Annual third-party penetration testing is a commitment inside the SOC 2 report rather than a marketing habit, and four engagements across 2025 and 2026 are on file. The most recent application assessment ran in July 2026 against OWASP ASVS 5.0.0 - every Level 1 control plus a subset of Level 2, a higher bar than the year before - and returned no critical and no high-severity findings. Publicly reachable endpoints were probed for account information and found free of defects. What held up under testing, in the assessor's own terms: token integrity and signature validation, object-level authorization on tenant-owned records, injection and output-encoding defenses, mass-assignment protection, and client-side component currency. On authentication specifically, every in-scope token-handling control passed - forged, mutated, truncated, expired and foreign-project tokens were all rejected, including a genuine token from a different project signed by the same provider key. Every assessment produces a finding list and ours is no exception; the severity summary is the part that decides whether a finding matters, and the full reports go to customers under NDA on request. The discipline that keeps a section like this honest is refusing to state anything the report does not support end to end - including any property whose executive summary reads better than its detail sections do. No critical and no high-severity findings is true, and it is sufficient. The other half of the fleet ## The room device is tested on its own terms. Because the attestation stops at the console, the device behind the display gets its own evidence. In the same July 2026 engagement, network testing of a managed Pod surfaced no significant attack surface: the ports that answer are the casting and appliance functions, and no persistent media listener was enumerable at all, because the real-time media path uses ephemeral, per-session UDP ports that answer only after ICE consent. There is no standing media service on the room device to probe. That is a fact a port scan can establish and an attestation never could, which is exactly why the hardware is tested rather than described. The takeaway ## Four questions worth asking any cloud-connected room vendor. None of this is Mersive-specific as a method. If you are evaluating any platform that puts a managed device in a room and a management plane above it, these are the questions that separate an architecture from an assurance: - What does the cloud do - broker, or carry? Ask for the data path, and ask what reaches the vendor when a guest on a phone shares to a display. - What is held about my fleet, and under what classification? A specific list beats a promise. - What is the scope sentence of the certificate or attestation, verbatim? A management-system certificate is not a product certification, and a cloud attestation is not a statement about the box on the wall. - Who tests the device itself, how recently, and against which standard? If the answer is only the cloud's certification, the hardware has no evidence of its own. The full architecture, every scope statement and the audit findings live in the Trust Center, ungated. That is the point of publishing them: a security read that requires a form is a security read nobody finishes. [Open the glossary *›*](https://www.mersive.com/resources/glossary) [‹ All blog posts](https://www.mersive.com/resources/blog)