Security Overview¶

This page provides a high-level overview of how 3D Immersive Services protects customer data and controls access to the platform. It is intended for customers who are onboarding to the service and want to understand the security principles behind it, without going into internal implementation detail.

Tenant Isolation and Data Segregation¶

3D Immersive Services is a multi-tenant SaaS platform, which means many customers share the same underlying infrastructure while their data remains completely separate.

• Every customer is provisioned as a tenant. All projects, files, and configuration created by a customer are tied to that tenant.
• Every request to the platform is validated against the identity of the authenticated user and the user's assigned tenant. Data belonging to one tenant is never returned to, or accessible by, another tenant.
• Data isolation is enforced consistently across the API, storage, and processing layers of the platform, not just in a single place, so there is no single point where a mistake could expose data across tenants.
• Backups, exports, and any temporary processing of data respect the same tenant boundaries as normal operation.

In short: your data is separated from every other customer's data at every layer of the platform, and access is always scoped to your own tenant.

Authentication and Security Framework¶

Authentication answers the question "who are you?". 3D Immersive Services does not implement its own username/password system. Instead, it relies on industry-standard identity providers and protocols:

• User sign-in is handled through Siemens ID, using the industry-standard OpenID Connect (OIDC) protocol (built on top of OAuth 2.0). This is the same standard used by many enterprise and consumer platforms. Siemens ID is Siemens' enterprise identity platform, which is centrally managed and subject to Siemens' own security and compliance standards.
• Credentials (passwords, multi-factor authentication, etc.) are never handled or stored by 3D Immersive Services itself — they stay with the identity provider, reducing the risk of credential leakage.
• All communication between users, applications, and the platform is encrypted in transit (HTTPS/TLS).
• Every API call and every interactive session must present a valid, time-limited token issued by the identity provider. Expired or invalid tokens are rejected.
• The platform follows standard identity and access management (IAM) practices, such as short-lived tokens, token validation on every request, and the ability to revoke access centrally through the identity provider.

Authorization and Access Control¶

Authorization answers the question "what are you allowed to do?", once a user's identity has been established.

• Access to a customer's data is only granted to users who have been explicitly authorized by that customer. Being able to authenticate does not, by itself, grant access to any tenant's data.
• The platform uses role-based access control (RBAC). Each user is assigned one role (i.e. Guest or Engineer), and each role defines a specific set of permissions.
• Customer administrators manage their own users and roles: they decide who can be invited, which roles they receive, and when access should be revoked.
• Permission checks are enforced on every request, ensuring a user can only perform actions and access data that their assigned role and tenant membership allow.
• Changes to user access take effect centrally, so access can be revoked immediately when needed, for example when an employee leaves a customer's organization.

Summary¶

This document intentionally omits internal implementation details, such as infrastructure design or specific security controls, in order to keep the information suitable for external sharing. More detailed, contractual, or audit-related security information can be requested through your Siemens contact.