If you are manufacturing a physical ITAR item you also need to be able to support R&D, factory/manufacturing (forward logistics), failure analysis, various reliability testing, release, and support/return (reverse logistics) as well. By including R&D and manufacturing in the process means you need to have test equipment like robots, Non-Destructive Xray/CT scanners, or other test items that are used to store, test an ITAR components to be connected to your Azure Government network as well. The complexity increases if the product being built is something where a large part of it or core components are regulated under the ITAR and not covered under an exception allowing you to export to a non-US Person or licensed entity.  

The areas that are of major concern for any ITAR/CUI program are:

  1. Compliance to all regulatory, contractual, and national security obligations 
  2. Ensuring all regulated data existed only in approved locations both in encrypted and non-encrypted state with proper auditing and tracking systems
  3. Ensuring persons/entities, Azure Support, Microsoft staff that can access data is approved and screened persons with correct citizenship and licenses
  4. Ensure controls are in place to meet the required NIST 800-171/CMMC regulations on proper storing, securing, auditing, inventory of regulated information
  5. Ensuring systems were secured and monitored for security compromises or vulnerabilities.  

Can you use Azure Public for ITAR?

Bottom line, While Azure Public offerings could be configured and manipulated into storing minimal amounts of ITAR/CUI it is not realistic or advisable to attempt to maintain compliance while using commercial cloud offerings. Microsoft will only support contracts that involve ITAR only if stored in Azure Government/GCC-HIGH (  

Azure Government is your best option if you need to support ITAR/CUI.

Green Field Azure Considerations

When building an ITAR/CUI environment there are a number of items you must consider before you start building and deploying. While there are technically ways to work around some of these considerations if your situation changes at a later date the impact is higher than designing with them first.  Obviously this won’t be a complete list, however it is the items that will be key in the beginning.

  1. Where is primary Identity stored?  Azure AD or Legacy Active Directory (including Azure AD DS)
    1. Many companies probably already have an Active Directory Forest/Domain setup. 
    2. However, if you don’t have legacy Active Directory already setup you need to decide if you start with AD or AAD.
      1. The question is: Will any of your systems, tools require legacy AD to function correctly. If all your tools, systems are modern and support Azure AD then you probably don’t require legacy AD.  
      2. However, you probably require Active Directory as the primary if
        1. You need to use  Azure DevOps Server (not cloud) or Perforce or other software that only supports Active Directory or  LDAP
        2. You need to manage group policy on systems/laptops/servers
        3. You are using Windows Server SKUs that don’t support Intune/Endpoint Manager joined
        4. You are using Linux systems that need Kerberos/LDAPS support
        5. You will issue and manage Certificates for 802.1x (Wifi, Wired), Authentication, VPN, application signing, SSL, workstations and, kerberos.  You will probably need to use ADCS (Active Directory Certificate Services) with an offline HSM (Hardware Security Module) backed root CA (certificate authority).  On-line CAs are required to be Domain Joined and don’t support AAD.
        6. Need to use Smart Cards/PIV or Windows Hello for Business for your MFA (Multi-Factor Authentication)
      3. If you do require using Legacy Active Directory you have a number of options on design that will be covered in future posts.  
  2. Determine what system will be used as the HR employee database.  This system if it is SAP, Workforce, or some other HR system will need to be connected into your Identity system to ensure users are created and de-activated as new employees join/leave the company.  You will need to ensure your HR system tracks citizenship, and ITAR license status to make sure accounts are created for users that are approved to have an account that is ITAR/CUI accessible (U.S. Citizen, U.S. Green Card Holder, or ITAR License granted). 
  3. Determine how you will track employees/vendors have completed required ITAR/CUI training per your FARS/DFARS contract requirements.  Your HR system will need to either expose flags tracking the required training or integrate with an LMS (learning management system) to ensure only approved users that have completed training are created.
  4. What is your primary region?
    1. Azure Government users have limited options currently for hosting services in Azure.  Arizona or Virginia.  While Texas is a location it has limited support for some resource types and is primarily a failover location.
      1. Unless you are a DoD entity you do not get to use the DoD regions and only the USGov Arizona, Virginia
    2. Pick a location that will minimize the network latency to your primary office/user base and that meets your company BCDR (Business Continuity and Disaster Recovery) requirements
  5. Ensure the features you require are actually available in Azure Government.  Generally, getting new features in Azure Gov takes 6-12 months after GA in Azure Public.  Some SKUs, features, and capabilities don’t even exist in Azure Government yet, or require extra steps to get functional.
  6. Are you going to require On-Prem file storage or appliances for testing, manufacturing.  While Azure offers SMB file storage it is slow if you are needing to store many TB of data for Computer Vision, AI, or other models. If you require on-site storage appliances for network shares you will probably need Legacy AD and to setup a Site to Site VPN, or ExpressRoute back into Azure.  Make sure you take into account your current and future needs when determining how to design your network.
  7. Determine how you are going to allow data to flow between your regulated and non-Regulated environment.  It is important to think about this early as it can impact how you setup your systems and what controls you put in place.  I will cover 1st party considerations for sharing in future posts.  
  8. Determine how you are going to share materials and content with 3rd parties including the DoD in a compliant way.  How will you ensure an employee doesn’t accidentally email an ITAR file to someone outside of the USA or to a non-US person?  I will cover considerations for 3rd party sharing in future posts.
    1. While the DoD may use SAFE other other tools to exchange information you may need to share very large data sets and are not supported by SAFE
    2. 3rd party suppliers and vendors may need to provide you with updated software/tools/libraries that are regulated under the ITAR/CUI and you need to ensure they are stored and uploaded in a compliant way
    3. Law firms, Marketing, etc persons many not be as technical as your engineering staff and require an easy to use data exchange option to download or upload information that is both ITAR/CUI and commercial un-regulated.
  9. Review your laptop/workstation manufacture and ensure your company has reviewed the risk of using non-US manufactures.  It is recommended to only use U.S. companies for your workstations and avoid non-US companies like Lenovo, Asus, MSI, Toshiba, etc.  It is best to consider companies like Dell, HP, Apple, Microsoft, Alienware, for both information worker and AR/VR/Engineer systems.  Obviously you will have exception processes but it is better to not use companies with know/unknown ties to Foreign governments.
    1. It is known many of the U.S. Companies manufacture their systems in China or Taiwan. While true, the U.S. legal entity would be accountable to U.S. government to ensure proper supply chain under the Cybersecurity Executive Order 14028

Azure Government Considerations

  1. Getting approved to have an Azure Government Tenant is a process with the U.S. Government ( and Microsoft. It can take weeks to get approval.
  2. Make sure your IT, Network, Security, Staff are US Persons/US Citizens to ensure you keep compliance with regulations.
  3. Azure Government features sets are generally 6-12 months behind Azure Public GA
  4. Many Azure Security features are not available at all nor are they on any public roadmaps
  5. You are limited to only a few Azure regions within the U.S.A. and there can be network limitations/latency
  6. Azure Government support can be more time-consuming because not all Azure feature teams are staffed with U.S. Citizens allowed to access Azure Government environment to debug your issue
  7. Peering (B2B, B2C) between other Azure Public Tenants isn’t currently possible
  8. Many public tools/software that Supports Azure Public won’t support Azure Government without updates/explicit support for different endpoints for authentication, etc.  Use of scripts and tools also require different parameters to support connecting to Azure Government.
  9. Know that just because you operate in Azure Government doesn’t mean you are ITAR compliant or will pass NIST 800-171.  It simply means the infrastructure you are using meets some of the requirements and you can inherit those controls.
  10. It costs more and generally more complex to operate in Azure Government than Azure Public.  Both for licenses and overall staff and support costs.
  11. GCC-High M365/O365 licenses must be purchased via an Enterprise Agreement (EA) and can’t be purchased directly on the website.  You will need to plan you license needs as billing is done in 12 months increments. With a billing cycle starting on the 2nd of the month.

I will continue to provide setup and build-out steps and information for best practices and how-tos on building an ITAR/CUI compliant engineering environment.

Leave a Reply

Your email address will not be published. Required fields are marked *