Is Your AVD Management Platform Inside or Outside Your Compliance Boundary?

By David, 2026-09-09

Picture an organization that has done the hard work. Its Azure environment is built around Microsoft Entra ID and Conditional Access. Permissions flow through Azure RBAC, Azure Policy keeps resources inside agreed guardrails, secrets live in Key Vault, logs land in a central workspace and the SIEM, and network paths are deliberate. Azure Virtual Desktop sits inside that design like any other workload.

Then the team buys an AVD management platform.

The security review focuses on features. Does it autoscale? Manage images? Monitor sessions? Automate host pools? Produce reports? Those are the right questions for choosing a tool, but another one is easy to skip, because it isn't a feature:

Where does the management platform itself live?

What can it access? What data does it receive? Which identities does it use? And what happens when information crosses from your Azure environment into the vendor's?

None of these implies a wrong answer. They matter because a security or compliance program has to define which systems, identities and data flows it covers, and an AVD management platform is, by definition, highly privileged. This article walks through the question vendor-neutrally, then explains the architecture we chose for Atlas AVD, including the parts that still depend on us.

Not legal or compliance advice. This article describes architectural considerations. It does not determine scope for any framework, and it does not claim that any product, Atlas AVD included, makes an organization compliant.

What is a compliance boundary?

A security or compliance boundary is the line an organization draws around everything a particular program applies to. Frameworks call it the system boundary, the authorization boundary, the assessment scope or the cardholder data environment, but the idea is similar. It identifies the systems that store, process or transmit protected information; the services they depend on; the identities, human and non-human, that can access or change them; the networks and data flows between them; the people and processes that operate them; and the security and management tools that protect or administer all of the above.

Boundaries are not universal. The same AVD estate can have a different boundary under different programs, because scope depends on the organization, its architecture, the regulatory framework, the contract that imposes the requirement, the classification of the data and the purpose of the system.

That leads to the most important sentence in this article:

A vendor cannot universally tell a customer whether a specific system is inside or outside that customer's compliance boundary.

A vendor can, and should, describe precisely where its product runs, what it stores, what it sends and what it can access. What that means for scope is for the organization and its qualified security and compliance professionals to decide.

The hidden expansion of the boundary

A SaaS integration often looks like one new box on a diagram: "the AVD management tool." In practice that box can bring several systems and relationships with it.

Depending on the architecture and the framework, an organization may need to understand:

• what information leaves Azure, and in what form;
• where it is stored, in which region and in whose environment;
• who can access it, including vendor engineers and support staff;
• what permissions the vendor holds in your subscriptions and your directory;
• how authentication works, and where any secrets or certificates are kept;
• what logs are generated and whether you can see them;
• which subprocessors are involved;
• how incidents are handled, how data is deleted, and how customers are offboarded.

None of that means each item automatically becomes part of your compliance boundary. It means each one can introduce an additional trust relationship that should be considered when determining system boundaries, and some may affect scope depending on what the platform touches.

A simple example

In Environment A, users sign in with Entra ID, connect to Azure Virtual Desktop, keep profiles on Azure Storage, and the team watches everything in Azure Monitor. It all operates primarily within the organization's established Azure environment, under controls it already governs.

Environment B is the same organization after adding a vendor-hosted management platform, with its own external API, external database, vendor identity system and vendor operations.

Environment B is not automatically noncompliant; plenty of regulated organizations run vendor-hosted tools successfully. It simply has more questions to answer about the vendor's environment, people, controls and suppliers, and someone has to collect those answers, assess them and keep them current.

The question isn't whether SaaS is secure. The question is whether you understand every system you're adding to your security and compliance architecture.

The questions security teams should ask

Here is the checklist we'd want answered for any AVD management platform, including ours, grouped so each section can go to the person best placed to answer it.

Hosting and data

1. Where is the management plane hosted, and in whose cloud subscription?
2. What customer data leaves our Azure environment?
3. Where is that data stored?
4. How long is that data retained?
5. Does customer information pass through vendor infrastructure?

Identity and access

6. Which identities access our Azure resources?
7. Are static client secrets required, and who stores and rotates them?
8. Can managed identity be used, and for what?
9. What Azure RBAC roles are required, and at what scope?
10. What Microsoft Graph permissions are required?
11. Does the vendor require Global Administrator or a similarly privileged role, and for how long?
12. Can permissions be reduced after deployment?
13. Does the vendor store secrets for our environment?
14. Does the vendor have standing administrative access?
15. How does vendor support gain access, and who approves it?

