.webp)
Almost every enterprise conversation I’ve had since I joined the Xyte team has reached the same point. The demo goes great, the use case fits like a glove, and then someone from IT leans in: "Before we go any further, we need to talk about security."
Fair enough. These folks are responsible for production environments that run critical infrastructure. They’ve learned to ask hard questions before signing anything.
After fielding these conversations across multiple enterprise accounts, a clear pattern has emerged. The same seven questions surface time and again, in roughly the same order. Here they are, along with my answers:
1. Where is Xyte data stored, and who has access to the data?
All Xyte data resides on AWS infrastructure in the EU, encrypted in transit via TLS 1.2+ and encrypted at rest at both the disk and database level.
On ownership, data falls into two categories. Device data - telemetries, commands, incidents - is owned by the manufacturer. Organizational data belongs to its respective organization, whether that's a manufacturer, channel partner, or end customer. Each organization accesses its own data through its own portal - no organization can see another's data.
Within Xyte, access to customer data is restricted to a limited number of personnel, scoped by role, and reviewed by an external auditor on a regular basis. For a full breakdown of data types and retention practices, Xyte's Privacy Policy covers the details.
2. What personal information is available to Xyte employees and what is shared with partners?
The Xyte platform is designed to avoid collecting personally identifiable information beyond what's necessary to operate the service: names, email addresses, and billing and shipping addresses. This data is only collected for the operators of the platform (e.g. the IT/AV team administering the tenant), and not for the organization’s users. The data is accessible only to the organization that provided it and to parties that require it to deliver a product or service.
Within Xyte, access is restricted by role and limited to personnel who need it to operate and support the platform. Xyte does not sell or share personal data.
Externally, data is shared with service providers who support platform operations - cloud infrastructure vendors, payment processors, and similar - under contractual obligations that restrict how they can use it. A full list of subprocessors is available in Xyte's documentation portal, and additional details on data sharing practices are covered in the Privacy Policy.
3. Is the device claiming process actually secure?
One concern I hear frequently is about MAC address and serial number - specifically, whether those credentials are strong enough to prevent an unauthorized party from claiming a device. The answer has a few layers.
First, the device claiming process is built around proof of physical ownership. Xyte supports multiple authentication methods - MAC address and serial number for manufacturers who want a credential tied to the device itself, its packaging, or the reseller post-purchase, and a Device Cloud ID for those who want an identifier that isn't printed on the outside of a box.
Second, the platform enforces a hard rule: each device may only be claimed by one organization and located in a single space. A device cannot be moved to another customer without deleting the full device history and re-claiming the device from scratch.
Third, all API communications involved in the claiming process require authentication and run over encrypted transport, so the exchange itself isn't exposed in transit.
4. Do we need to open inbound firewall ports or set up a VPN?
This is the question that comes up the moment IT hears "cloud-connected AV devices." The assumption is that cloud management means opening the network up - inbound ports, VPN tunnels, firewall exceptions. It doesn't.
Xyte's architecture is outbound-only. All communication between devices and the Xyte cloud is initiated from within the customer network, never from outside it. No inbound firewall ports need to be opened. No VPN is required.
The specifics: the interface runs over port 443, devices connect to the server over HTTPS (port 443) and MQTTS (port 8883), and all traffic runs to allow listed *.xyte.io subdomains. Remote tunnelling, when enabled, uses a dedicated tunnelling server, requiring different ports - still outbound, still controlled. Everything in transit is encrypted via TLS 1.2+.
5. We manage multiple customers. How is their data separated?
The question behind this question is actually: if something goes wrong in one customer environment, what's the exposure to others?
Customer environments on Xyte are isolated at the platform level. One customer's data cannot be accessed by another regardless of who manages them, and that holds whether you're running two customers or two hundred. This is especially important to MSPs operating multiple end customers through a single tenant.
On the question of what Xyte itself can see: our data collection is deliberately narrow. The platform is designed to avoid collecting personally identifiable information about end customers or users, which limits exposure and simplifies compliance obligations for the MSP and their customers alike.
All Xyte data resides on AWS infrastructure in the EU, encrypted in transit via TLS 1.2+ and encrypted at rest at both the disk and database level. Access to customer data within Xyte is restricted to a limited number of personnel. And our access logs are audited internally and by an external auditor on a regular basis.
6. Do you support SSO, and can we enforce MFA across all users?
For enterprise IT teams, SSO is often a condition of vendor approval. The ability to enforce authentication policy centrally, through the identity provider the organization already uses, is a hard requirement for a lot of accounts.
Xyte supports SAML-based SSO, which integrates with mainstream enterprise identity providers - Okta, Azure AD, and similar platforms. MFA can be enforced at the organization level, so it's not left to individual users to opt in.
Role-based access control (RABC) lets administrators define what each user can see and do, scoped to the appropriate level - a single space, a customer environment, or the full platform. We apply the principle of least privilege wherever possible – meaning that Xyte's own access to production systems is restricted by role and necessity. Any administrative actions are logged for traceability.
7. We need documentation for a formal security questionnaire. What do you have?
This question usually comes at the end of the technical conversation, once IT is satisfied. What it really means is: can you make it through our procurement process?
Xyte holds SOC 2 Type II certification that is audited annually by an independent third party and covers security, availability, and confidentiality controls. That's typically the first document an enterprise security team asks for. Beyond that, Xyte supports GDPR and CCPA compliance, maintains a published Data Processing Agreement, and provides a list of subprocessors used for infrastructure and service delivery in our documentation portal.
Additional documentation is available on request - including internet access requirements, edge security documentation, and security and privacy FAQs. Penetration testing is conducted on a regular basis, and results are available under NDA for accounts that require them. For anything requiring deeper review, our security team is reachable directly at support@xyte.ai.
The Bottom Line
The security conversation doesn't have to slow a deal down. For the vast majority of questions coming from enterprise IT teams, we have clear, documented answers - and the architecture itself does a lot of the work. Outbound-only connectivity, logical data isolation, SOC 2 Type II certification, and enforced identity controls aren't features we added to check a box. They're the foundation the platform was built on.
If you're heading into an enterprise evaluation and want to walk through the security posture in detail, we're happy to do that. Book a demo and we'll make sure your IT team gets the answers they need.
.webp)
