Why These Components Live in Your Tenant
Azure Communication Services — your tenant
Remote Expert joins calls as the actual signed-in Teams user — not as a guest or bot. The backend exchanges each user’s Teams identity for an ACS calling token. The ACS resource is provisioned in your tenant so that your users join meetings created in your tenant as internal participants: when the ACS resource sits outside the user’s tenant, participants are treated as external and must be admitted from the meeting lobby. Hosting ACS in your tenant also keeps call media in your Azure environment, in the region you choose — and the keys remain yours to rotate, monitor, or revoke at any time, giving you full control over the integration.Microsoft Entra ID app registration — your tenant
The app registration enables Teams SSO: it verifies each meeting participant’s identity inside the Teams meeting, with no separate usernames or passwords collected by Altoura. It also grants the delegated Microsoft Graph permissions (see Appendix A) that let the backend act strictly as the signed-in user — for example creating the meeting and sending invites as that user — never on its own. Because the registration lives in your tenant and is consented by your admin, you control the permissions and can revoke consent at any time.Frequently Asked Questions
Your two key questions
Will Altoura misuse our ACS key / connection string?
Will Altoura misuse our ACS key / connection string?
The ACS connection string is shared with the Altoura backend for one purpose: to mint short-lived ACS access tokens so meeting participants can join the real-time Remote Expert session. Its use is limited to issuing scoped ACS access tokens for these sessions.Scope of the key: the connection string authenticates only to your ACS resource. It cannot be used to reach your other Azure resources, your Microsoft Graph data, or your tenant settings — its blast radius is limited to that single ACS resource, which lives in your tenant.You stay in control:
- You can rotate/regenerate the ACS keys at any time in the Azure portal, which immediately invalidates the shared key.
- You can monitor all usage of the ACS resource via Azure Monitor metrics and logs in your own tenant.
- We recommend periodic key rotation as policy; provide the new value to Altoura via a secure channel.
Will the contacts shown in the Remote Expert contact list be used or stored by Altoura?
Will the contacts shown in the Remote Expert contact list be used or stored by Altoura?
The Frontline app retrieves a contact list on behalf of the signed-in user so that an expert can be found and invited to a session. This read uses delegated Microsoft Graph permissions, and the signed-in identity (tenant and user) is derived transiently from the Teams SSO token; neither the contact list nor the identity is stored by the web app.Where contact or directory data is read (for example, expert search / invite in the broader Frontline product), it uses delegated Microsoft Graph permissions (
Contacts.Read, User.Read.All) — read strictly on behalf of the signed-in user, only while they are signed in, and only data that user is already permitted to see.Contact and directory data is fetched transiently from Microsoft Graph and is not cached or retained by the Altoura backend. On each request the backend calls Graph, returns the result to the client, and does not write that directory payload to Redis, the database, or any other store; there is no application-side cache.That data is used only to support delivery of the Remote Expert session. Altoura does not sell, license, or share it with unrelated third parties, and does not use it for advertising or analytics — consistent with Altoura’s Data Processing Agreement and Privacy Policy.Identity, permissions & consent
What permissions does the app request, and are they delegated or application?
What permissions does the app request, and are they delegated or application?
All Microsoft Graph permissions used by the Remote Expert integration are delegated — they act only on behalf of the signed-in user. Delegated
User.Read.All lets a signed-in user list eligible experts and resolve participant identities. See Appendix A for the full list and purpose of each.How is sign-in handled, and how many Entra apps are involved?
How is sign-in handled, and how many Entra apps are involved?
Two Entra ID applications are used, with different scopes:
- Application sign-in — the Altoura Frontline application authenticates users through a single-tenant Entra ID app (limited to your tenant).
- Teams meeting verification — the multitenant Entra ID app covered in this guide is used only to verify users within the Teams meeting via Teams SSO, so participants from different tenants can be authenticated during a remote assist session.
Why is the meeting-verification app multitenant — is that less secure?
Why is the meeting-verification app multitenant — is that less secure?
Only the Teams meeting-verification app is multitenant; your primary application sign-in remains single-tenant (your tenant only). The meeting app must be multitenant because a remote assist meeting can include participants from different organizations, and each must be verifiable.Multitenant only means users from tenants that have granted consent can authenticate. Each tenant grants its own admin consent and controls its own data; it does not give Altoura any access to your tenant beyond the delegated scopes you consent to.
How are the client secret and ACS key rotated, and how are secrets stored?
How are the client secret and ACS key rotated, and how are secrets stored?
Both are customer-owned. You can regenerate the client secret (Certificates & secrets) and the ACS keys (ACS → Keys) at any time and provide the new values to Altoura via a secure channel. We recommend a client secret lifetime of 180 days or less and rotation before expiry.On the Altoura side, the client secret and ACS connection string are stored per customer domain in the Altoura database (not in source, and not as Azure App Service application settings) and are loaded at request time for token exchange, meeting creation, and ACS token issuance; they are not logged. Platform-level secrets are stored in Azure Key Vault and loaded at startup, on a path separate from the per-tenant ACS credentials.
Data protection
Is data encrypted in transit?
Is data encrypted in transit?
Yes. Altoura’s Azure App Service is configured HTTPS-only with a minimum TLS version of TLS 1.2; all client traffic to the Altoura API/portal is terminated using TLS 1.2 or higher (TLS 1.3 where the client supports it). File uploads use HTTPS to Azure Blob Storage, and ACS real-time media uses Microsoft’s encrypted media transport.
Is data encrypted at rest, and what does Altoura store?
Is data encrypted at rest, and what does Altoura store?
Altoura storage accounts use Azure Storage Service Encryption (SSE) at rest with Microsoft-managed keys (the Azure default).The backend persists only operational Remote Expert data: short-lived Microsoft Graph tokens and meeting-to-session mappings in Redis; call audit records in Azure SQL; and session collaboration artifacts (backgrounds, canvas uploads, annotations) in Azure Storage, with annotation data subject to a ~24-hour retention window. Microsoft directory/contact data is not retained.
Are Remote Expert sessions recorded?
Are Remote Expert sessions recorded?
Altoura Remote Expert does not implement its own audio/video recording. Sessions run as Microsoft Teams online meetings; any recording is governed by Teams-native recording and your Microsoft 365 / Teams policies. Altoura’s application code does not start, store, or process call recordings.
Where is data stored (residency)?
Where is data stored (residency)?
Your ACS data resides in the ACS Data location you selected when creating the resource, within your Azure tenant.The Altoura-hosted backend and its data stores for this integration run in Microsoft Azure — West US 2 (App Service API, Azure SQL, Azure Storage, Redis, and Key Vault). Data Altoura processes or persists for this service remains in West US 2.
Network & isolation
What endpoints need to be allowlisted?
What endpoints need to be allowlisted?
- Remote Expert web app:
https://remote-expert-web.altoura.com - Secure API / portal:
https://api.altoura.com,https://portal.altoura.com,https://login.altoura.com,https://apivnext.altoura.com - Blob Storage:
https://altourajade.blob.core.windows.net· Storage CDN:https://altouranext.azureedge.net - Web PubSub:
https://altourateamsapp.webpubsub.azure.comandwss://altourateamsapp.webpubsub.azure.com - Standard Microsoft Teams, Microsoft Graph, and Azure Communication Services endpoints.
How is one tenant's data isolated from another?
How is one tenant's data isolated from another?
Tenant data is logically isolated by
OrganizationID in a shared Azure SQL database, with access enforced through authenticated user–organization roles; Remote Expert Graph/ACS configuration is isolated per SSO domain. Where required, dedicated Azure deployments provide physical separation; otherwise Redis and Storage are shared per deployment with entity-level (session / project) partitioning.In the meeting flow, the backend also identifies each session by the tenant (tid) and audience claims in the validated SSO token, and all Graph access is delegated to the signed-in user.