Visibility and control

16. Can we monitor the vendor's actions?
17. Are management actions visible in our Azure Activity Log?
18. Are support actions logged, and can we see those logs?
19. Can our Azure Policy assignments apply to the vendor's components?
20. Can our network controls apply?

Connectivity

21. Does the platform require inbound connectivity?
22. What outbound connectivity is required, to which hosts?

Supply chain and resilience

23. Which subprocessors are involved?
24. What happens if the vendor has an outage?
25. What happens if the vendor has a security incident?
26. Can the platform keep operating if the vendor's control plane is unavailable, and for how long?

Exit

27. What happens when we terminate the service?
28. How is our data deleted, and how is that evidenced?
29. What happens to infrastructure and agents after offboarding?
30. Who ultimately owns the infrastructure running the management platform?

A vendor that answers these clearly, whatever the answers are, is a vendor you can assess. Vague answers are a finding in themselves.

Before comparing feature checklists, ask one architectural question: where does the management platform actually run?

Framework-specific considerations

Each framework treats this differently. What follows is orientation, not a scoping determination; work from the current official text and your own advisors.

CMMC and NIST SP 800-171

The CMMC program rule, 32 CFR Part 170, applies to defense contractors handling Federal Contract Information and Controlled Unclassified Information (CUI). Level 2 assesses the requirements of NIST SP 800-171 Rev. 2, the revision the rule incorporates (NIST has since published Rev. 3). Several of the rule's concepts apply directly to management platforms:

• CUI Assets process, store or transmit CUI.
• Security Protection Assets provide security functions or capabilities to the assessment scope, and are assessed against the requirements relevant to what they provide.
• Security Protection Data includes configuration data, logs, vulnerability and configuration status of in-scope assets, and passwords that grant access to the in-scope environment.
• An External Service Provider is an outside party providing IT or cybersecurity services, and counts as one for CMMC only if CUI or Security Protection Data is processed, stored or transmitted on its assets. The rule scopes cloud and non-cloud providers differently.

A privileged management platform can touch several of these at once, so where it runs and what it stores is likely to be part of the scoping conversation. (The rule also treats an endpoint hosting a VDI client limited to keyboard, video and mouse as out of scope, one reason AVD is common in CMMC enclave designs. The management layer for that enclave is a separate question.)

Architecture cannot decide the answer. Deploying a management platform inside your own Azure subscription does not automatically place it inside or outside a CMMC assessment scope. It changes the facts scoping is based on, and those facts still need analysis by your organization and, where applicable, your C3PAO. The DoD's Level 2 Scoping Guide and the Cyber AB are the places to start.

GCC High and Azure Government

Organizations on Microsoft 365 GCC High and Azure Government chose a physically separate cloud with its own sign-in authority and endpoints, usually because a contract requires it. They tend to be particularly sensitive to commercial SaaS dependencies, data movement out of the sovereign cloud, identity boundaries that cross into commercial directories, external APIs, privileged vendor access (who can exercise it, from where, under what approval), service availability, data residency and contractual requirements such as DFARS clauses.

Two cautions apply to every vendor. Running software in Azure Government does not make it FedRAMP authorized; FedRAMP authorizes a specific cloud service offering through a defined process. And Microsoft's FedRAMP authorizations for Azure Government cover Microsoft's services, not the applications built on them.

Where Atlas stands today:

• Self-service trials are available in Azure commercial. Microsoft 365 GCC and GCC High / Azure Government are waitlisted while GCC High onboarding is validated end to end (join the GCC High waitlist).
• The application is built to target sovereign endpoints automatically (login.microsoftonline.us, management.usgovcloudapi.net, graph.microsoft.us), and refuses to start against unsupported clouds rather than falling back to commercial hosts.
• Atlas Ink is commercial-only and fails closed in GCC and GCC High.
• Planning the desktops themselves? Azure Virtual Desktop in GCC High covers the Government endpoints, clients, feature timing and CMMC enclave scoping.
• The Atlas control plane runs in Azure Government. That is a hosting fact, not an authorization: Atlas is not FedRAMP authorized.
• Choosing a GCC High subscription at deployment prompts the deployer to confirm authorization from their Information System Owner, because connecting a subscription can affect a CMMC assessment scope. See the GCC High guide and government page.

PCI DSS

