Why We Built Atlas AVD Inside Your Azure Tenant Instead of as Traditional SaaS

By David, 2026-09-08

Many IT management platforms ask you to do the same thing on day one: connect your environment to their cloud. You grant a vendor-hosted service access to your tenant, its servers pull in data about your users and machines, and from then on the tool that runs your estate lives somewhere you can't see.

That model has real strengths, and plenty of excellent products are built on it. When we designed Atlas AVD, though, we made a different call, and it shaped almost every architectural decision that followed:

Wherever it's technically practical, the infrastructure that manages and operates your environment is deployed inside your own Azure subscription, not in ours.

This article explains what that means in concrete terms: what runs in your subscription, what Atlas still operates centrally, what crosses the line between the two, and what happens if Atlas is unreachable. Where the honest answer is "this still depends on us," we say so.

Two ways to build a management platform

The traditional SaaS model

In a conventional SaaS management platform, the vendor runs the application, the database, and the automation engine in its own cloud. Your environment connects to it:

• the vendor's service holds credentials, tokens, or delegated access to your tenant;
• inventory, telemetry, and configuration flow from your environment into the vendor's databases;
• scheduled jobs (scaling, patching, scripts) run on the vendor's infrastructure and reach into your environment to act;
• the vendor's administrators, identity system, monitoring stack, and subprocessors sit behind the service.

None of that is inherently insecure. Well-run SaaS vendors invest heavily in isolation, encryption, audits and incident response. The point is narrower: SaaS adds another operational boundary, owned by someone else, that your organization has to understand, evaluate, govern, and often include in its risk and compliance analysis.

The Atlas model

Atlas AVD inverts that. When you deploy it, the management application, its database, its secrets, and its automation run as ordinary Azure resources in a resource group in your subscription. Atlas still operates a small set of central services (licensing, billing, release distribution, and a few others covered below), but the system that holds your data and acts on your environment is yours.

It's worth being clear that deploying into the customer's subscription isn't unique to Atlas among AVD tools. Nerdio, for example, documents its Nerdio Manager for Enterprise as deployed into the customer's own subscription. The sharper contrast is with SaaS-delivered IT management, RMM and remote-support tools generally. That's also where Atlas extends the same in-tenant pattern beyond AVD, to remote support, documentation, email signatures and printing.

What actually runs in your subscription

"Runs in your tenant" gets used loosely, so here is the specific inventory. The standard Atlas AVD deployment creates these resources in a resource group you choose:

Alongside those resources, Atlas uses an app registration in your Entra ID directory. It's a single-tenant registration that you own: you can see its permissions, rotate its secret, or delete it without involving us. Users sign in to Atlas with Entra ID through that registration.

The modules follow the same pattern. Each one is part of the same application in your subscription rather than a separate vendor service:

So when someone asks "where is our Atlas data?", the answer isn't a region on a vendor's trust page. It's a PostgreSQL server in a resource group you can open in the Azure portal.

What does "your Azure boundary" actually mean?

"Your data never leaves Azure" is easy to write, but it's vague and misses the point. Data can stay inside Azure and still sit in someone else's subscription. What matters is who owns the resources, who controls access to them, and what crosses the line.

With an in-subscription deployment, several things follow from ordinary Azure mechanics rather than from anything Atlas promises:

• Ownership. The resources belong to your subscription. You pay Microsoft for them on your own Azure bill, and they live and die with your resource group.
• Access control. Azure RBAC on the subscription and resource group decides who can touch the app, the database, and the vault. Atlas staff have no Azure role on your subscription, and the Atlas application contains no vendor support or remote-access path into your deployment.
• Visibility. You can inspect every resource, its configuration, its role assignments, and the permissions granted to the app registration.
• Activity history. Changes to these resources, and the changes Atlas makes to your AVD estate through its app registration, appear in your Azure Activity Log. Application and database diagnostics flow to the Log Analytics workspace the deployment creates, which you can retain, query, or forward like any other.
• Policy. Azure Policy assigned at your subscription or management group applies to these resources the same way it applies to anything else you run. A policy that denies public network access to Key Vault or PostgreSQL, for example, pairs with the deployment's private-endpoint option.
• Networking. PostgreSQL and Key Vault sit behind private endpoints on the deployment's own virtual network by default; you decide whether to peer that network with yours and whether access to the app is limited by IP.
• Lifecycle. Scaling the App Service plan, adding database high availability or geo-redundant backup, tagging, and deleting resources are your decisions.

Two honest caveats. First, the default deployment uses public endpoints for the database and Key Vault, protected by TLS, authentication and firewall rules; private networking is an option you choose at deployment time, not the default. Second, owning the resources means the standard Azure hygiene is yours: right-sizing the plan, reviewing access, watching costs. That's the price of the control, and for most Azure teams it's work they already do across their estate.

