Region Support
This article covers how the Secureframe Virtual supports engineering environments, including GPU-backed workstations, network security, access control, and logging
Region ID | Code | Label |
usgovvirginia | va | US Gov Virginia (default) |
usgovarizona | az | US Gov Arizona |
usgovtexas | tx | US Gov Texas |
VM Sizes
Azure VM Size | Label | Specifications | Region Availability |
Standard_D2ds_v4 | Light | 2 vCPUs, 8 GB RAM | All regions |
Standard_D4ds_v4 | Medium | 4 vCPUs, 16 GB RAM | All regions |
Standard_D8ds_v4 | Heavy | 8 vCPUs, 32 GB RAM | All regions |
Standard_NV6ads_A10_v5 | Power (GPU enabled) | 6 vCPUs, 55 GB RAM, 1/6 NVIDIA A10 GPU | Virginia |
Standard_NV4as_v4 | Power (GPU enabled) | 4 vCPUs, 14 GB RAM, 1/8 AMD Radeon MI25 GPU | Arizona |
Hardware & Performance
Instance Types for Engineering Workloads
The Enclave's "Power" instance type, available in the Virginia and Arizona regions, is designed to support GPU-backed engineering workloads including 3D modeling applications like SolidWorks. If the Power instance doesn't meet your hardware requirements, custom instance types are also supported, anything Azure offers within Azure US Government regions can be provisioned.
VDI Latency for CAD Modeling
Interactive performance depends on two factors: the instance hardware meeting the application's recommended specs, and your proximity to the data center. Round-trip times of approximately 50ms are realistic when connecting to a nearby region, this is nearly indistinguishable from working on a local device. As a reference point, connecting from Philadelphia to the Virginia region (about 200 miles) achieves this.
Infrastructure & Server Support
Engineering Workstations
GPU-backed Power instances can be provisioned to support a team of engineering workstations.
Shared servers and line-of-business apps
Some engineering and estimating apps need a shared backend that multiple Virtual Desktops can reach, such as a SolidWorks PDM vault, a licensing server, a dedicated SQL Server, or a file/terminal server for a line-of-business app (for example HeavyBid). Use a service machine inside your Secureframe Virtual Desktops enclave for that role.
A service machine is a VM in the enclave that other desktops can reach on the network. It is meant for daemons and services (licensing, databases, file shares), not as a day-to-day user workstation. You install and secure the server software. Secureframe provides the enclave network path between desktops and the service machine.
To create one:
Open Virtual Desktops.
Choose Create pool, then Service machine.
Pick an instance size that meets your application's server requirements (use a heavier size when the vendor calls for more CPU or RAM), and review the estimated Azure cost before you confirm.
Note: Service machines require the current Virtual Desktops platform (V5). If you still see upgrade banners in Virtual Desktops, complete those upgrades in order before Create pool → Service machine is available.
Note: There is one service machine per region. If create fails because a service machine already exists, check your desktop list, including any Legacy desktops view, before provisioning another. A second service-machine pool in the same region will not deploy.
Important: Peering or connecting an outside / on-premises server into the Secureframe Virtual Desktops enclave is not supported out of the box. That expands your CMMC boundary. Keep the server role on a service machine inside the enclave when you can. If you believe you need an outside connection, talk with Secureframe Compliance before you proceed.
Typical pattern (same idea as SolidWorks licensing):
Install the server or licensing components on the service machine and open only the Windows Firewall ports your app needs from the enclave subnet.
Install the client on each Virtual Desktop and point it at the service machine.
You remain responsible for hardening and maintaining the third-party software. Secureframe does not certify vendor apps for CMMC.
Installing only the client on a regular Virtual Desktop (no shared backend) is covered under Secureframe Virtual Desktops.
Network Security & Boundary
How the Enclave Boundary Works
Virtual desktops are placed on an isolated virtual network. A network security group is applied to the subnet, which does two things:
Blocks communication between virtual desktops (compartmentalization of CUI)
Denies all inbound traffic from the public internet
The only allowed connectivity is outbound via a NAT gateway, or remote desktop connections mediated through Azure Virtual Desktop.
Replacing On-Prem VLAN Segmentation
For organizations currently relying on Hyper-V or VLAN-based segmentation to isolate CUI, the Enclave's network architecture provides an equivalent boundary without requiring on-prem infrastructure management.
Access Control
How User Access is Granted
Secureframe automatically configures role assignments based on the Entra accounts assigned to machines within the Secureframe application. Only users explicitly assigned to a virtual desktop will be able to access it. Assigned users will see their virtual desktops appear directly in their Windows app.
Logging & Monitoring
Built-in Logging
Secureframe is rolling out automatic configuration of logging and alerting via Azure Log Analytics for Enclave environments.
Frequently Asked Questions (FAQ)
Can the enclave support a shared server (for example a PDM vault, SQL Server, or a file/terminal server for an app like HeavyBid)?
Yes, with a service machine inside the enclave. Create one from Virtual Desktops → Create pool → Service machine (requires the current platform / V5; complete any upgrade banners first).
Use the service machine for the shared backend (licensing, database, or file/terminal server). Install the client on each Virtual Desktop and point it at the service machine. Pick an instance size that matches the vendor's server requirements and review cost before you deploy.
One service machine per region. If Secureframe says one already exists, check your list (including Legacy desktops) before creating another.
Peering an outside or on-premises server into the enclave is not supported out of the box and has CMMC boundary implications. Prefer keeping the server role on the service machine inside the enclave.
Installing only the client app on a Virtual Desktop (no shared backend) is separate. See Secureframe Virtual Desktops.
What is a service machine?
A service machine is an enclave VM that other Virtual Desktops can reach on the network. Use it for shared services such as licensing servers, databases, or file/terminal backends for apps like SolidWorks or HeavyBid.
Create it from Virtual Desktops → Create pool → Service machine after you are on the current platform (V5).
It is not meant as a daily user workstation. Keep interactive user work on regular Virtual Desktops and put shared server software on the service machine.
Can I peer my own on-premises server into the Secureframe Virtual Desktops enclave?
Not out of the box. Connecting an outside network into the enclave expands your CMMC boundary and is not a supported default path.
When you need a shared server for an app that has no CMMC-ready cloud option, use a service machine inside the enclave instead.
Will VDI performance handle real-time 3D CAD modeling?
Yes, when the instance hardware meets the application's recommended specs and you connect from a nearby region. Round-trip times of about 50ms are realistic nearby (for example, Philadelphia to the Virginia region (about 200 miles) is nearly indistinguishable from a local device). Use the Power (GPU-enabled) instance type in Virginia or Arizona for GPU-backed CAD workloads like SolidWorks.
How is the network boundary enforced?
Virtual desktops sit on an isolated virtual network with a network security group on the subnet. That blocks communication between virtual desktops, denies inbound traffic from the public internet, and allows only outbound connectivity via a NAT gateway or remote desktop connections through Azure Virtual Desktop.