PCI DSS scope starts with the cardholder data environment (CDE): the people, processes and technology that store, process or transmit cardholder data. The PCI Security Standards Council's scoping and segmentation guidance is explicit that the CDE is only the starting point: systems connected to the CDE, or that can impact its security, are generally in scope too. That category typically includes systems providing administrative access, authentication, logging and other security services.

A management platform that can start, reimage or reconfigure session hosts in a CDE, or holds credentials to them, has a clear path to affecting CDE security. Whether it is in scope, and what segmentation can do about that, depends on the architecture; work it through with your QSA against the current PCI DSS standard.

HIPAA

For electronic protected health information (ePHI), the HIPAA Security Rule calls for risk analysis and safeguards across systems that create, receive, maintain or transmit it. A management platform deserves attention if it has privileged access to systems holding ePHI, receives telemetry, logs, screenshots or support data that could contain ePHI, stores session data, or interacts directly with clinical workloads.

When a third party creates, receives, maintains or transmits ePHI on a covered entity's behalf, it is generally a business associate needing a business associate agreement (BAA); HHS's cloud computing guidance covers how that applies to cloud providers, and NIST SP 800-66 Rev. 2 is a practical implementation guide. Whether a given management tool needs a BAA is a question for your privacy and legal teams, informed by exactly what data it can reach.

SOC 2

SOC 2 is different in kind. It is not a regulation or a certification but an attestation report by an independent CPA firm against the AICPA's Trust Services Criteria. For a management platform, a SOC 2 program usually cares about vendor management, access control, change management, logging and monitoring, availability and incident response. A vendor-hosted platform is usually evaluated through its own SOC 2 report; a platform deployed in your environment shifts more of those controls onto your existing processes, while the vendor's development and release practices still need evaluating.

Every vendor can introduce another trust relationship

Modern systems inevitably rely on vendors, and vendors rely on vendors. A management platform is rarely one company:

The goal is not "zero vendors." That isn't achievable or desirable; specialists often do a better job than anyone could alone. The goal is:

Understand, and minimize, unnecessary trust relationships.

That is a software supply chain question as much as a compliance one: for each link, know what it receives, what it could do if compromised, and whether it is needed at all.

Portal hopping and vendor sprawl

There is an operational version of the same problem. IT teams and MSPs add tools one need at a time: AVD management, RMM, documentation, email signatures, DNS filtering, printing, monitoring, automation, ticketing. Together they can mean a dozen SaaS portals, user databases and admin roles; a dozen sets of APIs with access to the same tenant; several agents on the same endpoints; and a dozen contracts, security reviews and sets of audit artifacts every year.

That isn't merely inconvenient: each platform is another set of identities to review, another place an offboarded technician might keep access, and another vendor whose incident becomes yours.

Consolidation does not automatically improve security; one platform with sweeping permissions and weak controls can be worse than three well-governed ones. But reducing systems you don't need, done responsibly, can simplify governance: fewer identities, fewer data flows, fewer parties in your incident response plan.

Why Atlas chose a different architecture

When we designed Atlas AVD, we applied one principle to almost every decision:

Keep operational components inside the customer's Azure environment whenever it is technically practical.

A standard deployment creates these resources in a resource group in your subscription:

People sign in with Entra ID through a single-tenant app registration in your own directory, so your Conditional Access policies apply. In an MSP deployment, each managed tenant gets its own PostgreSQL database.

The modules are part of that same application, not separate vendor services:

One note on Advisor: in AI mode, the provider you choose receives your questions and the environment context Advisor sends with them, so it belongs in your own data-flow analysis. On GCC High, commercial AI providers are blocked by default.

We didn't move these components out of your subscription just because centralizing them would suit us. Where a central service genuinely earns its place, we run one, described below.

What customer-owned infrastructure means

Because these are ordinary Azure resources in your subscription, the control comes from standard Azure mechanics, not from anything Atlas promises. You can see every resource and role assignment, monitor it in your own workspace or SIEM, apply Azure Policy to it, inspect activity (changes Atlas makes to your AVD estate appear in your Azure Activity Log under the identity that made them), control networking and RBAC, and own the lifecycle, down to deleting the resource group.

Individual vendors vary, so treat the middle column as typical, not universal:

Two caveats. The default deployment uses public endpoints for PostgreSQL and Key Vault, protected by TLS, authentication and firewall rules; private networking is an option you choose. And ownership means routine Azure hygiene (sizing, access reviews, cost) is yours.