The same trade applies to the most sensitive data Atlas holds. Where should an MSP store client credentials? walks through what Atlas Vault encrypts, with whose key, and what your Azure access control has to protect.

The contrast with "trust us, it's running securely in our cloud" isn't that one is secure and the other isn't. It's that one asks for trust and the other lets you verify.

What Atlas still runs centrally, and what crosses the line

A platform that's sold, licensed and updated needs some central services. Ours is the Atlas control plane, a single service at controlplane.atlasavd.us that runs in Azure Government. It handles:

• trials, subscriptions and billing (through Stripe, which holds card details);
• the setup link and one-time onboarding described below;
• signed license answers and usage totals for billing;
• update availability and staged rollout;
• support tickets you choose to file, release notes, and content feeds such as CVE intelligence.

Atlas also operates the storage that release packages and agent installers download from, and sends account email from the control plane. The subprocessors page lists the third parties involved.

Here is what your deployment sends to the control plane in normal operation:

And here is what does not go to Atlas: your users' sessions, profiles, files or mail; your session-host inventory and VM telemetry in normal operation; Atlas Vault contents; Advisor conversations; Reach session content and recordings; print jobs; and the Azure and Microsoft Graph credentials your deployment uses.

The precise version of the promise. Atlas is not "zero data." It's a small, documented set of metadata and counts needed to license, bill, update and support the product, with your operational data staying in a database you own.

Your deployment also talks directly to services that aren't Atlas: Microsoft's endpoints (Azure Resource Manager, Microsoft Graph, Log Analytics and so on), public sources such as winget package manifests and open DNS threat lists, the encrypted DNS resolver that Atlas Resolve forwards filtered lookups to (Quad9 by default, configurable), the AI provider you pick for Advisor if you turn AI mode on, and integrations you configure. One detail worth knowing: the user location map uses a local GeoIP database when one is loaded and falls back to a public lookup service when it isn't. On government clouds, only the local database is permitted.

How onboarding touches your tenant

With the setup link, your administrator approves Atlas once in their own Entra directory. Working under that administrator's own short-lived sign-in, the control plane creates the Atlas app registration in your directory and deploys the Azure template into your subscription. It requests no long-lived refresh token for the directory work, and the deployment sign-in session expires within 90 minutes. The app registration's new client secret is held by the control plane in encrypted form only until your deployment collects it and reports ready (seven days at the outside), and Atlas then removes its temporary setup application from your tenant (telling you if it needs to be removed by hand).

If you would rather Atlas never act in your directory at all, the Cloud Shell script creates the same registration under your own account, and you continue the deployment yourself.

After onboarding, Atlas holds no Azure role assignment on your subscription, no Azure Lighthouse delegation, and no standing access to your directory. What it retains is the ability to answer your deployment's license checks, which is how a cancellation or suspension takes effect, and to nudge your deployment to re-check its license after a plan change. Neither gives Atlas any way to read your data or change your resources.

The compliance boundary problem

Atlas does not make anyone compliant, and neither does any architecture on its own. CMMC, NIST SP 800-171, HIPAA, PCI DSS, SOC 2 and similar frameworks are about how an organization operates, and the applicable boundary is something you determine with your own compliance and security professionals and, where relevant, your assessor.

What architecture can do is influence how much has to be evaluated. Every external system that stores, processes or has access into your regulated environment can bring:

• another security review and vendor risk assessment;
• another data flow to document and justify;
• another identity relationship, with its own credentials and permissions;
• another contract, data processing agreement and subprocessor list;
• another party in your incident response plan;
• another system that auditors need to understand.

Keeping the operational infrastructure inside an Azure environment you already govern may reduce the number of external systems that have to be evaluated, depending on your architecture and requirements. The management application, its database and its credentials sit within a boundary you've already scoped and controlled, and the remaining external relationship is the narrower one described above: licensing, billing, updates and support.

That doesn't remove Atlas from your analysis; it changes the shape of the question. "A vendor stores our operational data and has standing access to our tenant" becomes "vendor software runs in our subscription; here is the metadata it reports and the onboarding consent it used." For many regulated organizations, that's an easier conversation.

For organizations in Azure Government, the Atlas application runs against Azure Government endpoints, the control plane itself runs in Azure Government, and some Microsoft features that aren't offered in GCC High are switched off automatically. Self-service trials are open for Azure commercial today; Microsoft 365 GCC and GCC High / Azure Government are on a waitlist. Our government page covers the details.

Reducing vendor trust dependencies

Neither model eliminates trust. Running Atlas means trusting Atlas software with significant permissions in your environment. The question is what that trust is attached to, and there's a meaningful difference between giving a vendor control over your environment and running vendor software inside infrastructure you control:

