Connecting your Azure Government environment
Provisioning happens in two parts. You connect your Azure Government environment once, guided by the CUI Enclave Setup module in the Defense Navigator, and then provision desktops whenever you need them from the Virtual Desktops module.
This is the one-time step, and the recommended place to do it is the CUI Enclave Setup module in Navigator, where it happens in the right order within your CMMC setup. If you go straight to the Virtual Desktops page instead, you will be prompted to set up your virtual desktop infrastructure first. It is the same connection either way, and both paths walk you through it.
Secureframe connects to your environment through an App Registration that you create. That connection is scoped to manage Virtual Desktop infrastructure in the dedicated subscription you select. It has subscription Owner for deploy and maintenance, plus privileged Microsoft Entra permissions needed to operate the environment. Standing design does not grant read access to CUI or profile shares. See Secureframe Virtual Desktops (Secureframe access to your Virtual Desktops) for the full privilege model.
Follow the on-screen instructions to create the App Registration and enter the required IDs and secrets. Each step is laid out exactly.
Sign in with an account that has the Owner role on the subscription (or Contributor plus User Access Administrator), including permission to assign roles, and select your subscription when prompted.
Secureframe then builds the foundation your desktops run on, including an isolated virtual network with security rules that block inbound internet traffic and a NAT gateway for controlled outbound access. You will land on a confirmation page when your environment is connected, and the person who started the deployment gets an email when the infrastructure finishes deploying. These core resources incur Azure costs even before any desktops exist. Costs depend on the number of users and your workflow type.
Note: Complete Prerequisites to setting up your Virtual Desktops before you start. Missing subscription visibility or Owner access is the most common cause of stalled setup.
Ownership, Terraform, and infrastructure as code
Secureframe deploys and maintains Virtual Desktop infrastructure in Azure resource groups that Secureframe creates and manages. That includes upgrades and image patches. Secureframe tracks configuration drift on those resources.
If your organization manages Azure with Terraform, OpenTofu, or similar tools:
Treat Secureframe-managed resource groups as vendor-managed. Leave them out of your Terraform or OpenTofu state.
Do not import Secureframe-managed resources into your own state. Secureframe re-applies its configuration on deploy and upgrade, so your plan will keep showing drift against Secureframe.
You keep ownership of the rest of the subscription outside those resource groups.
Secureframe does not provide the Virtual Desktop deployment as customer-managed Terraform. The platform renders ARM templates and continues to reconcile the environment as new versions ship. That is different from the AWS integration Terraform, which creates a static read-only scanning role you can own after setup.
For visibility before and after a change, use the deployment plan and change list in Secureframe. If you need the template for your records, Secureframe can export the ARM JSON that was submitted for that deploy.
Provisioning a desktop
Desktops are provisioned from the Virtual Desktops page under Defense.
Click Provision new desktop.
Configure the desktop: Name, Image (Windows 11), Region (US Gov Virginia), Instance type (Lite: 2 vCPUs / 8 GB RAM, Medium: 4 vCPUs / 16 GB RAM, Heavy: 8 vCPUs / 32 GB RAM, or Power GPU-enabled for engineering work), Disk size (128 GB to 2 TB), and User access (each user needs an active GCC High license).
Review and confirm. Secureframe shows estimated Azure costs in the product before you deploy. Confirm to start provisioning.
If your subscription is out of quota for the selected instance type, Secureframe falls back to an alternative where possible. Otherwise the deployment error tells you what to fix, and you may need to request a quota increase from Azure.
Your CSM can help you choose the right setup for your team.
Region
The Region field lists US Gov Virginia. Enclaves with the shared data drive use one storage account behind one private endpoint, so the enclave uses a single region. Multi-region selection is not available when the shared data drive is enabled.
What every desktop includes
You are not provisioning a bare virtual machine. Every desktop deploys from a CMMC-compliant configuration:
Windows 11, joined to a managed domain (not Entra join), with multi-factor authentication required to sign in
Microsoft Defender endpoint protection and automatic patching
Automatic screen lock after inactivity
Clipboard, drive, USB, and printer redirection blocked, so CUI stays inside the desktop
Encryption at rest on FIPS-validated Azure Government hardware. For broader FIPS 140 guidance in virtualized CUI environments, see FAQs: FedRAMP, CMMC, and DFARS.
Network isolation, with desktops unable to reach each other and no inbound access from the internet
This configuration is what Secureframe's automated CMMC tests validate continuously after deployment.
Note: Managed-domain-joined Virtual Desktops do not appear in Entra Devices or Intune. They still show as VMs in the Azure portal. Intune cannot manage these desktops, so plan device management around that.
The shared data drive is part of that same enclave, not a folder on one desktop.
Shared data drive (Z:)
When your enclave is sized, Secureframe provisions a shared data drive mapped as Z:. Put shared or large working data there (for example multi-hundred-GB datasets) so it survives desktop rebuilds. Do not keep that data only on a single desktop's Desktop or Downloads folder.
Learn more about what happens to local files on a rebuild in Secureframe Virtual Desktops and Accessing Your Virtual Desktop.
OS updates and maintenance evidence
Secureframe Virtual Desktops use Windows automatic updates on each desktop VM. When Secureframe provisions a desktop, Azure is set with enableAutomaticUpdates: true and patchMode: AutomaticByOS. That is the same Windows automatic updates setting Azure reports on the VM.
Azure Update Manager may show these desktops as Unsupported. That is expected. Azure Update Manager does not support Windows client SKUs, including the Windows 11 multi-session image used by Azure Virtual Desktop session hosts. Unsupported in Update Manager does not mean patching is off. See Microsoft's Azure Update Manager FAQ.
Note: The System maintenance procedures test in Secureframe is an evidence-upload test (Vendor: None). Azure status alone will not turn it green. Attach a document that covers the points in the test guidance, including proof of how maintenance and updates are handled for your Virtual Desktops.
Capture patch settings for the System maintenance procedures test
Use these steps when you need a screenshot of the automatic-update settings for an evidence upload:
In Secureframe, open Virtual Desktops.
Click the desktop to open the slideout.
Click the resource URL to open the resource group in Azure.
In the table, open the item of type Virtual machine.
Open JSON View on the right side of the page.
Scroll to osProfile (often around line 42).
Screenshot the JSON segment that includes
enableAutomaticUpdates(andpatchModeif present).
Upload that screenshot, with any other procedure notes the test asks for, to the System maintenance procedures test.
Managing your desktops
On the Virtual Desktop pool list, Failed means every session host in the pool failed to deploy (no healthy desktops). Degraded means at least one desktop failed and at least one is still serving. Open the pool to see which hosts failed.
Every desktop you provision appears in your desktop list, showing its size, region, image, assigned users, and two statuses:
Deployment status: Tracks the build, showing Complete once Azure finishes creating the desktop.
System status: Shows whether the desktop is currently Running or Stopped.
If a deployment fails, the error message describes the issue (for example, quota or SKU availability) so you know what to fix.
From each desktop's menu you can Start, Stop, or Restart the desktop, or Delete it when it is no longer needed. Azure charges accrue for resources while they exist, so delete desktops you no longer use.
Managing user access
Assign users to a desktop from the same menu. Each assigned user needs an active GCC High license, and the desktop appears in their remote desktop app automatically. See Accessing Your Virtual Desktop for what your users do next.
Removing a user takes effect right away. Their sign-in access and their remote desktop feed access are both revoked. If a removed user still sees the desktop listed, have them refresh or remove and re-add the workspace in their app.
Pool admin
Pool admins can install software on desktops in the pool. Standard users cannot run installers.
Go to Virtual desktops, open the pool, and select the Access list tab.
Turn on the Pool admin toggle for that person. They become a local administrator on every desktop in the pool.
The change reaches existing desktops automatically, but the person must sign out completely and reconnect before it takes effect. Disconnecting is not enough, because Windows reads the permission when the session starts.
Tip: Install software to C:\Program Files. See Golden Image for Virtual Desktops for elevation tips, including .msi installs.
Frequently Asked Questions (FAQ)
How do I make someone a pool admin?
Go to Virtual desktops, open the pool, and select the Access list tab.
Turn on the Pool admin toggle for that person. They become a local administrator on every desktop in the pool.
The change reaches existing desktops automatically, but the person must sign out completely and reconnect before it takes effect. Disconnecting is not enough.
Pool admins can install software under
C:\Program Files. Standard users cannot run installers. See Golden Image for Virtual Desktops.
What access does Secureframe have after we connect Azure Government?
The App Registration connection can manage Virtual Desktop infrastructure in your dedicated subscription (including Owner-level deploy actions) and holds privileged Entra permissions needed to operate the environment.
It does not have standing read access to CUI or profile shares. Full detail: Secureframe Virtual Desktops.
What Azure resources are created during initial setup, before any desktops?
Core resources needed to securely enable desktop deployment, such as a virtual network, subnets, and a NAT gateway.
What Azure resources are created for each desktop?
The virtual machine along with its storage disk, network interface, and security configurations (network security groups, identity assignments, and monitoring agents).
Can I provision into an existing subscription or VDI environment?
No. Desktops are always provisioned fresh into a dedicated subscription that you own. See Prerequisites to setting up your Virtual Desktops for why.
What is the shared Z: drive, and what should go there?
When your enclave is sized, Secureframe provisions a shared data drive mapped as Z:.
Put shared or large working data there (for example multi-hundred-GB datasets) so it survives desktop rebuilds.
Do not keep that data only on a single desktop's Desktop or Downloads folder.
Why is only one region available (for example Virginia)?
Enclaves with the shared data drive use one storage account behind one private endpoint. That requires a single region for the enclave. Multi-region selection is not available when the shared data drive is enabled.
Why doesn't my virtual desktop show in Entra Devices or Intune?
Expected. Managed-domain-joined Virtual Desktops do not appear in Entra Devices or Intune.
They still show as VMs in the Azure portal.
Intune cannot manage these desktops. Plan device management around that.
Is managed domain join required?
Yes. The current supported Secureframe Virtual Desktops platform uses managed domain join.
Why does Azure Update Manager show my Virtual Desktop as Unsupported?
Expected for Secureframe Virtual Desktops.
Azure Update Manager does not support Windows client SKUs, including Windows 11 multi-session AVD session hosts.
Desktops still receive OS updates through Windows automatic updates on the VM (
enableAutomaticUpdates: true,patchMode: AutomaticByOS).
How are Secureframe Virtual Desktops patched?
Each desktop VM is provisioned with Windows automatic updates enabled (
enableAutomaticUpdates: true,patchMode: AutomaticByOS).Separately, Secureframe also releases updated golden images with Windows and security changes. New desktops use the newest approved image. Existing desktops keep their build until rebuilt. See Golden Image for Virtual Desktops.
Why is my System maintenance procedures test still failing if Azure shows Unsupported?
That test is an evidence-upload test (Vendor: None), not an automated Azure check.
Upload evidence that covers the guidance on the test, including how Virtual Desktop maintenance and patching work.
A screenshot of
osProfilewithenableAutomaticUpdatesfrom Azure JSON View is a common way to show the VM patch settings. See OS updates and maintenance evidence above.
Where do I find the automatic update settings to screenshot?
Virtual Desktops → open the desktop → resource URL → Virtual machine → JSON View →
osProfile→ screenshotenableAutomaticUpdates(andpatchModeif shown).
Where can I find guidance on FIPS-validated encryption for CUI in virtualized environments?
See FAQs: FedRAMP, CMMC, and DFARS (section FIPS and encryption for CUI) for Historical vs 140-3 certificates, which layers need validated crypto, east-west traffic, FIPS mode vs modules, and physical safeguards vs encryption.
Can I manage Secureframe Virtual Desktops with my own Terraform or OpenTofu?
No. Secureframe deploys Virtual Desktops with ARM and keeps reconciling that infrastructure for upgrades and patches.
This is not the same as the AWS connection Terraform, which only creates a read-only scanning role.
For records and review, use the deployment plan and change list in Secureframe, or request an export of the submitted ARM JSON.
Should I import Secureframe resource groups into my Terraform state?
No. Treat Secureframe-managed resource groups as vendor-managed and leave them out of your state.
Importing them causes ongoing plan drift, because Secureframe re-applies its configuration on deploy and upgrade.
Manage your own resources elsewhere in the subscription; leave Secureframe's resource groups to Secureframe.
See Drift Detection for Virtual Desktops for how Secureframe detects and preserves changes outside its managed groups.
Questions? Contact [email protected] or reach out to your CSM.
Virtual Desktop create or update fails only on the Public IP address step. What should we check?
Provisioning uses a locked-down network path. A failure only on Public IP usually means Azure networking for that desktop (public IP, NAT, or related resource) did not complete, not that sign-in credentials are wrong.
Copy the exact error text from the failed Public IP step. That message is required for Support.
Confirm you still have permission on the Azure subscription and resource group Secureframe uses for Virtual Desktops, then retry once after checking Azure activity for failed public IP or NIC operations.
If it keeps failing on that step alone, contact Support with company name, desktop name/region, and the exact error string.
What do Failed and Degraded mean on the Virtual Desktop pool list?
Failed: every session host in the pool failed to deploy. There are no healthy desktops in that pool.
Degraded: at least one desktop failed and at least one is still serving. Open the pool for host-level detail.
Use pool status to catch deploy problems without opening each desktop. For a create/update that fails only on the Public IP step, see the Public IP FAQ on this article.