Identity and secrets

A management platform's identity is privileged by design, so the key question is where the credential lives and who manages it:

• A vendor stores credentials for your Azure environment. A client secret, certificate or token for your tenant lives in the vendor's systems. Your security depends partly on how the vendor protects it.
• An Azure-hosted workload uses a managed identity. The identity is bound to a resource in your subscription, Azure issues and rotates its credential, and RBAC decides what it may do. Managed identities remove the need to manage those credentials yourself.

Managed identity reduces long-lived application credentials where it can be used. Here is exactly where Atlas stands today:

• Managed identity covers the resources the deployment owns: its Key Vault, its own App Service for updates, Log Analytics queries, its storage, and Azure OpenAI in your tenant if you choose it for Advisor.
• Managing your AVD estate and Microsoft 365 uses the app registration in your directory, authenticated with a client secret. That secret has a 24-month lifetime, lives in your Key Vault, and you can rotate it. Atlas doesn't keep a copy after onboarding completes.
• The database connection uses a password stored in Key Vault rather than Entra authentication.
• The application's data-encryption keys are currently App Service settings rather than Key Vault references. We're reviewing that.

On permissions: rather than subscription-wide Contributor or Owner, the app registration gets specific Azure built-in roles (for example Desktop Virtualization Contributor, Virtual Machine Contributor, Network Contributor, Monitoring Reader) plus a narrow custom role that can only create resource groups. The set includes Role Based Access Control Administrator, because Atlas assigns AVD access roles when it deploys host pools. It carries a condition that limits it to the five AVD roles Atlas assigns, so it can never grant Owner, but it still deserves a deliberate review. Microsoft Graph application permissions cover users, groups, devices and policies, and initial setup needs a Global Administrator to grant consent and assign the Exchange and Compliance Administrator directory roles. The app registration guide lists every permission, and a read-only setup variant lets you evaluate Atlas before granting anything that can change your tenant.

The architecture doesn't make those permissions small. It makes them yours to see, review and revoke, held by an identity in your directory rather than by a vendor service.

What does the Atlas control plane actually do?

Atlas runs one central service, the Atlas control plane at controlplane.atlasavd.us, in Azure Government. As the genuinely vendor-hosted part of Atlas, it deserves the most transparency. It handles trials, subscriptions and billing (payments through Stripe); onboarding through the setup link; signed license answers and usage totals; release availability and staged rollout; and support tickets, release notes and content feeds such as CVE intelligence. Atlas also operates the storage that release packages and agent installers download from. The subprocessors page lists the third parties involved.

What your deployment sends it

What it doesn't receive in normal operation: sessions, profiles, files or mail; session-host inventory and VM telemetry; Vault contents; Advisor conversations; Reach session content; print jobs; or the Azure and Graph credentials your deployment uses.

Authentication. Each deployment holds a registration token issued at onboarding. It authenticates the deployment's calls (the control plane stores it encrypted and looks it up by hash) and keys an HMAC attestation on usage reports. License answers are signed with an Ed25519 key held in the control plane's Key Vault and verified by your deployment.

Licensing and updates. Licensing is a pull model: your deployment asks, and the control plane answers with a signed license state and a lease. Cancellation or suspension takes effect at the next pull; the control plane can ask your deployment to re-check early, but holds no credential that lets it change your deployment. It also doesn't push code: it says whether a release is available to you yet (stable releases roll out gradually), and an administrator installs it. The app's managed identity then points the App Service at the new package from Atlas's release storage, and you can roll back.

Outbound connectivity. Nothing needs inbound access to your environment. Your deployment needs outbound access to the control plane, Atlas's release storage (atlasavdreleases.blob.core.usgovcloudapi.net, needed whenever the app starts, not only for updates) and Microsoft's endpoints for your cloud. Some features add more: public winget manifests, open threat lists and an encrypted DNS resolver (Quad9 by default) for Atlas Resolve, the AI provider you pick for Advisor, integrations you configure, and a public IP-geolocation lookup for the user location map when no local GeoIP database is loaded (never used on government clouds). The application includes no third-party analytics or crash-reporting service; Application Insights lives in your subscription.

Onboarding, the one time Atlas acts in your environment:

• Your administrator approves Atlas in their own Entra directory. Under that administrator's delegated sign-in, the control plane creates the Atlas app registration and deploys the template into your subscription as that user. Directory work requests no refresh token; the deployment sign-in session expires within 90 minutes and is stored encrypted for that window.
• The new client secret is held by the control plane, encrypted, only until your deployment is running and reports ready, seven days at most. It is passed in as a secure parameter that lands in your Key Vault.
• Atlas then removes its temporary setup application from your tenant.
• If you'd rather Atlas never act in your directory, the Cloud Shell script creates the registration under your own account.

After onboarding, Atlas holds no Azure role assignment on your subscription, no Azure Lighthouse delegation and no standing access to your directory, and the application contains no vendor remote-access or impersonation path.

Why the central pieces exist. Billing belongs in one place, a license must be signed by a key that isn't in every customer's environment, staged rollout needs a view of the whole fleet, and a support desk is shared by nature. Those are the reasons, and the limits.

What happens if the vendor control plane goes offline?

With traditional centralized SaaS the answer is usually simple: if the vendor's service is down, the management platform is down, though the managed workloads typically keep running. With Atlas the answer is split.

Unaffected

• Azure Virtual Desktop itself. Host pools, session hosts and workspaces are native Azure resources, and users connect through Microsoft's service. Atlas isn't in the connection path, and user authentication is Entra ID's.
• Your data. Database, Key Vault and logs stay in your subscription.
• Work already done. Signatures already in mailboxes stay there; Spool printers are ordinary Windows printers.

Continues for a limited time

• The Atlas application keeps running on its last signed license for a lease, about three days by default. During it, the console, the User Portal, autoscaling and scheduled automation keep working, because they run in your web app, and Reach agents keep connecting, because they connect to your deployment.

Stops or degrades

• After the lease, the license is marked suspended and the console and API lock to the licensing and update screens until it can be renewed. Sign-in still works and your data is untouched, but plan as if Atlas-driven automation and agent features have stopped.
• App restarts. The App Service loads its release package from Atlas's release storage each time it starts. If that storage were unreachable during a restart, scale-out or slot swap, the app could fail to start, even inside the lease. This is by design: every deployment runs the same immutable, versioned package from one source, which keeps installs, rollbacks and audits simple. If you restrict outbound traffic, keep the release storage host allowed.
• Updates, new agent installs, billing changes, support tickets and content feeds need Atlas's central services.

If you want scaling that never depends on Atlas, Azure's native scaling plans are an option; Atlas stands its own autoscaling down for any host pool with one assigned.

The accurate summary: Atlas makes the management plane yours, not vendor-independent.

Offboarding matters too

When you leave any SaaS provider, ask: who owns the data and the infrastructure? What must be exported, what gets deleted, and how is that evidenced? Which integrations and identities must be revoked? What agents and infrastructure remain? With customer-owned infrastructure, your operational data was never in the vendor's environment, so deleting it is something you do and can see. For Atlas:

• Your Azure resources stay yours. Cancelling deletes nothing in your subscription, and the control plane has no standing access with which to do so. The application stops operating when its license lapses (a self-service cancellation takes effect at the end of the paid period); the database, Key Vault and logs remain until you delete the resource group.
• Revoke access yourself. Atlas doesn't delete its app registration for you. Removing the app registration, its enterprise application, and its directory-role and Azure role assignments ends the deployment's access. In an MSP setup, each customer can revoke the registration in its own directory.
• Remove agents with the Reach agent uninstall guide.
• Control-plane records (contact and billing details, usage reports, support tickets) are kept under the control plane's retention schedule; some billing and audit records are kept long term. Ask us if you need specific records deleted.
• Your AVD estate keeps running without Atlas.

The step-by-step checklist, with the commands, is in the Support Center: Leaving Atlas AVD: Offboarding & Uninstall Guide.

The architecture, side by side

Know your management boundary

Before choosing an AVD management platform, understand where it runs, what it accesses, what leaves your environment, and which new trust relationships it introduces. Ask every vendor the thirty questions above.

Atlas AVD was designed around customer-owned Azure infrastructure and Azure-native services wherever technically practical. That doesn't make anyone compliant or remove Atlas from your analysis; it gives your security and compliance team a smaller, clearer set of facts to work with.

• Explore the interactive demo.
• Review the architecture in Why We Built Atlas AVD Inside Your Azure Tenant Instead of as Traditional SaaS and the deployment guide.
• Read the documentation: the app registration guide, the GCC High guide, the Azure Virtual Desktop security guide and the subprocessors page.
• Ask us your architecture and security questions by email, or see pricing.