The permissions deserve scrutiny either way. Atlas manages AVD, Microsoft 365 and endpoints, so its app registration holds broad ones: Azure roles on the subscription for virtual machines, networking and AVD, and Microsoft Graph permissions for users, groups, devices and policies. We publish every permission, directory role and Azure role it holds, and Microsoft's consent screen lists them before your administrator approves anything. The architecture doesn't make those permissions small. It makes them yours to see and yours to revoke, held by an identity in your directory rather than by a vendor service.

Updates follow the same principle. Your deployment checks for new releases, and Atlas stages each release out gradually across the fleet, but installing an update is an administrator action in your deployment. Atlas doesn't push code into your subscription.

Why managed identity matters (and where it fits)

The most common long-lived secret in Azure automation is a client secret: a password for an application, copied into a configuration file or a vendor's database, valid for months or years.

A managed identity takes that secret out of your hands. The identity is bound to a specific resource, Azure issues and rotates its underlying credential, and RBAC governs what it may do. There are still credentials; Azure just manages their lifecycle instead of you.

Atlas uses its web app's system-assigned managed identity where Azure supports it for resources the deployment owns: reading and writing its Key Vault, managing its own App Service for updates, querying Log Analytics, working with its storage, and calling Azure OpenAI in your tenant if you choose that provider for Advisor.

Managing your AVD estate and Microsoft 365 works differently today, and we'd rather be specific than imply otherwise. Those calls to Azure Resource Manager and Microsoft Graph use the app registration in your directory, authenticated with a client secret. That secret lives in your Key Vault, is referenced from the app's settings rather than written into them, and can be rotated by you. In a multi-tenant MSP deployment, each managed tenant uses an app registration in its own directory. Likewise, the database connection uses a password stored in Key Vault rather than Entra authentication.

The principle holds either way: the credentials live inside your boundary, under your control.

Customer-owned infrastructure, in practice

Put together, owning the infrastructure means the management plane behaves like the rest of your Azure estate. It's visible in the portal next to everything else you run. Your governance (Policy assignments, RBAC, tagging standards, access reviews) applies to it. Its networking can follow your design through private endpoints, VNet integration and IP restrictions. Its logs land in a workspace in your subscription. Sign-in runs through your directory and your Conditional Access policies. And its lifecycle (sizing, backup retention, high availability, when updates are installed) is your decision. The management layer stops being an opaque service and becomes an app, a database and a vault you can inspect.

What happens if Atlas disappeared tomorrow?

It's a fair question to ask any vendor. With a traditional SaaS platform, vendor unavailability usually means the management platform is unavailable. With Atlas the picture is split, because some things live in your subscription and some depend on us. Here's the honest version, including the less flattering parts.

Unaffected, because it was never Atlas's to begin with

• Azure Virtual Desktop itself. Host pools, session hosts, application groups and workspaces are native Azure resources. Users connect through Microsoft's AVD service and clients; Atlas isn't in the connection path.
• Your data. The PostgreSQL database, the Key Vault and the logs stay in your subscription. Atlas doesn't delete customer resources when a subscription ends, and it has no standing Azure access with which to do so.
• Work already done. Email signatures already written into mailboxes stay there. Printers that Atlas Spool installed are ordinary direct-IP Windows printers.

Continues for a limited time

• The Atlas application. By default, your deployment keeps running on its last signed license for about three days if the control plane can't be reached. That window exists so a short network problem doesn't interrupt a paying customer.
• Scheduled automation and agents. Scaling, scheduled jobs and other automation run inside your web app, not on Atlas servers, so they continue during that window. Reach agents connect to your deployment, not to Atlas.

Stops or degrades

• After the license window, the Atlas console locks to its licensing and update screens and paid automation stops. Sign-in still works and your data is untouched, but day-to-day management through Atlas is no longer available.
• Restarts. Today your App Service loads the Atlas application package from Atlas's release storage. If that storage were unreachable, the app could fail to start after its next restart.
• Updates, new agent installs, billing changes, support tickets and the content feeds need Atlas's central services.

One practical consequence: if Atlas's autoscaling stops, session hosts stay in whatever state they were last left in. If you want scaling that never depends on Atlas, Azure's native scaling plans are an option, and Atlas stands its own autoscaling down for any host pool that has one assigned, so the two never compete.

So the honest summary is: Atlas makes the management plane yours, not vendor-independent. Your desktops keep working, your data stays put, and nothing needs to be retrieved from us. But Atlas, the software, needs Atlas, the company, to stay licensed and updated, as any commercial software does.

SaaS isn't bad

SaaS is the right model for a great deal of software, and we don't want this article read as an argument against it. It offers:

• instant onboarding, with nothing to deploy;
• upgrades that happen centrally, for everyone, at once;
• no infrastructure for the customer to size, patch or pay for;
• predictable operations run by people who do nothing else.

Atlas itself uses centralized services where they clearly earn their place. Billing belongs in one place. Staged release rollout only works if one service can see the whole fleet's health. License signing needs a key that isn't in every customer's environment. A support desk is, by nature, shared.

Our philosophy isn't "never SaaS." It's: use centralized services where they provide clear value, but don't move customer infrastructure, control or sensitive operational data outside the customer's boundary unless there's a reason to.

Why this matters for MSPs

With a SaaS management tool, the chain often runs MSP → management vendor → customer, and the vendor in the middle holds access to every customer the MSP serves. With Atlas, the vendor steps out of the data path: the MSP's own Atlas deployment manages each customer's tenant directly, and the Atlas control plane sees licensing and counts.

In multi-tenant mode (Atlas Command), an MSP runs one Atlas deployment in its own subscription and manages its customers' tenants from it. That has some concrete consequences:

• Tenant isolation. Each managed tenant gets its own PostgreSQL database with its own scoped database role, rather than rows in a shared table.
• Customer-owned access. Each customer grants access through an app registration in its own directory, which the customer can review and revoke.
• Offboarding. When a customer leaves, revoking that app registration ends the deployment's access to their tenant. Their AVD resources were in their own subscription throughout, and their history sits in a separate database rather than interleaved with other customers' rows.
• Security reviews. When a customer's security team asks who has access to their environment, the answer is "our MSP, through an app registration you can see," not "our MSP and a third-party platform vendor."
• Customer handoffs. If a customer needs the management plane inside its own boundary, which is common in regulated work, it can run its own Atlas deployment in its own subscription instead.

None of this replaces an MSP's own security practices, contracts or delegated administration model. It does keep the number of parties holding access to a customer's tenant smaller. See Atlas AVD for MSPs and MSP plans for the operational side.

The Azure-native advantage

Atlas was designed around Azure rather than to abstract it away. It manages your estate through Azure Resource Manager, the Azure Virtual Desktop APIs, and Microsoft Graph and Entra ID; keeps secrets in Key Vault and uses managed identity; reads diagnostics from Azure Monitor and Log Analytics; stores App Attach packages and images in Azure Storage and Azure Compute Gallery; and itself runs on App Service and Azure Database for PostgreSQL.

For an organization standardized on Azure, that has practical benefits. There's no translation layer between what Atlas shows and what Azure reports: quotas, SKUs and regions are Azure's own. Azure Government is a matter of using the right endpoints rather than a separate product. And the management platform is governed by the same Azure tooling as the workloads it manages.

The trade-off is deliberate. Atlas isn't a cross-cloud abstraction; if your desktops span several clouds, a generic platform may suit you better. If they live in Azure, building on Azure directly removes a layer.

Architecture vs feature checklists

Evaluations of AVD and MSP management tools usually focus on features: autoscaling, image management, monitoring, scripting, dashboards, reporting, automation. Those matter. But there's a question that rarely makes the spreadsheet: where does the management platform itself run?

Here are the questions we'd suggest asking any vendor, including us:

1. Where is the management plane hosted, and in whose subscription?
2. Where is our operational data stored, and who administers that storage?
3. Exactly what data leaves our environment, how often, and why?
4. What credentials to our tenant does the vendor hold, and for how long?
5. Can managed identity be used, and where is it not used?
6. What happens to our environment if the vendor's service is unavailable for a day, a week, or permanently?
7. Can we inspect the infrastructure that runs the platform?
8. Do our Azure Policy assignments apply to it?
9. Can its logs go into our own monitoring platform?
10. Which external services become part of our operational dependency chain?
11. How is tenant isolation implemented: separate databases, separate schemas, or filtered rows?
12. What happens to our data and the vendor's access when we offboard?
13. Who owns the underlying infrastructure and pays for it?
14. Which components need outbound internet access, and to where?
15. What access does vendor support have to our environment, and how is it granted and logged?

A vendor that answers these clearly, whatever the answers are, is a vendor you can assess. Pair them with the Azure Virtual Desktop security checklist, our comparison pages, and the AVD cost calculator to account for the Azure infrastructure an in-tenant platform runs on.

See the architecture for yourself

Atlas AVD was built around a simple principle: your Azure environment should remain yours.

Explore the interactive demo to see how Atlas manages Azure Virtual Desktop and IT operations with customer ownership and Azure-native architecture at the center of the platform. When you're ready to look at the deployment itself, the deployment guide walks through it step by step, and pricing covers the plans.

Explore the Atlas AVD demo →