> ## Documentation Index
> Fetch the complete documentation index at: https://docs.altoura.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Data Security & FAQ

> Why ACS and the Entra ID app are provisioned in your tenant, plus answers to common security-review questions about Altoura Remote Expert.

This page explains why the two components your IT team provisions ([ACS](/frontline/administration/remote-expert-it-admin/deploy-acs-resource) and the [Entra ID app registration](/frontline/administration/remote-expert-it-admin/azure-app-registration)) live in your tenant, and pre-answers common security-review questions. The answers describe how the system is designed to work.

## 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](#appendix-a-requested-permissions)) 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

<AccordionGroup>
  <Accordion title="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.

    **How Altoura handles it:** the ACS connection string is stored as a protected configuration value per customer domain in the Altoura database — because Altoura serves many customer organizations, each tenant's credentials are held in this per-customer store rather than as a single application setting. The values are not in source code, the database is encrypted at rest (Azure SQL Transparent Data Encryption) and accessed only over TLS; platform-level secrets are additionally managed in Azure Key Vault. The value is read at request time to mint short-lived ACS tokens and is not logged. Rotation is supported without application downtime: because the value is not cached across requests, updating the stored connection string takes effect immediately.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

### Identity, permissions & consent

<AccordionGroup>
  <Accordion title="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](#appendix-a-requested-permissions) for the full list and purpose of each.
  </Accordion>

  <Accordion title="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.

    In the meeting flow, the Teams client obtains an SSO token from the multitenant app; the Altoura backend validates it (tenant and audience claims) and then acts on behalf of that user. No separate username/password is collected by Altoura.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

### Data protection

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

### Network & isolation

<AccordionGroup>
  <Accordion title="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.com` and `wss://altourateamsapp.webpubsub.azure.com`
    * Standard Microsoft Teams, Microsoft Graph, and Azure Communication Services endpoints.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

## Appendix A — Requested Permissions

### Microsoft Graph

| Permission                                | Type      | Purpose                                           | Admin consent |
| ----------------------------------------- | --------- | ------------------------------------------------- | ------------- |
| Chat.ReadWrite                            | Delegated | Read and write the user's chat messages           | No            |
| Contacts.Read                             | Delegated | Read the user's contacts (expert search)          | No            |
| offline\_access                           | Delegated | Maintain access / silent token renewal            | No            |
| OnlineMeetings.ReadWrite                  | Delegated | Read and create the user's online meetings        | No            |
| openid                                    | Delegated | Sign the user in                                  | No            |
| profile                                   | Delegated | View the user's basic profile                     | No            |
| TeamsAppInstallation.ReadWriteSelfForChat | Delegated | Allow the Teams app to manage itself in chats     | Yes           |
| User.Read                                 | Delegated | Sign in and read the user's profile               | No            |
| User.Read.All                             | Delegated | Read all users' full profiles (as signed-in user) | Yes           |

### Azure Communication Services

| Permission        | Type      | Purpose                                   |
| ----------------- | --------- | ----------------------------------------- |
| Teams.ManageCalls | Delegated | Manage calls in Teams (real-time session) |
| Teams.ManageChats | Delegated | Manage chats in Teams (real-time session) |